Replikasi Database Adalah: Cara Kerja, Jenis & Risikonya

Sebagian besar aplikasi web bertumpu pada satu server database. Semua permintaan, baik membaca maupun menulis, mendarat di mesin yang sama. Susunan ini bekerja dengan baik sampai salah satu dari dua hal terjadi: server itu mati, atau jumlah pembacanya melampaui kemampuannya melayani.

Replikasi database adalah jawaban paling umum untuk kedua masalah tersebut. Idenya sederhana, yaitu menyediakan salinan data di server lain dan menjaganya tetap mengikuti perubahan di server asli. Yang tidak sederhana adalah konsekuensinya, dan bagian itulah yang paling sering terlewat.

Apa Itu Replikasi Database?

Replikasi database adalah proses menyalin data dari satu server database ke satu atau lebih server lain, lalu menjaga salinan tersebut tetap selaras dengan sumbernya secara berkelanjutan. Dalam dokumentasi berbahasa Inggris istilahnya database replication. Kata "berkelanjutan" adalah intinya, dan di situlah pengertian replikasi database sering dipersempit keliru. Menyalin berkas database satu kali bukan replikasi, melainkan penggandaan biasa yang langsung usang begitu ada satu baris berubah.

Tiga hal sering tertukar karena sama-sama menghasilkan salinan data:

1. Replikasi: salinan hidup yang terus mengejar perubahan di sumbernya, biasanya dalam hitungan milidetik sampai detik. Tujuannya ketersediaan dan pembagian beban.
2. Cadangan (backup): potret data pada satu titik waktu, disimpan terpisah dan sengaja dibekukan. Tujuannya pemulihan setelah kerusakan atau kesalahan.
3. Mirroring tingkat disk: penggandaan blok data di lapisan perangkat keras, misalnya pada RAID 1. Ini berlangsung di bawah database, dan database sama sekali tidak menyadarinya.

Tiga salinan data: replikasi salinan hidup, cadangan potret beku, mirroring RAID 1 penggandaan blok di lapisan disk.

Setiap perangkat lunak memakai sebutan sendiri untuk peran yang terlibat: MySQL memakai source dan replica, PostgreSQL memakai primary dan standby, SQL Server memakai publisher serta subscriber. Istilah lama master dan slave masih beredar sangat luas, dan kita akan kembali ke persoalan ini karena akibatnya sudah nyata di server yang baru.

Cara Kerja Replikasi: Perjalanan Satu Baris Data

Cara kerja replikasi database paling mudah dipahami dengan mengikuti satu perintah UPDATE dari awal sampai mendarat di server salinan. Seluruh proses replikasi database berlangsung dalam beberapa tahap berikut.

Semuanya dimulai saat transaksi dijalankan dan disetujui (commit) di server sumber. Sebelum jawaban "berhasil" dikirim ke aplikasi, perubahan itu dicatat berurutan ke sebuah berkas log. MySQL menyebutnya binary log, PostgreSQL menyebutnya write-ahead log (WAL). Log ini sebenarnya sudah ada lebih dulu untuk memulihkan database setelah server mati mendadak; replikasi hanya menumpang catatan yang sudah tersedia itu.

Di sisi lain, server replika membuka koneksi tetap ke server sumber. Dua utas kerja (thread) menangani sisanya:

1. Utas penerima: menyalin peristiwa baru dari binary log sumber ke berkas perantara di disk replika, yang disebut relay log. Tugasnya hanya menerima, bukan menjalankan.
2. Utas pelaksana: membaca relay log dan benar-benar menjalankan perubahannya ke tabel di replika.

Pemisahan dua utas ini penting untuk dipahami. Menerima data jauh lebih cepat daripada menjalankannya, sehingga relay log bisa saja sudah penuh sementara tabelnya belum diperbarui. Di celah antara kedua utas itulah jeda replikasi lahir.

Cara kerja replikasi database: binary log disalin utas penerima ke relay log, lalu ditulis utas pelaksana ke tabel replika.

Replika juga perlu menandai sudah sampai di mana ia bekerja. Cara lama memakai pasangan nama berkas binlog dan angka posisi di dalamnya, yang rapuh begitu server sumber berganti. Cara yang lebih baru memakai GTID (Global Transaction Identifier), yaitu identitas unik untuk setiap transaksi.

Format perekamannya ada tiga: statement-based menyalin perintah SQL-nya, row-based menyalin baris hasil perubahannya, dan mixed memilih otomatis. MySQL modern memakai row-based sebagai bawaan, karena NOW(), RAND(), dan UUID() menghasilkan nilai berbeda bila dijalankan ulang di mesin lain.

Fungsi dan Tujuan Replikasi Database

Fungsi replikasi database sering diringkas menjadi "supaya aman", padahal manfaat replikasi database terpisah menjadi beberapa hal yang tidak selalu datang bersamaan:

1. Menjaga layanan tetap hidup saat satu server jatuh: ketika server sumber mati, salah satu replika dapat dinaikkan menjadi server penulis yang baru. Sebagian sistem melakukannya otomatis, sebagian menuntut perintah manual.
2. Membagi beban baca: aplikasi mengirim seluruh perintah tulis ke satu server, tetapi menyebar perintah baca ke beberapa replika, entah dari sisi aplikasi atau lewat load balancing khusus database.
3. Mendekatkan data ke penggunanya: replika di wilayah lain memangkas waktu tempuh permintaan baca. Pengguna di Singapura membaca dari salinan terdekat, bukan menyeberang ke Jakarta setiap kali.
4. Menjalankan laporan berat tanpa mengganggu produksi: kueri rekapitulasi yang memindai jutaan baris dijalankan di replika khusus, sehingga server yang melayani pengguna tidak ikut melambat.
5. Menyediakan sumber data untuk sistem lain: replika logis mengalirkan perubahan ke gudang data atau mesin pencari internal tanpa membebani database utama.

Perhatikan bahwa tidak satu pun dari lima poin di atas berbunyi "menggantikan cadangan". Ini bukan kelalaian penulisan, dan alasannya jelas di bagian kelemahan.

Jenis Replikasi Berdasarkan Waktu Tunggu

Jenis replikasi database yang paling menentukan perilaku sistem Anda adalah pembagian berdasarkan seberapa lama server sumber bersedia menunggu replikanya. Ada tiga metode replikasi database di sini, dan masing-masing menukar kecepatan dengan jaminan.

Asinkron (asynchronous) adalah bawaan MySQL. Server sumber mencatat perubahan ke binary log, membalas "berhasil" ke aplikasi, lalu melanjutkan tanpa peduli apakah replikanya sempat menerima. Ini yang tercepat, dan risikonya juga paling jelas: bila sumber mati sesaat setelah membalas, transaksi yang sudah dinyatakan berhasil bisa hilang karena belum pernah sampai ke mana pun.

Semi-sinkron (semisynchronous) menutup sebagian celah itu. Sumber menahan balasan sampai minimal satu replika mengonfirmasi bahwa peristiwanya sudah diterima dan ditulis ke relay log. Perhatikan kata "diterima", karena replika belum tentu sudah menjalankannya. Di MySQL fitur ini berbentuk plugin yang harus dipasang di kedua sisi.

Satu angka pada mode ini layak Anda ingat. Variabel rpl_semi_sync_source_timeout bernilai bawaan 10.000 milidetik. Bila tidak ada satu pun replika yang menjawab dalam sepuluh detik, server sumber berhenti menunggu dan turun ke mode asinkron.

Tiga jenis replikasi database: asinkron tidak menunggu, semi-sinkron menunggu satu replika, sinkron menunggu konfirmasi.

Penurunan ke asinkron ini terjadi tanpa pesan kesalahan. Aplikasi Anda tetap berjalan normal, dan jaminan "minimal satu salinan sudah menerima" hilang tanpa ada yang memberi tahu. Sistem kembali ke semi-sinkron sendiri begitu ada replika yang menyusul.

Sinkron (synchronous) menuntut konfirmasi sebelum transaksi dianggap selesai. MySQL standar tidak menyediakannya dan mengarahkan pemakaian NDB Cluster untuk kebutuhan ini. PostgreSQL menanganinya lewat parameter synchronous_commit yang punya lima tingkat:

Hanya remote_apply yang benar-benar menjamin data terbaca dari standby segera setelah commit. Tingkat itu juga yang paling lambat, karena setiap transaksi menunggu perjalanan bolak-balik ke server lain.

Model Replikasi: Master-Slave, Master-Master, dan Istilah Barunya

Selain waktu tunggu, model replikasi database dibedakan berdasarkan arah aliran datanya.

Satu arah adalah bentuk paling umum. Satu server menerima seluruh perintah tulis, dan satu atau beberapa server lain hanya menerima salinan. Inilah yang selama ini dikenal sebagai replikasi master-slave. Kelebihannya adalah kesederhanaan, karena tidak pernah ada dua pihak yang mengubah baris yang sama.

Dua arah membuat dua server sama-sama menerima tulisan dan saling menyalin. Susunan master-master ini terdengar menarik karena keduanya produktif, tetapi memunculkan masalah baru. Yang paling cepat terasa adalah tabrakan nomor AUTO_INCREMENT, ketika dua server sama-sama menyisipkan baris dan memilih angka yang sama. Penyelesaian bakunya memakai dua variabel: untuk N server, auto_increment_increment diisi N di semua server, sedangkan auto_increment_offset diisi angka berbeda dari 1 sampai N. Pada dua server, artinya yang satu memakai angka ganjil dan yang lain memakai angka genap.

Model replikasi master-slave satu arah tanpa konflik, dibanding master-master dua arah yang tetap bisa bentrok nomor.

Pola ini menghindari tabrakan nomor, bukan menghapus konflik. Bila dua pengguna mengubah baris yang sama di dua server berbeda dalam waktu berdekatan, salah satu perubahan tetap akan kalah. MySQL InnoDB Cluster mengatur kedua variabel itu otomatis untuk susunan multi-primary sampai sembilan anggota.

Perintah master dan slave sudah dihapus di MySQL 8.4

Sejak MySQL 8.0.23 yang dirilis 18 Januari 2021, seluruh pernyataan bergaya master dan slave berstatus usang, dan penggantinya diperkenalkan sebagai alias. Pada MySQL 8.4 LTS, pernyataan lama itu dihapus — bukan sekadar memunculkan peringatan, melainkan ditolak. Inilah penyebab panduan lama gagal di baris pertama:

Parameternya ikut berubah: MASTER_HOST menjadi SOURCE_HOST, MASTER_PORT menjadi SOURCE_PORT, dan seterusnya. MariaDB mengambil jalan berbeda dengan menerima kedua bentuk sekaligus, sehingga skrip lama tetap berjalan di sana. Bila server Anda MySQL 8.4 dan panduan yang Anda ikuti masih menuliskan CHANGE MASTER TO, kesalahan sintaks yang muncul bukan karena Anda salah ketik.

Replikasi di MySQL, PostgreSQL, dan SQL Server

Cara replikasi database berbeda cukup jauh antar perangkat lunak, meski konsep dasarnya sama.

Replikasi database MySQL — atau MySQL replication dalam dokumentasinya — memakai binary log dengan penanda posisi atau GTID, ditambah plugin semi-sinkron bila dibutuhkan. Untuk susunan yang lebih rapat tersedia Group Replication, dengan batas keanggotaan maksimum sembilan server dalam satu grup; permintaan bergabung dari anggota kesepuluh ditolak. Versi 8.4 adalah rilis LTS dengan dukungan utama sampai 30 April 2029. Replikasi database MariaDB menempuh jalur terpisah, dengan seri 12.3 sebagai rilis jangka panjang yang dirawat sampai Juni 2029.

Replikasi database PostgreSQL membedakan dua bentuk yang sering tertukar. Replikasi fisik mengalirkan WAL apa adanya, sehingga standby menjadi tiruan persis dari primary sampai ke tingkat blok penyimpanan; inilah yang dikenal sebagai streaming replication. Replikasi logis membaca isi WAL lalu mengirimkan perubahannya per tabel, sehingga Anda dapat memilih tabel tertentu saja dan bahkan menyalin antar versi PostgreSQL yang berbeda. Keduanya diatur lewat wal_level, yang harus bernilai replica untuk bentuk fisik dan logical untuk bentuk logis. Versi mayor terbaru adalah PostgreSQL 18 yang dirilis 25 September 2025.

Replikasi database SQL Server disusun sebagai enam jenis resmi, bukan tiga seperti yang sering dituliskan. Tiga yang pokok adalah snapshot yang mengirim potret data secara berkala, transactional yang mengalirkan perubahan hampir seketika, dan merge yang memakai pemicu untuk menyelaraskan perubahan dari kedua sisi. Tiga sisanya — peer-to-peer, bidirectional, dan updatable subscriptions — dibangun di atas jenis transactional.

Replikasi database MySQL lewat binary log, PostgreSQL lewat write-ahead log, SQL Server lewat publisher-subscriber.

Di luar tiga besar itu, replikasi database Oracle ditangani Data Guard untuk standby dan GoldenGate untuk replikasi logis lintas sistem. MongoDB membungkusnya sebagai replica set dengan anjuran minimal tiga anggota. Bila primary tidak terjangkau selama electionTimeoutMillis yang bernilai bawaan 10 detik, salah satu secondary mengajukan pemilihan, dan primary baru umumnya terpilih dalam waktu sekitar 12 detik.

Replikasi dan Fragmentasi pada Database Terdistribusi

Replikasi database terdistribusi hanyalah satu dari dua metode menyebar data ke banyak simpul. Metode satunya adalah fragmentasi, dan keduanya menjawab pertanyaan yang berbeda.

Replikasi menaruh salinan yang sama di beberapa simpul, menjawab pertanyaan "apa yang terjadi kalau satu simpul mati?". Fragmentasi memecah data lalu menaruh potongan berbeda di simpul berbeda, menjawab pertanyaan "bagaimana menampung data yang tidak muat di satu mesin?". Fragmentasi horizontal membagi per baris, misalnya pelanggan wilayah barat dan wilayah timur di simpul yang berlainan. Fragmentasi vertikal membagi per kolom.

Sistem nyata hampir selalu memakai keduanya sekaligus. Contoh replikasi database yang menggabungkan keduanya adalah Apache Cassandra: data lebih dulu dipecah berdasarkan kunci partisi, lalu setiap potongan disalin sebanyak nilai replication factor yang Anda tetapkan. Dengan replication factor 3, setiap potongan selalu ada di tiga simpul berbeda.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Replikasi memindahkan sebagian masalah, dan sebagai gantinya memunculkan masalah baru yang harus Anda kelola.

Jeda replikasi selalu ada, dan sulit diukur dengan jujur. Metrik yang paling sering dipakai adalah Seconds_Behind_Source pada keluaran SHOW REPLICA STATUS, dan dokumentasi MySQL sendiri menyatakan kolom itu hanya berguna pada jaringan cepat. Pada jaringan lambat, angkanya kerap menunjukkan 0 justru ketika utas penerima jauh tertinggal, karena yang dibandingkan adalah utas pelaksana terhadap utas penerima, bukan terhadap server sumber. Nilainya juga menjadi NULL saat utas pelaksana berhenti.

Data yang baru Anda tulis belum tentu langsung terbaca. Bila aplikasi menulis ke server sumber lalu segera membaca dari replika, hasilnya bisa jadi data lama; pengguna yang baru menyunting profilnya melihat versi sebelum suntingan. Penyelesaiannya bukan menambah replika, melainkan mengarahkan pembacaan sesaat setelah penulisan kembali ke server sumber.

Replikasi bukan cadangan. Ini kekeliruan yang paling mahal. Perintah DROP TABLE yang salah sasaran tersalin ke seluruh replika dalam hitungan detik, dan Anda kehilangan data di semua tempat sekaligus. Replikasi menyalin kesalahan Anda sesetia ia menyalin data yang benar.

Kasus DROP TABLE keliru: replikasi menghapus tabel di sumber dan semua replika, arsip cadangan kemarin malam tetap utuh.

Bukti paling telak datang dari dokumentasi MySQL sendiri. Mereka menyediakan fitur delayed replication lewat SOURCE_DELAY, yang sengaja membuat satu replika tertinggal sekian detik atau jam. Alasan pertama yang mereka daftarkan untuk fitur itu adalah melindungi dari kesalahan pengguna di server sumber — artinya replikasi biasa memang tidak melindunginya. Jadi replikasi berdampingan dengan backup, bukan menggantikannya.

Biaya dan pekerjaan bertambah. Dua server aktif berarti dua kali biaya perangkat, ditambah pemantauan yang harus Anda siapkan sendiri. Replikasi yang berhenti diam-diam adalah kejadian lazim, dan tidak ada yang memberi tahu sampai seseorang membutuhkan replika itu. Kebutuhan teknisnya juga menutup pintu shared hosting, karena menyunting berkas konfigurasi dan membuka port antar server menuntut akses root di dua mesin terpisah, yaitu minimal dua VPS Indonesia atau server sekelasnya.

Gambaran Menyiapkan Replikasi MySQL

Cara membuat replikasi database berbeda-beda per perangkat lunak, tetapi kerangkanya mirip. Empat langkah berikut memakai sintaks MySQL 8.4 supaya Anda mengenali bentuk pekerjaannya sebelum masuk ke panduan teknis mana pun.

Langkah #1: Nyalakan binary log dan beri nomor unik

Di berkas konfigurasi server sumber, aktifkan pencatatan binary log dan tetapkan server_id yang berlainan untuk setiap server:

[mysqld]
log_bin = mysql-bin
server_id = 1
gtid_mode = ON
enforce_gtid_consistency = ON

Langkah #2: Buat akun khusus untuk replikasi

Akun ini hanya membutuhkan satu hak akses, dan sebaiknya tidak dipakai untuk keperluan lain:

CREATE USER 'repl'@'%'
  IDENTIFIED BY 'sandi-yang-kuat';
GRANT REPLICATION SLAVE ON *.*
  TO 'repl'@'%';

Nama hak akses REPLICATION SLAVE masih memakai istilah lama meski pernyataan perintahnya sudah diganti. Bagian ini memang belum diseragamkan, jadi jangan mengubahnya menjadi REPLICATION REPLICA.

Langkah #3: Ambil salinan awal, lalu arahkan replika

Replika membutuhkan titik berangkat yang sama. Ambil cadangan dari server sumber dan pulihkan ke server replika; tanpa langkah ini, replika akan menerapkan perubahan ke tabel yang isinya tidak sepadan. Setelah itu, jalankan di server replika:

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '10.0.0.1',
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'sandi-yang-kuat',
  SOURCE_AUTO_POSITION = 1;
START REPLICA;

Baris SOURCE_AUTO_POSITION menyuruh replika memakai GTID, sehingga Anda tidak perlu mencatat nama berkas dan posisi binlog secara manual.

Langkah #4: Periksa dan pasang pemantauan

Jalankan SHOW REPLICA STATUS\G, lalu baca dua kolom lebih dulu: Replica_IO_Running dan Replica_SQL_Running. Keduanya harus bernilai Yes, dan bila salah satunya No, penyebabnya tercantum di kolom galat pada keluaran yang sama. Setelah berjalan, pasang peringatan untuk dua kondisi: salah satu utas berhenti, dan jeda melewati ambang yang Anda tetapkan.

Keluaran SHOW REPLICA STATUS pada replikasi MySQL: Replica_IO_Running dan Replica_SQL_Running keduanya Yes, jeda 0 detik.

Pertanyaan yang Sering Muncul

Apa bedanya replikasi database dan backup?

Replikasi menjaga salinan yang selalu mengikuti sumbernya, sehingga kesalahan pun ikut tersalin. Cadangan menyimpan potret data pada satu titik waktu dan sengaja tidak mengikuti perubahan berikutnya, sehingga Anda bisa kembali ke kondisi sebelum kesalahan terjadi. Keduanya menjawab kebutuhan berbeda dan sebaiknya dijalankan bersamaan.

Apakah replikasi otomatis membuat aplikasi lebih cepat?

Tidak dengan sendirinya. Replikasi menambah kapasitas baca, dan itu hanya membantu bila kelambatan aplikasi Anda memang berasal dari beban baca. Aplikasi juga harus diubah agar mengirim perintah baca ke replika. Untuk beban tulis yang berat, menambah replika justru menambah pekerjaan server sumber.

Berapa jumlah replika yang wajar untuk satu database?

Untuk sebagian besar aplikasi, satu replika sudah menutup kebutuhan ketersediaan, dan dua sampai tiga replika cukup untuk membagi beban baca. Melewati angka itu, biaya bertambah lebih cepat daripada manfaatnya. Sebagai pembanding, MySQL Group Replication membatasi satu grup pada sembilan anggota, dan MongoDB menganjurkan replica set dimulai dari tiga anggota.

Bisakah replikasi diatur lewat phpMyAdmin atau XAMPP?

Tidak. Keduanya adalah alat untuk mengelola isi database, bukan untuk mengatur perilaku server. Replikasi diatur di berkas konfigurasi MySQL (my.cnf atau my.ini) dan lewat perintah SQL tingkat server, serta menuntut dua instansi database yang terpisah. Menjalankan dua instansi di satu komputer memang bisa untuk belajar, tetapi tidak memberi manfaat ketersediaan apa pun.

Apa itu mirroring dan apa bedanya dengan replikasi?

Dalam konteks database, mirroring berarti mempertahankan satu salinan utuh yang identik dengan aslinya, sering kali dalam mode siaga yang tidak melayani pembacaan. Replikasi lebih luas: salinannya bisa banyak, bisa sebagian tabel saja, dan umumnya aktif melayani permintaan baca. Istilah mirroring juga dipakai di tingkat disk pada RAID 1, yang bekerja di bawah database.

Kesimpulan

Replikasi database adalah cara menyalin data ke server lain secara berkelanjutan, dengan tiga tingkat jaminan yang dapat Anda pilih dan dua arah aliran yang dapat Anda susun. Pasang replikasi ketika aplikasi Anda tidak boleh berhenti saat satu server mati, atau ketika beban baca sudah menekan satu mesin. Belum perlu memasangnya bila database Anda masih ringan dan waktu henti beberapa menit masih dapat diterima, karena Anda menambah dua kali biaya dan satu sistem lagi untuk dipantau.

Satu hal yang tidak boleh disalahpahami: replikasi menyalin kesalahan Anda secepat ia menyalin data yang benar. Ia bekerja berdampingan dengan cadangan berkala, bukan menggantikannya. Semoga artikel ini membantu.