Replikasikan data

Pertanyaan

Saat sebuah tulisan sudah dibalas "OK", berapa salinan yang sebenarnya sudah menyimpannya, dan apa yang hilang kalau leader mati sekarang?

Setelah baca ini, kamu bisa nelusurin alur tulis di replikasi leader/follower, nyebut kapan sebuah tulisan boleh dianggap durabel, dan nyatain berapa data yang bisa hilang pada tiap mode replikasi.

Prasyarat dan contoh

Kamu sudah paham invarians dan transaksi di satu node (M05) dan alasan data dipartisi (M07). Replikasi itu sumbu lain: partisi membagi data, replikasi menggandakannya.

Sebuah toko online punya satu database primary dan dua replika. Pembeli bayar, aplikasi nulis order 981: LUNAS ke primary, lalu primary balas sukses. Dua detik kemudian primary kehabisan disk dan mati. Replika yang dipromosikan ternyata belum punya order 981. Pembeli sudah dipotong uangnya, sistem tidak punya catatannya. Pertanyaannya bukan "apakah ada replika", tapi "tulisan itu sudah sampai ke berapa replika sebelum klien diberi jawaban".

Mekanisme

Alur leader/follower. Semua tulisan masuk ke satu leader. Leader menambahkan perubahan ke log urutan, lalu mengirim log itu ke follower. Follower memutar ulang perubahan dengan urutan yang sama. Pembacaan boleh dilayani follower, jadi kapasitas baca naik, tapi kapasitas tulis tetap sebesar satu leader.

klien ── tulis ──> leader ── log ──> follower A
                      │         └──> follower B
                      └── ack ──> klien   (kapan? itu intinya)

Sinkron vs asinkron. Beda keduanya cuma di titik ack:

• Asinkron: leader menulis lokal, langsung balas klien, lalu kirim ke follower. Latensi tulis kecil, tapi ada jendela di mana hanya leader yang punya data. Kalau leader mati di jendela itu, tulisan yang sudah diakui bisa hilang.
• Sinkron: leader menunggu follower mengonfirmasi sebelum balas. Tulisan yang diakui ada di minimal dua node. Harganya latensi tulis ikut tergantung follower paling lambat yang ditunggu, dan kalau follower itu mati, tulisan macet.

Semi-sinkron. Praktiknya sering campuran: tunggu satu dari dua follower, sisanya asinkron. Dengan begitu satu follower lambat tidak menghentikan tulisan, dan durabilitas tetap minimal dua salinan. Konfigurasi seperti synchronous_commit di PostgreSQL atau acks=all dengan min.insync.replicas di Kafka adalah variasi dari ide ini.

Durabilitas yang diakui. Tulisan "durabel" artinya ia selamat dari kegagalan yang kamu klaim tahan. Sebutkan kegagalannya: satu proses mati, satu mesin mati, satu zona mati. Dua salinan di rak yang sama tidak selamat dari rak mati. Tulisan di memori follower belum di-fsync juga belum durabel (M09 membahas ini).

Replication lag. Jarak antara posisi log leader dan posisi log follower, diukur dalam byte, jumlah entri, atau detik. Lag bukan konstanta: ia naik saat beban tulis melonjak, saat follower melakukan backup, atau saat jaringan antarzona padat.

Failover. Mengganti leader butuh tiga langkah: mendeteksi leader mati, memilih follower pengganti (yang paling mutakhir), dan mengarahkan klien serta follower lain ke leader baru. Deteksi berbasis timeout selalu bisa salah: leader yang lambat tampak seperti leader yang mati (dibahas di M08.06).

Saat rancangan ini gagal

• Mengira replika sama dengan backup. DROP TABLE yang salah ikut tereplikasi ke semua follower dalam hitungan milidetik. Replika menangani kematian mesin, bukan kesalahan manusia.
• Promosi follower yang tertinggal. Follower yang lag 8 detik dipromosikan, lalu leader lama hidup kembali dengan tulisan yang tidak ada di leader baru. Dua riwayat bercabang, dan salah satunya harus dibuang.
• Pembacaan dari follower yang diasumsikan terkini. Pengguna menyimpan profil, halaman dimuat ulang dari follower yang belum menerima tulisan, dan data lama muncul. Itu bukan bug replikasi, itu perilaku asinkron yang tidak dinyatakan (dibahas di M08.02).
• Sinkron ke semua follower. Satu follower yang sedang lambat membuat semua tulisan time out. Ketersediaan tulis jadi lebih buruk daripada satu node.

Contoh tandingan: replikasi sinkron ke satu follower di zona lain menaikkan latensi tulis dari 2 ms ke 14 ms, tapi menghilangkan kehilangan data saat satu zona mati. Untuk ledger pembayaran itu pertukaran yang benar. Untuk counter tayangan video, 14 ms dan satu follower yang bisa menahan tulisan jelas bukan pilihan yang masuk akal.

Latihan

Primary menerima 600 tulisan/detik dengan dua follower asinkron. Lag normal 100 ms, lag puncak 20 detik. Tim ingin target "tidak boleh kehilangan lebih dari 5 detik tulisan yang sudah diakui saat satu mesin mati". Apakah konfigurasi sekarang memenuhi target, dan apa perubahan minimalnya?

Lihat pembahasan+

Belum memenuhi. Pada lag puncak 20 detik, kerugian maksimum kira-kira 20 x 600 = 12.000 tulisan, setara 20 detik, empat kali target. Pada lag normal, kerugiannya sekitar 60 tulisan, jadi target terpenuhi hanya di waktu tenang.

Perubahan minimal: ubah satu follower menjadi sinkron (semi-sinkron, satu dari dua). Setiap tulisan yang diakui sudah ada di dua node, jadi kehilangan saat satu mesin mati turun ke nol untuk kegagalan satu mesin. Follower kedua tetap asinkron supaya satu follower lambat tidak menghentikan tulisan.

Harga yang harus disebut: latensi tulis naik sebesar round trip ke follower sinkron, dan kalau follower sinkron itu mati, sistem harus otomatis menukar follower sinkron ke yang lain, kalau tidak tulisan macet. Selain itu, kegagalan dua node sekaligus (misalnya satu zona yang memuat leader dan follower sinkron) tetap bisa menghilangkan data, jadi tempatkan follower sinkron di zona lain.

Jawaban yang bagus menghitung kerugian dari lag x laju tulis, bukan dari kata "asinkron", dan menyebut kegagalan yang tetap tidak tertahan.

Terkait

• M01.03 Tentukan sasaran yang berguna membantu menyatakan target kehilangan data sebagai angka.
• M08.02 Sebutkan jaminan konsistensi membahas apa yang dilihat pembaca saat follower tertinggal.
• M05 membahas transaksi di satu node, dan M09 membahas fsync serta WAL yang menentukan apakah satu salinan benar-benar durabel.
• Lab L08 memvisualkan lag, failover, dan hilangnya tulisan saat parameter replikasi diubah.

Catatan

• Asumsi: satu leader, replikasi berbasis log, kegagalan berupa crash dan bukan korupsi data.
• Yang tidak dibahas: replikasi multi-leader dan leaderless (quorum baca/tulis ala Dynamo), serta resolusi konflik.
• Angka latensi dan lag adalah contoh hitung, bukan patokan produk tertentu.
• Terakhir ditinjau: 26 Oktober 2026.