--- title: "Replikasi Database MySQL, Kapan Perlu dan Cara Kerjanya" description: "Cara kerja replikasi MySQL dengan binary log dan GTID, jenis-jenisnya, kapan bisnis benar-benar butuh, contoh konfigurasi MySQL 8.4, dan batasannya." url: "https://nivelva.com/insight/replikasi-database-mysql-perlu-cara-kerjanya" category: "Server \u0026 Infrastruktur" tags: ["mysql","replikasi","database","gtid","high availability"] author: "Theresia Candiawan" published: "2026-11-07T11:11:00+07:00" updated: "2026-11-07T11:11:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Replikasi Database MySQL, Kapan Perlu dan Cara Kerjanya > **Jawaban singkat:** Replikasi MySQL menyalin setiap perubahan dari server sumber ke server replika lewat binary log. Ia perlu saat kamu butuh server cadangan yang siap diambil alih, ingin memindahkan beban baca, atau butuh salinan nyaris real time, tapi tidak menggantikan backup. 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](https://nivelva.com/insight/cara-membuka-akses-remote-mysql-aman). ## Jenis replikasi dan topologi yang umum | Jenis | Cara kerja | Risiko kehilangan data saat sumber mati | Kerumitan | |:--|:--|:--|:--| | Asinkron (bawaan) | Sumber tidak menunggu replika | Transaksi terakhir yang belum terkirim bisa hilang | Rendah | | Semi-sinkron | Sumber menunggu minimal satu replika mengonfirmasi menerima transaksi | Lebih kecil, dengan tambahan latensi tulis | Sedang | | Group Replication / InnoDB Cluster | Beberapa server bersepakat atas setiap transaksi, failover otomatis | Paling kecil di antara ketiganya | Tinggi | 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](https://nivelva.com/insight/apa-itu-rpo-rto-dalam-rencana-pemulihan-server). **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](https://nivelva.com/insight/database-server-terpisah-perlu-dipisah) 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. > **Replikasi bukan backup:** > > Perintah `DROP TABLE` atau `DELETE` yang salah di sumber akan ikut dijalankan di replika dalam hitungan detik. Tetap jalankan backup terjadwal, misalnya seperti di [backup database otomatis](https://nivelva.com/insight/backup-database-otomatis), dan simpan di luar kedua server. ## 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. ## Pertanyaan yang sering diajukan ### Apakah replika bisa dipakai untuk menulis data? Sebaiknya tidak. Tulisan langsung ke replika membuat datanya berbeda dari sumber dan bisa menghentikan replikasi. Aktifkan `super_read_only` di replika. ### Bagaimana cara memantau replikasi? Periksa `SHOW REPLICA STATUS` secara berkala, terutama status thread dan `Seconds_Behind_Source`, lalu kirim alert bila replikasi berhenti atau lag terus naik. ### Apa yang terjadi bila jaringan antara sumber dan replika putus? Pada replikasi asinkron, sumber tetap berjalan. Saat jaringan pulih, replika melanjutkan dari transaksi terakhir yang ia terima, selama binary log di sumber belum terhapus. ### Berapa lama binary log perlu disimpan? Cukup lama agar replika yang tertinggal masih bisa menyusul. Di MySQL 8.4, masa simpan diatur dengan `binlog_expire_logs_seconds`, sesuaikan dengan ruang disk dan lama gangguan terburuk yang kamu perkirakan. ## Sumber - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/replikasi-database-mysql-perlu-cara-kerjanya Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com