KAL
Menu

Replikasi

Pola leader-follower, failover, dan scaling pembacaan beserta risiko lag replikasinya.

Daftar isi

Replikasi adalah praktik menjaga salinan data yang sama pada beberapa mesin dengan menyalin setiap perubahan dari satu node utama ke node-node salinannya. Topik ini membahas pola leader-follower, cara meningkatkan kapasitas pembacaan dengan read replica, risiko lag replikasi, dan alur failover ketika leader mati. Sebuah simulasi Python memperlihatkan anomali baca akibat lag secara konkret, dan sebuah diagram menggambarkan arah aliran tulisan dan pembacaan.

Pola leader-follower#

Pada pola leader-follower, satu node bertindak sebagai leader, yaitu node yang menerima seluruh tulisan, sedangkan node lainnya bertindak sebagai follower yang menyimpan salinan data dan melayani pembacaan. Leader mencatat setiap perubahan ke log replikasi, misalnya write-ahead log pada basis data relasional atau oplog pada basis data dokumen, lalu follower menerapkan isi log tersebut berurutan. Follower dengan demikian mengikuti jejak leader dengan keterlambatan kecil yang disebut lag.

Susunan ini memberi tiga manfaat sekaligus. Pertama, data tersalin pada beberapa mesin, sehingga kerusakan satu mesin tidak menghilangkan data. Kedua, cadangan data dapat diambil dari follower tanpa membebani leader yang sedang melayani tulisan. Ketiga, pembacaan dapat didistribusikan ke beberapa follower, sebagaimana dibahas pada bagian berikutnya.

Diagram berikut menggambarkan arah aliran tulisan dan pembacaan pada topologi ini. Seluruh tulisan memasuki leader, sedangkan pembacaan dialihkan ke follower.

AplikasiLeaderFollower 1Follower 2menerima seluruh tulisantulislog replikasi (terjadi lag)log replikasibacabaca
Topologi leader-follower dengan dua follower

Scaling pembacaan#

Kebanyakan beban aplikasi web berat sebelah ke pembacaan, dan di sanalah replikasi memberikan ruang tumbuh yang paling langsung. Pembacaan dapat dibagi ke beberapa follower sehingga kapasitas baca bertambah seiring penambahan node, sedangkan follower yang ditujukan khusus untuk menyerap pembacaan lazim disebut read replica. Pembagian pembacaan dilakukan oleh pengarah query, misalnya proxy, yaitu komponen perantara yang berada di depan basis data, atau konfigurasi pada pustaka klien, sehingga aplikasi tidak perlu mengetahui alamat setiap node.

Kapasitas tulis, berbeda dengan kapasitas baca, tidak bertambah dengan menambah follower. Seluruh tulisan tetap memasuki satu leader, sehingga leader tetap menjadi titik tersibuk sekaligus titik tunggal yang harus dijaga. Setiap follower baru juga menambah beban pengiriman log replikasi pada leader dan jaringannya, sehingga penambahan follower bukan langkah yang sepenuhnya gratis. Jumlah follower yang kecil, misalnya dua hingga empat, sudah menyerap kebanyakan kebutuhan pembacaan.

Pembacaan juga tidak harus dibagi rata. Query yang berat dan tidak sensitif waktu, misalnya rekap statistik sensor untuk laporan, dapat diarahkan ke satu follower khusus agar tidak mengganggu pembacaan halaman aplikasi. Follower yang tertinggal jauh dapat dikeluarkan sementara dari pembagian pembacaan sampai lagnya menyusut, sehingga kualitas jawaban tetap terjaga.

Lag replikasi dan anomali baca#

Lag replikasi adalah selisih antara perubahan yang sudah diterapkan pada leader dan perubahan yang sudah diterapkan pada follower. Karena penerapan pada follower umumnya asinkron, pihak yang menulis ke leader lalu langsung membaca dari follower dapat melihat data lama. Anomali ini dikenal sebagai pelanggaran read-your-writes, yaitu jaminan bahwa tulisan yang baru dibuat terlihat pada pembacaan berikutnya.

Simulasi berikut memodelkan follower yang tertinggal tiga langkah penerapan, kemudian menghitung antrean replikasi ketika laju penerapan di bawah laju tulisan.

python simulasi-lag.py 
"""Simulasi lag replikasi pada pola leader-follower.

Bagian pertama memperlihatkan anomali baca setelah tulis: klien menulis
ke leader lalu langsung membaca dari follower yang tertinggal LAG
langkah penerapan, sehingga tulisan terbarunya belum terlihat.

Bagian kedua memperlihatkan pertumbuhan antrean replikasi ketika laju
penerapan log pada follower berada di bawah laju tulisan leader.
"""

LAG = 3                # follower tertinggal tiga langkah penerapan log
TULIS_PER_DETIK = 10   # laju tulisan yang diterima leader
TERAP_PER_DETIK = 8    # laju penerapan log pada follower

print("Bagian 1: baca setelah tulis pada follower yang tertinggal")
for t in range(1, 7):
    tulisan = f"pesan-{t}"
    posisi_follower = t - LAG
    if posisi_follower >= 1:
        terlihat = f"pesan-{posisi_follower}"
        ket = f"basi, tertinggal {LAG} langkah"
    else:
        terlihat = "(kosong)"
        ket = "basi, tulisan pertama belum diterapkan"
    print(f"  t={t}  tulis={tulisan}  baca dari follower={terlihat}  ({ket})")

print()
print("Bagian 2: antrean replikasi saat penerapan lebih lambat dari tulisan")
for detik in (1, 5, 10, 30, 60):
    antrean = (TULIS_PER_DETIK - TERAP_PER_DETIK) * detik
    print(f"  detik {detik:2d}: {antrean:3d} tulisan belum diterapkan di follower")
text Keluaran 
Bagian 1: baca setelah tulis pada follower yang tertinggal
  t=1  tulis=pesan-1  baca dari follower=(kosong)  (basi, tulisan pertama belum diterapkan)
  t=2  tulis=pesan-2  baca dari follower=(kosong)  (basi, tulisan pertama belum diterapkan)
  t=3  tulis=pesan-3  baca dari follower=(kosong)  (basi, tulisan pertama belum diterapkan)
  t=4  tulis=pesan-4  baca dari follower=pesan-1  (basi, tertinggal 3 langkah)
  t=5  tulis=pesan-5  baca dari follower=pesan-2  (basi, tertinggal 3 langkah)
  t=6  tulis=pesan-6  baca dari follower=pesan-3  (basi, tertinggal 3 langkah)

Bagian 2: antrean replikasi saat penerapan lebih lambat dari tulisan
  detik  1:   2 tulisan belum diterapkan di follower
  detik  5:  10 tulisan belum diterapkan di follower
  detik 10:  20 tulisan belum diterapkan di follower
  detik 30:  60 tulisan belum diterapkan di follower
  detik 60: 120 tulisan belum diterapkan di follower

Bagian pertama keluaran menunjukkan bahwa setiap pembacaan dari follower, yang dilakukan segera setelah tulisan, selalu basi karena follower masih menerapkan log tiga langkah di belakang leader. Bagian kedua memperlihatkan pola yang lebih mengkhawatirkan, yaitu bila laju penerapan follower berada di bawah laju tulisan leader, antrean bertambah dua tulisan tiap detik dan tidak pernah menyusut. Lag yang dibiarkan membesar berujung pada follower yang basi berjam-jam, sehingga lag perlu dipantau sebagai metrik utama dan dibatasi dengan ambang.

Mitigasi anomali baca tersedia pada beberapa lapis. Pembacaan data yang baru ditulis dapat diarahkan ke leader, klien dapat dipin ke follower yang sama untuk beberapa saat setelah menulis, dan pengarah query dapat menunggu follower mencapai posisi log tertentu sebelum menyodorkan pembacaan. Semua mitigasi menambah kerumitan, sehingga hanya data yang benar-benar sensitif yang diperlakukan khusus.

Failover#

Failover adalah proses mengganti leader yang mati dengan follower yang dipromosikan, sehingga tulisan dapat berlanjut tanpa intervensi panjang. Alur umumnya bergerak dalam tiga langkah berikut.

  1. Sistem mendeteksi leader tidak merespons dalam ambang waktu, misalnya lewat health check, yaitu pemeriksaan kesehatan berkala antarnode.
  2. Salah satu follower dipromosikan menjadi leader baru, dan kandidat yang dipilih biasanya follower dengan lag paling kecil.
  3. Klien diarahkan ke leader baru, sedangkan follower lain mengalihkan langganannya ke leader baru tersebut.

Promosi follower yang tertinggal memiliki konsekuensi yang harus disadari sejak desain. Pada replikasi asinkron, tulisan terakhir yang belum tersalin ke follower akan hilang ketika follower itu dipromosikan, sehingga kehilangan sebagian tulisan adalah kemungkinan yang nyata. Replikasi semisinkron, yang menahan konfirmasi tulisan hingga sekurang-kurangnya satu follower menerimanya, memperkecil jendela kehilangan tersebut dengan harga latensi tulis yang lebih tinggi. Risiko lain yang jarang disadari adalah split brain, yaitu kondisi dua node sama-sama menganggap dirinya leader, yang dicegah dengan kuorum pengambilan keputusan.

Kesalahan umum#

Tiga kesalahan berikut paling sering muncul ketika replikasi baru dipasang di production, yaitu lingkungan yang melayani pengguna sebenarnya.

  • Membaca dari follower segera setelah menulis, tanpa memperhitungkan lag. Anomalinya sulit dideteksi pada pengujian karena lag di lingkungan uji kecil, tetapi muncul saat trafik nyata. Perbaikannya, arahkan pembacaan data yang baru ditulis ke leader atau pin klien ke follower yang sudah menerapkan tulisan tersebut.
  • Menganggap replikasi sebagai pengganti cadangan data. Perintah penghapusan yang keliru ikut tereplikasi ke semua follower dengan setia, sehingga data hilang di semua salinan pada saat yang sama. Cadangan berkala yang disimpan terpisah tetap dibutuhkan.
  • Menambah follower tanpa memantau lag. Pembacaan menjadi makin basi saat antrean replikasi membesar, dan perbaikannya adalah memantau lag serta menambah kapasitas leader dan jaringan bersamaan dengan penambahan follower.
  • Membiarkan lag tanpa ambang pada failover. Promosi follower yang basi memperluas jendela kehilangan tulisan, dan perbaikannya adalah membatasi kandidat promosi pada follower dengan lag di bawah ambang yang ditetapkan.

Ringkasan#

  • Leader menerima seluruh tulisan dan menerbitkan log replikasi, sedangkan follower menerapkan log tersebut sehingga data tersalin pada beberapa mesin.
  • Pembacaan dapat disebar ke read replica, tetapi kapasitas tulis tetap dibatasi satu leader dan setiap follower baru menambah beban lognya.
  • Lag replikasi membuat pembacaan setelah tulisan pada follower menghasilkan data basi, sehingga lag dipantau dan pembacaan sensitif diarahkan ke leader.
  • Failover mempromosikan follower menjadi leader, dan pada replikasi asinkron tulisan terakhir dapat hilang pada proses tersebut.

Referensi#