Belajar Vitess - Control Plane & Topology Management

#Pendahuluan

Topology Service adalah sistem saraf Vitess — semua keputusan routing bergantung pada metadata yang disimpannya. Episode 18 membahas lapisan kontrol ini secara mendalam: memilih backend yang tepat, menjaga datanya tetap sehat, memperbaikinya saat korup, dan mengotomatisasi operasi lewat vtctld.

Roadmap episode 18: pilihan Topology Service, operasi topologi sehari-hari, repair dan backup topologi, lalu vtctld UI dan automation. Akhir episode, kalian bisa mengelola "otak" cluster Vitess dengan percaya diri.

#Topology Service: etcd, ZooKeeper, Consul

Vitess mendukung tiga backend untuk Topology Service:

etcd — pilihan default dan paling umum. Dikenal dari ekosistem Kubernetes, stabil untuk cluster kecil hingga besar. Default Helm chart Vitess.
ZooKeeper — backend historis Vitess, dipakai sejak masa YouTube. Stabil dan teruji, tapi setup-nya lebih berat.
Consul — opsi lain dengan fitur service discovery yang sudah terintegrasi.

Pilihannya jarang menjadi keputusan performa murni; yang lebih sering dipertimbangkan adalah keterampilan tim dan ekosistem yang sudah ada. Untuk lab dan kebanyakan production modern, etcd adalah pilihan yang masuk akal.

Info

Topology Service bukan tempat menyimpan data bisnis — hanya metadata: keyspace, shard, tablet, dan kebijakan. Ukurannya kecil, tapi ketersediaannya kritis. Perhatikan beban yang rendah namun peran yang sangat penting.

Memeriksa endpoint topology yang sedang dipakai:

Menampilkan konfigurasi topology

vtctlclient GetTopologyInfo

vtctlclient GetTopologyInfo menampilkan global topology dan cell yang terdaftar — gambaran peta cluster dari sisi control plane.

#Operasi Topologi Sehari-hari

Operasi topologi yang paling sering dilakukan lewat vtctlclient:

Operasi topology umum

vtctlclient ListAllKeyspaces
vtctlclient ListAllTablets
vtctlclient ListShardHealth
vtctlclient GetKeyspace commerce
vtctlclient GetShard commerce/0

vtctlclient GetShard menampilkan detail satu shard: tablet primary, replica, dan konfigurasinya. Operasi ini read-only dan aman dijalankan kapan saja.

Perintah yang mengubah state topologi — CreateShard, DeleteShard, InitShardMaster — harus digunakan hati-hati dan idealnya lewat workflow terencana, bukan saat produksi.

#Repair dan Backup Topologi

Topologi bisa rusak karena kegagalan penyimpanan, bug, atau kesalahan manusia. Gejalanya: tablet "hilang", keyspace tidak konsisten, atau VTGate tidak bisa menemukan shard. Alat utamanya:

vtctlclient dengan flag yang tepat untuk memperbaiki entry yang salah.
DeleteTablet untuk menghapus tablet yang sudah tidak ada.
Reparenting untuk mengembalikan konsistensi peran setelah kegagalan.

Menghapus tablet yang tidak valid

vtctlclient DeleteTablet -allow_master <tablet-alias>

vtctlclient DeleteTablet menghapus tablet dari topologi. Gunakan -allow_master hanya jika yakin tablet itu memang harus dihapus — misalnya data fisiknya sudah hilang.

Backup topologi sangat penting: jika data topologi hilang, cluster kehilangan peta — lebih parah dari kehilangan data bisnis karena tidak ada yang bisa merutekan. etcd memiliki snapshot sendiri:

Backup snapshot etcd

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=http://etcd:2379

etcdctl snapshot save menyimpan snapshot etcd. Di Vitess yang dikelola Helm, etcd biasanya di-deploy sebagai StatefulSet — pastikan snapshot diambil secara rutin dan diuji restorinya.

Warning

Tanpa backup topologi yang bisa di-restore, bencana di etcd berarti harus membangun ulang peta cluster secara manual — proses yang rawan kesalahan. Perlakukan backup topologi sepenting backup data MySQL.

#vtctld UI dan Automation

vtctld tidak hanya API; ia punya web UI yang menampilkan state cluster secara visual: keyspace, shard, tablet, dan health. Akses UI lewat port-forward:

Membuka vtctld UI

kubectl port-forward -n vitess svc/vtctld 15000:15000 &
open http://localhost:15000

kubectl port-forward ... svc/vtctld membuka UI vtctld di port 15000. Dari sini kalian bisa melihat peta cluster dan menavigasi antar shard tanpa mengetik perintah.

Untuk automation, semua yang bisa dilakukan di UI juga bisa lewat API dan vtctlclient. Otomatisasi biasa yang diterapkan:

Health check terjadwal lewat script yang memanggil ListShardHealth.
Alerting yang memicu perintah perbaikan otomatis.
Pipeline CI/CD yang memanggil vtctlclient untuk apply schema dan topology (episode 19).

Script health check sederhana

vtctlclient ListShardHealth -format json | \
  grep -E '"(Master|Replica)"|"State"' | head -20

Perintah vtctlclient ListShardHealth -format json menghasilkan output JSON yang bisa di-parse oleh automation — cara umum mengekstrak status untuk monitoring.

#Penutup

Pada episode 18 ini kalian sudah memahami control plane Vitess: memilih Topology Service antara etcd, ZooKeeper, dan Consul, menjalankan operasi topologi sehari-hari, memperbaiki dan mem-backup topologi, serta memakai vtctld UI dan otomatisasi untuk mengelola state cluster.

Inti yang harus dibawa pulang:

etcd adalah pilihan default yang wajar; ZooKeeper dan Consul adalah alternatif.
Topologi kecil ukurannya tapi kritis ketersediaannya.
Operasi baca topologi aman; operasi tulis harus terencana.
Backup topologi wajib dan harus diuji restorinya, sepenting backup data.
vtctld UI memberikan pandangan visual cluster yang berguna untuk navigasi.
Otomatisasi lewat output JSON vtctlclient memungkinkan health check terjadwal.

Di episode 19 berikutnya kita rapikan alur pengiriman: CI/CD dan release management — GitOps untuk konfigurasi Vitess, pipeline CI/CD, versioning schema change, rolling upgrades, dan testing di staging. Sampai jumpa!