Replikasi Database MySQL, Kapan Perlu dan Cara Kerjanya

Replikasi database MySQL adalah mekanisme yang membuat satu atau beberapa server (replika) terus menyalin perubahan data dari server utama (sumber). Setiap INSERT, UPDATE, dan DELETE di sumber dicatat, dikirim, lalu dijalankan ulang di replika, sehingga isi keduanya hampir selalu sama.

Kedengarannya seperti solusi untuk semua masalah database, padahal tidak. Salah memahami replikasi bisa berakibat dua hal: membayar dan merawat server tambahan yang sebenarnya tidak perlu, atau merasa aman padahal data yang terhapus ikut terhapus di replika dalam hitungan detik.

Bagaimana replikasi MySQL bekerja?

Binary log, thread I/O, dan thread SQL

Di server sumber, setiap perubahan data ditulis ke binary log. Di MySQL 8.0 ke atas, binary log aktif secara bawaan. Replika menjalankan dua jenis proses utama: satu yang terhubung ke sumber dan mengunduh isi binary log ke relay log lokal, dan satu lagi yang membaca relay log lalu menerapkan perubahannya ke data replika.

Replikasi bawaan MySQL bersifat asinkron. Sumber tidak menunggu replika. Transaksi dianggap selesai begitu tercatat di sumber, dan replika menyusul sesaat kemudian. Selisih waktu ini disebut replication lag, terlihat di kolom Seconds_Behind_Source pada SHOW REPLICA STATUS.

GTID memudahkan pengelolaan

Dulu replika harus tahu nama file dan posisi binary log persis untuk mulai menyalin. Dengan GTID (Global Transaction Identifier), setiap transaksi punya ID unik, sehingga replika cukup diberi tahu "lanjutkan dari transaksi yang belum kamu punya". Ini jauh lebih mudah saat memindahkan replika atau mempromosikannya menjadi sumber.

Contoh konfigurasi di MySQL 8.4

Di kedua server, tambahkan ke konfigurasi MySQL (dengan server_id berbeda):

[mysqld]
server_id = 1
gtid_mode = ON
enforce_gtid_consistency = ON

Di sumber, buat user khusus replikasi:

CREATE USER 'repl'@'10.0.0.21' IDENTIFIED BY 'kata-sandi-panjang';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.0.0.21';

Hak aksesnya memang masih bernama REPLICATION SLAVE. Di replika (dengan server_id = 2), setelah datanya diisi dengan salinan awal dari sumber, jalankan:

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.0.20',
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'kata-sandi-panjang',
  SOURCE_AUTO_POSITION = 1,
  SOURCE_SSL = 1;
START REPLICA;
SHOW REPLICA STATUS\G

Pastikan Replica_IO_Running dan Replica_SQL_Running bernilai Yes. Aktifkan juga super_read_only = ON di replika agar tidak ada yang menulis langsung ke sana. Perintah lama seperti CHANGE MASTER TO dan START SLAVE sudah dihapus di MySQL 8.4. MariaDB punya sintaks dan implementasi GTID sendiri, jadi ikuti dokumentasi MariaDB bila kamu memakainya.

Koneksi replikasi berjalan lewat jaringan, sebaiknya lewat jaringan privat dan port yang dibatasi firewall. Panduannya mirip dengan membuka akses remote MySQL dengan aman.

Jenis replikasi dan topologi yang umum

Untuk topologi, yang paling umum adalah satu sumber dengan satu atau beberapa replika. Topologi dua sumber yang saling menulis (multi-source atau dual primary) jarang cocok untuk usaha kecil karena rawan konflik data.

Kapan replikasi benar-benar perlu?

Butuh server cadangan yang siap diambil alih. Kalau target waktu pulih (RTO) database hanya hitungan menit, memulihkan dari backup puluhan gigabyte tidak akan sempat. Replika yang selalu mengikuti sumber bisa dipromosikan menjadi sumber baru. Cara menghitung target ini ada di apa itu RPO dan RTO.

Beban baca jauh lebih besar dari beban tulis. Laporan berat, pencarian, atau dashboard analitik bisa diarahkan ke replika supaya tidak memperlambat transaksi di sumber. Syaratnya, aplikasi harus bisa membedakan koneksi baca dan tulis, dan siap dengan data replika yang sedikit tertinggal.

Backup tanpa mengganggu server utama. Dump atau snapshot bisa diambil dari replika, sehingga server sumber tetap ringan saat jam sibuk.

Salinan di lokasi lain. Replika di pusat data berbeda memberi perlindungan saat lokasi utama bermasalah.

Kapan belum perlu?

Kalau database masih kecil, aplikasi bisa berhenti beberapa jam tanpa kerugian besar, dan bebannya belum menyiksa server, backup harian yang teruji biasanya sudah cukup. Masalah performa juga sering lebih tepat diselesaikan dengan indeks, query yang diperbaiki, atau memisahkan database ke server sendiri lebih dulu.

Replikasi menambah pekerjaan: satu server lagi untuk dirawat, lag yang harus dipantau, dan prosedur failover yang harus dilatih. Kalau tidak ada yang memantau, replikasi bisa berhenti diam-diam berminggu-minggu tanpa ada yang sadar.

Kapan memilih asinkron, semi-sinkron, atau cluster?

Pilih asinkron bila tujuanmu replika baca, backup dari replika, atau cadangan yang boleh kehilangan beberapa detik transaksi terakhir. Ini yang paling sederhana dan cukup untuk banyak usaha.

Pilih semi-sinkron bila kehilangan transaksi yang sudah dikonfirmasi ke pelanggan, misalnya pembayaran, tidak bisa ditoleransi, dan jaringan antar server cepat serta stabil. Tambahan latensi pada setiap penulisan perlu diuji dulu.

Pilih Group Replication atau InnoDB Cluster bila kamu butuh failover otomatis dan punya tim yang siap merawat minimal tiga server. Bila tim kecil, layanan database terkelola yang sudah menyediakan replika dan failover sering lebih masuk akal daripada merakit sendiri.