Migrasi Database Lokal ke Cloud tanpa Downtime

TL;DR

• Migrasi database tanpa downtime penuh bergantung pada pengendalian write path, bukan hanya copy data awal.
• Compatibility check, replication lag, dan rollback decision point harus ditetapkan sebelum cutover.
• Migration plan yang baik selalu mengasumsikan ada service tersembunyi yang masih memegang koneksi lama.

Pendahuluan

Migrasi database dari lingkungan lokal ke cloud sering dipresentasikan seperti pekerjaan mekanis: export, import, ubah connection string, selesai. Dalam sistem yang benar-benar dipakai, cara itu terlalu berbahaya. Begitu ada traffic tulis aktif, background job, dan integrasi ke beberapa service, setiap menit downtime terasa mahal dan setiap inconsistency sulit dijelaskan.

Target migrasi yang sehat bukan nol risiko, tetapi cutover yang terkendali. Artinya kita harus memahami write path, urutan dependency, dan kapan dual-state harus dihindari. Banyak migrasi gagal bukan karena teknologi cloud-nya buruk, melainkan karena tim meremehkan perilaku aplikasi saat sumber data berpindah.

Prerequisites

• Source database dan target cloud database harus berada pada versi mayor yang kompatibel.
• Akses admin ke source dan target.
• Observability dasar tersedia: replication lag, query latency, connection count.
• Daftar lengkap service, worker, cron, dan batch job yang memakai database.
• Maintenance window kecil yang sudah dikomunikasikan.

Problem di Production

Tim sering fokus pada mekanisme export/import dan lupa bahwa aplikasi terus menulis. Begitu worker, cron job, dan integrasi lain belum sepenuhnya diarahkan ulang, sumber data bisa terbelah diam-diam. Masalah semacam ini lebih mahal daripada downtime singkat karena inkonsistensinya sulit direkonstruksi.

Mental Model

Gunakan mental model state transition. Source database adalah sumber kebenaran saat ini, target cloud adalah calon sumber baru, dan cutover adalah perpindahan otoritas. Selama otoritas belum dipindah dengan eksplisit, sistem harus tahu siapa yang masih boleh menerima write.

Konsep Utama

Cutover adalah masalah perubahan state

Database migration bukan sekadar pemindahan data awal. Tantangan utamanya adalah bagaimana menangani perubahan baru yang terus masuk sambil target baru dikejar agar tetap sinkron.

Kompatibilitas aplikasi lebih penting daripada alat migrasi

Tool replikasi mungkin bekerja baik, tetapi jika aplikasi bergantung pada extension tertentu, timezone, collation, atau perilaku transaction yang sedikit berbeda, cutover tetap bisa gagal secara fungsional.

Rollback harus dirancang sebelum migrasi dimulai

Setelah write mulai mengarah ke database cloud, rollback tidak lagi sesederhana mengubah DNS atau connection string. Jika tidak ada strategi reverse sync atau freeze window yang jelas, rollback bisa lebih berbahaya daripada terus maju.

Architecture / Context

Sistem migrasi biasanya terdiri dari source database on-prem atau local VM, target managed database di cloud, jalur replication/change capture, dan beberapa client aplikasi. Di produksi, kompleksitas tidak berada pada tool migrasi, tetapi pada koordinasi application client agar semuanya berpindah ke sumber baru secara konsisten.

Arsitektur / Cara Kerja

Pola umum migrasi yang lebih aman biasanya melibatkan:

1. penilaian kompatibilitas schema dan query
2. initial load ke target cloud
3. change data capture atau replikasi berkelanjutan
4. verifikasi data dan query behavior
5. cutover terjadwal dengan freeze window pendek
6. observability dan rollback decision point

Untuk banyak workload, model terbaik adalah membuat target cloud mengejar sumber lama sampai replication lag sangat kecil. Setelah itu, aplikasi dialihkan secara terkontrol. Jika service membaca dan menulis ke dua database sekaligus tanpa desain yang matang, kompleksitas justru melonjak.

Practical Implementation

Step 1: Audit kompatibilitas

Periksa extension, collation, timezone, dan query berat.

SELECT version();
SHOW server_encoding;
SHOW timezone;

Step 2: Buat initial snapshot

Contoh PostgreSQL:

pg_dump -Fc -h source-db.internal -U app_user appdb > appdb.dump
pg_restore -h target-db.cloud -U app_user -d appdb appdb.dump

Step 3: Aktifkan replikasi atau CDC

Contoh PostgreSQL logical replication:

CREATE PUBLICATION app_pub FOR ALL TABLES;

Di target:

CREATE SUBSCRIPTION app_sub
CONNECTION 'host=source-db.internal dbname=appdb user=replicator password=secret'
PUBLICATION app_pub;

Step 4: Siapkan freeze window

Saat mendekati cutover, hentikan write yang tidak kritis.

kubectl scale deploy background-worker --replicas=0 -n app
kubectl scale deploy scheduler --replicas=0 -n app

Step 5: Ganti connection string aplikasi

kubectl set env deploy/api DATABASE_URL=postgres://app_user:secret@target-db.cloud:5432/appdb -n app
kubectl rollout restart deploy/api -n app

Step 6: Aktifkan kembali worker

kubectl scale deploy background-worker --replicas=2 -n app
kubectl scale deploy scheduler --replicas=1 -n app

Verification

SELECT COUNT(*) FROM orders;
SELECT MAX(updated_at) FROM orders;
SELECT COUNT(*) FROM users WHERE deleted_at IS NULL;

Dan dari sisi aplikasi:

kubectl logs deploy/api -n app --tail=100
kubectl get pods -n app

Tanda berhasil:

• replication lag nol atau sangat kecil sebelum cutover
• query validasi di source dan target konsisten
• aplikasi dan worker baru memakai target cloud
• error rate pasca-cutover tetap stabil

Troubleshooting

Worker masih menulis ke database lama

Audit semua environment variable dan secret yang dipakai job terpisah.

Query lambat di target cloud

Periksa indeks, statistik, dan perbedaan storage class.

Rollback tidak realistis

Jika write sudah banyak masuk ke target tanpa reverse replication, rollback penuh mungkin tidak aman. Gunakan keputusan eksplisit, bukan asumsi.

Production Notes

• Cutover biasanya lebih aman dengan freeze window singkat daripada dual-write yang longgar.
• Logging aplikasi pasca-cutover harus dipantau lebih ketat selama beberapa jam pertama.
• Simpan query validation dan checklist dependency sebagai artefak migrasi, bukan catatan pribadi operator.
• Jangan lupakan job non-web seperti ETL, export, atau report generator.

Studi Kasus / Masalah Nyata

Replica sinkron, tetapi query plan berubah

Data sudah lengkap di cloud, namun performa query kritis memburuk karena indeks, statistik, atau storage characteristic berbeda. Dari sisi data migration ini terlihat sukses, dari sisi aplikasi justru gagal.

Background worker tetap menulis ke sumber lama

Aplikasi web sudah diarahkan ke cloud, tetapi worker lama masih memakai connection string on-prem karena environment variable tertinggal. Hasilnya dua sumber data hidup bersamaan tanpa disadari.

Rollback tidak realistis setelah cutover

Tim menyebut punya rollback, tetapi ternyata tidak ada cara aman mengembalikan write terbaru dari cloud ke sumber lama. Ini bukan rollback, hanya harapan.

Trade-offs

• Freeze window kecil lebih aman daripada dual-write yang tidak disiplin, tetapi membutuhkan koordinasi bisnis.
• Continuous replication memberi cutover lebih halus, tetapi menambah kompleksitas observability.
• Rollback yang benar menuntut definisi titik tanpa-kembali, yang kadang tidak nyaman untuk disepakati.

Best Practices

Lakukan rehearsal pada data yang cukup representatif

Migrasi uji dengan volume kecil sering memberi rasa aman palsu.

Definisikan freeze window yang sempit tetapi nyata

Beberapa menit pembatasan write yang direncanakan jauh lebih baik daripada inkonsistensi berjam-jam.

Pantau lebih dari sekadar replication lag

Perhatikan juga error aplikasi, query latency, connection count, dan backlog worker.

Failure Modes

• Worker atau batch job tetap menulis ke database lama setelah aplikasi utama pindah ke cloud.
• Schema, extension, atau query plan berubah dan memicu regresi performa setelah cutover.
• Tim mengklaim punya rollback padahal tidak ada strategi sinkronisasi balik untuk write terbaru.

Kesalahan Umum

• menganggap export/import cukup untuk workload aktif
• tidak menginventarisasi semua service dan worker yang memakai database
• menguji migrasi hanya pada volume kecil yang tidak realistis
• tidak menetapkan titik keputusan rollback yang eksplisit
• fokus pada data copy tetapi lupa pada performa pasca-cutover

Kesimpulan

Migrasi database lokal ke cloud tanpa downtime penuh memang sulit, tetapi downtime yang sangat kecil dan terkontrol cukup realistis jika replikasi, cutover, dan rollback dipikirkan sebagai masalah perubahan state. Kedisiplinan operasional di sini jauh lebih penting daripada janji tool migrasi mana pun.