Belajar Vitess - Schema Change & Online Migrations

#Pendahuluan

Di dunia Vitess, mengubah skema tidak bisa dilakukan dengan menekan Enter di satu server. Tabel tersebar di banyak shard, dan setiap shard punya MySQL sendiri. ALTER TABLE biasa pada tabel besar akan mengunci tabel dan membuat downtime yang tidak bisa diterima. Episode 10 membahas cara mengubah skema dan memigrasi data dengan aman, tanpa memutus layanan.

Roadmap episode 10: mengapa online migration diperlukan, mesin di baliknya (VReplication dan online schema change), workflow vtctlclient, serta checklist migrasi zero-downtime.

#Mengapa Online Migration Diperlukan

Bayangkan tabel dengan ratusan juta baris. Menjalankan ALTER TABLE ADD COLUMN langsung akan mengunci tabel selama proses — di MySQL, banyak ALTER memakai MDL (metadata lock) atau menulis ulang tabel. Selama itu, aplikasi tidak bisa menulis, dan di workload 24/7 itu bencana.

Vitess menyediakan tiga jalur untuk schema change:

• DDL langsung lewat VTGate — hanya aman untuk perubahan ringan.
• Online Schema Change (OSC) — memakai mekanisme seperti gh-ost atau pt-osc via vreplication untuk menjalankan ALTER tanpa mengunci tabel lama.
• VReplication-based migration — membuat tabel baru dengan skema baru, menyalin data secara bertahap, lalu memotong traffic.

#Online Schema Change

Vitess mendukung menjalankan ALTER lewat mekanisme online. Caranya: kirim DDL dengan hint khusus via VTGate, dan Vitess menjalankannya sebagai online operation menggunakan vreplication:

ALTER TABLE users ADD COLUMN bio varchar(500)

Perintah di atas dikirim lewat VTGate dengan opsi online. Vitess menciptakan tabel sementara, menyalin data sedikit demi sedikit sambil memantau replikasi, lalu memotong ke skema baru. Aplikasi tidak pernah kehilangan akses tulis.

Untuk memantau migrasi online yang sedang berjalan:

vtctlclient OnlineDDL Show all

vtctlclient OnlineDDL Show menampilkan daftar migrasi online, statusnya (queued, running, complete, atau failed), dan progres tiap shard.

#VReplication dan Alur Migrasi Data

VReplication adalah mesin penyalin data berbasis binlog yang menjadi tulang punggung migrasi data Vitess: resharding (episode 16), migrasi antar keyspace, dan online schema change semuanya memakainya. Cara kerjanya:

1. Vitess membuat aliran VReplication dari sumber ke target.
2. Data awal disalin dengan snapshot konsisten.
3. Perubahan yang terjadi setelah snapshot ditangkap dari binlog.
4. Target mengejar ketinggalan sampai near-zero lag.
5. Traffic dipindahkan dan aliran dihentikan.

Karena migrasi berjalan bertahap, aplikasi tidak pernah berhenti — inilah inti zero-downtime migration.

vtctlclient VReplicationExec -json <tablet-alias> "select * from _vt.vreplication"

vtctlclient VReplicationExec menjalankan query langsung ke tabel _vt.vreplication di tablet — tabel internal yang menyimpan status setiap aliran VReplication.

#Workflow vtctlclient untuk Migrasi

Vitess mengemas alur migrasi lewat workflow. Contoh workflow migrasi keyspace (MoveTables) atau penggabungan shard (ShardMerge). Alur khasnya:

1. Buat workflow: vtctlclient MoveTables -source=... -tables=... commerce users
2. Pantau progres: vtctlclient VReplicationExec ... status
3. Tunggu lag mendekati nol.
4. Switch read dan write traffic: vtctlclient SwitchTraffic
5. Selesaikan dan bersihkan: vtctlclient Complete

vtctlclient MoveTables --source=commerce --tables=orders --target=users create order_move
vtctlclient Workflow --keyspace=users show order_move
vtctlclient MoveTables --source=commerce --target=users order_move switchtraffic
vtctlclient MoveTables --source=commerce --target=users order_move complete

Perintah vtctlclient Workflow ... show menampilkan status workflow — langkah mana yang sudah selesai dan berapa lag replikasi tersisa.

#Checklist Migrasi Zero-downtime

Sebelum menjalankan migrasi besar di produksi, siapkan checklist ini:

• Backup: pastikan backup terbaru tersedia sebelum migrasi.
• Dry run di staging: jalankan migrasi penuh di environment staging dengan data yang mirip.
• Pantau lag: jangan switch sebelum lag replikasi mendekati nol.
• Rencana rollback: tahu persis langkah membatalkan migrasi jika gagal di tengah jalan.
• Jendela waktu: pilih waktu traffic rendah untuk migrasi besar.
• Komunikasi: beri tahu tim terkait bahwa migrasi sedang berjalan.

#Penutup

Pada episode 10 ini kalian sudah memahami cara mengubah skema dan memigrasi data tanpa downtime: DDL langsung hanya untuk perubahan ringan, online schema change untuk ALTER tabel besar, VReplication sebagai mesin penyalinan data, serta alur workflow MoveTables dengan tahap create, switch, dan complete.

Inti yang harus dibawa pulang:

• DDL langsung hanya aman untuk perubahan skema ringan.
• Online schema change memakai VReplication agar ALTER tidak mengunci tabel.
• VReplication menyalin snapshot lalu mengejar ketinggalan dari binlog.
• Workflow migrasi: create, pantau lag, switchtraffic, complete.
• vtctlclient Workflow show adalah alat pantau status migrasi.
• Selalu backup, dry run di staging, dan punya rencana rollback.

Di episode 11 berikutnya kita urus konfigurasi dan rahasia: configuration management dan secrets — kustomisasi Helm dan ConfigMaps, manajemen secrets untuk kredensial MySQL dan topology, serta validasi dan rollback perubahan produksi. Sampai jumpa!