Belajar Vitess - Replikasi & Failover

#Pendahuluan

Database tanpa ketersediaan hanyalah gudang data. Episode 6 membahas bagaimana Vitess menjaga data tetap tersedia saat hardware rusak, proses mati, atau node reboot: lewat replikasi (salinan data) dan failover (perpindahan peran primary). Ini adalah perbedaan besar antara Vitess dan MySQL vanilla — failover di Vitess otomatis dan dirancang untuk meminimalkan downtime.

Roadmap episode 6: topologi replika dan peran primary, failure detection, failover otomatis dengan vtctld dan pseudo-GTID, lalu strategi backup dan recovery. Akhir episode, kalian paham apa yang terjadi di balik layar saat primary mati.

#Topologi Replika dan Peran Primary

Dalam satu shard, ada satu primary (menerima tulis dan baca) dan beberapa replica (menyalin tulis dari primary via binlog, melayani baca dan backup). Vitess menyebut peran ini sebagai tablet type: PRIMARY, REPLICA, dan RDONLY.

vtctlclient ListAllTablets

Output vtctlclient ListAllTablets menampilkan setiap tablet dengan tipe perannya. Satu shard 0 yang sehat biasanya memiliki satu tablet primary dan satu atau lebih replica.

Perbedaan REPLICA dan RDONLY: keduanya membaca data yang sama, tapi REPLICA dianggap bisa dijadikan primary (promotable), sedangkan RDONLY secara eksplisit tidak boleh dipromosikan — cocok untuk workload baca berat seperti reporting yang tidak boleh mengganggu jalur failover. Vitess mengarahkan traffic baca ke replica lewat VTGate, dan aplikasi bisa meminta "read after write consistency" untuk memastikan baca lewat replica tidak ketinggalan data.

Peran sebuah tablet tidak permanen — ia bisa diubah sesuai kebutuhan. Misalnya, saat beban reporting naik, kalian bisa mengubah tablet REPLICA menjadi RDONLY, atau sebaliknya. Vitess menangani transisi ini tanpa menghentikan layanan tablet tersebut.

vtctlclient ChangeTabletType <tablet-alias> RDONLY

Perintah vtctlclient ChangeTabletType mengubah peran tablet — alat yang berguna saat menyesuaikan distribusi beban baca tanpa menambah instance baru. Meski begitu, ingatlah bahwa mengubah semua REPLICA menjadi RDONLY akan menghilangkan kandidat failover, jadi selalu sisakan setidaknya satu REPLICA per shard.

#Failure Detection dan Automatic Failover

Saat primary mati, tulis berhenti — dan setiap detik downtime adalah kerugian. Vitess mendeteksi kegagalan dengan memantau health tablet secara berkala. Pemantauan dilakukan oleh beberapa pihak: vtctld memantau health lewat Topology Service, dan VTGate memantau health setiap tablet yang dipakainya.

Deteksi kegagalan bukan berarti langsung failover. Ada masa grace period — waktu tunggu untuk memberi kesempatan primary kembali sebelum memicu failover. Tujuannya menghindari failover yang tidak perlu saat network cuma delay sekejap.

Saat failover dipicu, urutan kejadiannya kira-kira begini:

1. Health monitoring menandai primary sebagai tidak sehat.
2. Setelah grace period, vtctld memilih replica terbaik sebagai pengganti.
3. Replica terpilih menjalankan EmergencyReparentShard dan diangkat jadi primary.
4. Tablet primary lama (jika hidup kembali) akan di-demote menjadi replica dan mengejar ketinggalan.

#Pseudo-GTID dan Mekanisme Ikut Data

Ini bagian paling teknis dan menarik. MySQL tradisional mereplikasi dengan file position (binlog file + binlog pos). Masalahnya, setelah failover, replica baru mungkin berada di posisi yang tidak cocok dengan replica lain — posisi file relatif terhadap primary lama, bukan data itu sendiri.

Vitess memakai pseudo-GTID: sebuah mekanisme untuk menemukan posisi replikasi berdasarkan konten data, bukan posisi file. Setiap beberapa ribu transaksi, Vitess menyisipkan baris unik yang bisa dicari. Dengan ini, Vitess bisa menemukan dengan tepat sampai ke transaksi mana sebuah tablet sudah mereplikasi — persis, dan mandiri dari file position.

Pseudo-GTID membuat resharding dan reparenting jauh lebih andal: Vitess bisa menyambungkan replikasi dari satu tablet ke tablet lain tanpa khawatir melompati atau mengulang transaksi.

vtctlclient PlannedReparentShard -keyspace_shard=commerce/0 \
  -new_primary=<tablet-alias>

Perintah vtctlclient PlannedReparentShard memindahkan peran primary ke tablet baru secara terencana — aplikasi hanya merasakan jeda singkat saat transisi.

#Strategi Backup dan Recovery

Failover menangani kegagalan instan. Untuk bencana yang lebih besar — misalnya semua node di sebuah availability zone mati — kalian butuh backup. Vitess menyediakan backup engine yang berjalan lewat VTTablet, menyimpan snapshot data ke object storage (misalnya GCS, S3, atau Azure Blob).

Alur backup di Vitess:

• Satu tablet REPLICA atau RDONLY dipilih untuk mengambil backup, sehingga primary tidak terganggu.
• VTTablet memakai mysqlbackup atau tool lain untuk membuat snapshot konsisten.
• Snapshot dikirim ke lokasi penyimpanan yang dikonfigurasi di vtctld.

Untuk memicu backup manual:

vtctlclient Backup <tablet-alias>

Restore dilakukan saat tablet di-bootstrap atau saat membuat tablet baru: Vitess mendeteksi backup terbaru, me-restore, lalu mengejar ketinggalan replikasi dari primary. Pilihan lokasi penyimpanan backup harus disiapkan saat install — helm install Vitess mengharuskan kalian menentukan bucket backup.

#Durability Policy dan Semi-sync

Salah satu keputusan penting dalam failover adalah kebijakan durability: seberapa yakin data tulis sudah aman sebelum VTGate mengembalikan sukses ke aplikasi. Vitess mendukung berbagai kebijakan:

• none — tulis dianggap sukses setelah masuk primary, tanpa jaminan replikasi. Tercepat, tapi risikonya tinggi.
• semi_sync — tulis menunggu setidaknya satu replica mengakui sebelum sukses. Paling umum dipakai: mengorbankan sedikit latensi untuk keamanan failover yang jauh lebih baik.
• none dengan RPO — kombinasi yang perlu disadari tim: tanpa semi-sync, failover bisa kehilangan transaksi terakhir yang belum ter-replikasi.

vtctlclient GetKeyspaceDurabilityPolicy commerce

vtctlclient GetKeyspaceDurabilityPolicy menampilkan kebijakan durability keyspace. Pilihan ini berdampak langsung pada RPO (seberapa banyak data boleh hilang saat failover) — temui nanti di episode 14 dan 20.

#Penutup

Pada episode 6 ini kalian sudah memahami topologi primary dan replica di Vitess, mekanisme deteksi kegagalan dan failover otomatis lewat PlannedReparentShard dan EmergencyReparentShard, peran pseudo-GTID dalam mengikuti posisi replikasi secara akurat, serta strategi backup dan recovery berbasis object storage.

Inti yang harus dibawa pulang:

• Satu shard punya satu primary dan beberapa replica dengan tipe REPLICA dan RDONLY.
• RDONLY tidak boleh dipromosikan; ia untuk workload baca berat.
• Failover punya grace period agar tidak gagal di deteksi yang salah.
• Pseudo-GTID memakai konten data, bukan posisi file, untuk menemukan titik replikasi.
• PlannedReparentShard untuk maintenance, EmergencyReparentShard untuk darurat.
• Backup dari replica, simpan ke object storage, dan uji restore secara rutin.

Di episode 7 berikutnya kita pasang mata dan telinga: observability dan debugging — metrics Prometheus dari VTGate dan VTTablet, log patterns, slow query tracing, dan diagnosa shard dengan vtctlclient. Sampai jumpa!