Belajar Database Administrator - Migration & Upgrade

#Pendahuluan

Database yang kita bangun di episode 3-10 akhirnya harus tumbuh: versi menua, teknologi berganti, atau bisnis pindah cloud. Migration & upgrade adalah pekerjaan berisiko tinggi — di sinilah reputasi DBA dibangun atau hancur. Kabar baiknya: semua risiko bisa dikelola dengan metode, uji, dan rencana rollback.

Prinsip yang memandu episode ini: migration is a project, not a command. Jangan pernah menjalankan upgrade karena "kesannya harus" — tulis rencana, uji di staging, jalankan di window yang disepakati, dan selalu siap jalan mundur.

#Upgrade Major Version PostgreSQL

Upgrade major (misal 15 → 16) tidak bisa dilakukan dengan apt upgrade begitu saja — data directory dan format fisik berubah. Cara resmi: pg_upgrade.

Langkah 1 — persiapan: install versi baru di samping yang lama, cek kompatibilitas extension.

Langkah 2 — backup lengkap (episode 5): ini jaring pengaman terpenting. Tanpa backup yang teruji, jangan mulai.

Langkah 3 — jalankan pg_upgrade:

sudo -u postgres /usr/lib/postgresql/16/bin/pg_upgrade \
    -b /usr/lib/postgresql/15/bin -B /usr/lib/postgresql/16/bin \
    -d /var/lib/postgresql/15/main -D /var/lib/postgresql/16/main \
    --link -j 4

Flag --link memakai hardlink sehingga upgrade hampir instan — tapi wajib backup dulu karena data lama dan baru berbagi file. -j 4 memparalelkan dengan 4 core.

Langkah 4 — verifikasi & cutover: jalankan vacuumdb --all --analyze-in-stages, tes query produksi, lalu geser service.

Catatan penting: upgrade major wajib menguji semua query kritis karena perencana kueri bisa berubah. Sertakan regresi performansi dalam uji.

#Migrasi Antar Engine

Migrasi antar engine (misal MySQL → PostgreSQL) jauh lebih menantang: tipe data berbeda, syntax berbeda, dan perilaku autentikasi berbeda. Jangan pernah berharap script otomatis sempurna.

Proses yang benar:

1. Inventory: daftar semua tabel, view, trigger, stored procedure, dan extension yang dipakai.
2. Skema: terjemahkan DDL ke target (MySQL INT AUTO_INCREMENT → PostgreSQL IDENTITY, ENUM → CHECK/tipe enum, dll).
3. Data: alat seperti pgloader untuk bulk transfer dengan map tipe otomatis:

pgloader mysql://user:pass@mysql/appdb \
        postgresql://user@postgres/appdb

4. Aplikasi: query dan driver berubah — uji aplikasi, bukan hanya data.
5. Validasi: bandingkan jumlah baris & checksum per tabel (lihat bagian validasi di bawah).

Kesalahan tersembunyi yang sering muncul: TEXT vs VARCHAR, perilaku ORDER BY NULL, waktu zona (TIMESTAMP vs TIMESTAMPTZ), dan case-sensitivity string. Daftar ini wajib masuk checklist.

#Strategi Zero-Downtime Migration

Migrasi besar tidak harus berarti downtime. Pola yang paling terbukti: dual-write + cutover bertahap.

Langkahnya:

1. Setup DB baru dan aktifkan dual-write: aplikasi menulis ke dua database sekaligus (via code atau CDC/message queue).
2. Backfill data historis; alat sinkronisasi meneruskan delta (misal debezium untuk CDC).
3. Validasi terus-menerus: bandingkan data lama vs baru.
4. Cutover bertahap: pindahkan baca dulu, lalu tulis, pada jendela di mana selisih data sudah nol.
5. Keep-alive DB lama selama masa transisi, lalu teardown.

Keuntungannya: setiap langkah bisa dibalik. Jika cutover baca bermasalah, aplikasi tinggal diarahkan kembali ke DB lama — tanpa kehilangan data apa pun.

#Validasi Data Pasca-Migrasi

Migrasi dikatakan sukses hanya jika data terbukti utuh. Dua lapis validasi yang wajib:

1. Perbandingan kuantitatif — jumlah baris per tabel:

SELECT 'orders' AS tbl, count(*) FROM orders
UNION ALL SELECT 'users', count(*) FROM users;

2. Perbandingan isi — checksum untuk memastikan tidak ada korupsi halus:

# di database lama
pg_dump -t orders --data-only --schema-only ... > orders_old.sql
# di database baru
pg_dump -t orders --data-only --schema-only ... > orders_new.sql
sha256sum orders_old.sql orders_new.sql

Untuk dataset besar, bandingkan per range: WHERE id BETWEEN $a AND $b dipecah per blok, lalu hitung count(*) dan md5(string_agg(...)) per blok — kesalahan kecil pun ketahuan.

Checklist validasi tambahan: cek count(*) semua tabel, cek sequence/identity tidak reset, cek foreign key terpenuhi (NOT VALID FK), dan jalankan beban aplikasi di staging untuk membandingkan latensi.

#Pitfall Umum

1. Upgrade tanpa backup teruji: satu-satunya jaring pengaman kalian — jangan pernah skip.
2. Migrasi tanpa test plan aplikasi: data utuh tapi query aplikasi rusak = migrasi gagal juga.
3. Dual-write tanpa validasi kontinu: menumpuk data tak sinkron tanpa sadar sampai cutover.
4. Lupa --link membuat upgrade lama: pg_upgrade tanpa --link menyalin semua file — puluhan menit untuk database besar.
5. Tanpa rollback plan: keputusan sebelum migrasi: "kalau gagal, apa yang kita lakukan?" — tulis, latih, jalankan.

#Penutup

Inti yang harus dibawa pulang:

• Upgrade major PostgreSQL memakai pg_upgrade --link + backup teruji + uji query kritis.
• Migrasi antar engine: inventory → skema → data (pgloader) → aplikasi → validasi.
• Zero-downtime = dual-write + backfill + validasi + cutover bertahap + batas waktu transisi.
• Validasi ganda: count(*) per tabel + checksum isi per blok; rollback plan wajib ada.

Di episode 12 selanjutnya kita pindah ke langit: managed cloud databases — provisioning RDS/Aurora, Cloud SQL, dan Azure SQL, memahami networking VPC, backup otomatis, dan read replicas di cloud, serta memigrasi database on-prem ke managed service. Sampai jumpa di episode 12!