Migrasi Database Tanpa Downtime untuk Aplikasi Bisnis: Pola Perluas-Migrasikan-Kecilkan, Backfill, dan Rencana Pembatalan

Setiap aplikasi bisnis yang hidup akan berubah. Fitur baru membutuhkan kolom baru, laporan baru membutuhkan tabel baru, dan pertumbuhan data memaksa struktur lama ditata ulang. Masalahnya, database adalah bagian aplikasi yang paling sulit diubah saat sedang dipakai. Kode program bisa diganti dalam hitungan detik dengan rilis ulang, tetapi tabel berisi jutaan baris pesanan, faktur, dan stok tidak bisa "dimatikan sebentar" tanpa dampak. Banyak bisnis akhirnya memilih jendela pemeliharaan tengah malam, atau lebih buruk, menunda perubahan hingga utang teknis menumpuk.

Artikel ini membahas cara mengubah struktur database aplikasi bisnis dengan risiko minimal dan, bila memungkinkan, tanpa menghentikan layanan: pola perubahan bertahap, cara memindahkan data besar, rencana pembatalan, dan pengujian. Panduan ini ditujukan bagi pemilik bisnis dan manajer produk yang perlu memahami keputusan teknis di balik perubahan, sekaligus bagi tim teknis yang mencari kerangka kerja praktis.

Ringkasan

• Perubahan database yang aman dilakukan bertahap dengan pola "perluas, migrasikan, kecilkan", bukan sekali ganti
• Selalu siapkan rencana pembatalan dan cadangan yang sudah diuji pemulihannya sebelum menyentuh data produksi
• Pindahkan data besar dalam potongan kecil di latar belakang agar tidak mengunci tabel dan memperlambat pengguna
• Uji migrasi pada salinan data produksi, ukur waktunya, dan latih prosedurnya sebelum hari pelaksanaan
• Komunikasikan jadwal dan risiko kepada pengguna bisnis; tidak semua perubahan perlu nol downtime, tetapi semuanya perlu terencana

Mengapa migrasi database berisiko

Perubahan struktur database berbeda dari perubahan kode karena dua alasan: data bersifat permanen dan perubahan sering memengaruhi seluruh aplikasi sekaligus.

• **Data tidak bisa "diganti"**: kesalahan pada kode dapat diperbaiki dengan rilis baru, tetapi data yang rusak atau terhapus hanya pulih dari cadangan
• **Penguncian tabel**: beberapa perubahan struktur membuat tabel terkunci selama proses berlangsung, sehingga aplikasi menunggu atau error
• **Kompatibilitas versi**: selama rilis, versi lama dan baru kode bisa berjalan bersamaan dan keduanya harus cocok dengan struktur database
• **Skala**: perubahan yang selesai dalam satu detik pada data uji bisa memakan satu jam pada data produksi
• **Ketergantungan tersembunyi**: laporan, integrasi, dan skrip lama mungkin membaca kolom yang hendak diubah

Karena itu, migrasi database perlu dianggap sebagai proyek kecil dengan persiapan, pengujian, dan rencana mundur, bukan tugas rutin yang dijalankan sambil lalu.

Prinsip dasar: perluas, migrasikan, kecilkan

Pola yang paling banyak dipakai untuk perubahan tanpa downtime sering disebut "expand and contract". Idenya: jangan pernah mengubah sesuatu sehingga versi kode lama langsung rusak.

Tahap 1: perluas (expand)

Tambahkan struktur baru tanpa menghapus yang lama. Misalnya, bila ingin memecah kolom nama lengkap menjadi nama depan dan belakang, tambahkan dua kolom baru lebih dulu. Kolom lama tetap ada dan tetap dipakai. Penambahan kolom yang bersifat opsional biasanya cepat dan aman.

Tahap 2: migrasikan (migrate)

Ubah aplikasi agar menulis ke struktur lama dan baru sekaligus, lalu salin data historis dari lama ke baru secara bertahap. Setelah semua data tersalin dan konsisten, ubah aplikasi agar membaca dari struktur baru. Selama masa ini kedua versi kode tetap berfungsi.

Tahap 3: kecilkan (contract)

Setelah yakin tidak ada yang memakai struktur lama, hentikan penulisan ke sana, lalu hapus kolom atau tabel lama pada rilis berikutnya. Jangan terburu-buru: simpan struktur lama beberapa waktu sebagai jaring pengaman.

Pola ini membutuhkan lebih banyak langkah daripada mengubah sekaligus, tetapi tiap langkah kecil, bisa dibatalkan, dan tidak memutus layanan. Pendekatan ini sejalan dengan feature flag dan rilis bertahap yang memungkinkan beralih ke perilaku baru dengan risiko rendah.

Jenis perubahan dan tingkat risikonya

Tidak semua perubahan setara. Mengenali tingkat risiko membantu menentukan perlunya jendela pemeliharaan.

Perubahan berisiko rendah

• Menambah tabel baru yang belum dipakai kode lama
• Menambah kolom opsional tanpa nilai bawaan yang berat
• Menambah indeks dengan metode yang tidak mengunci tabel (bila didukung mesin database)

Perubahan berisiko sedang

• Mengubah tipe data kolom, terutama pada tabel besar
• Menambah kolom wajib dengan nilai bawaan pada tabel jutaan baris
• Menambah batasan (constraint) pada data yang sudah ada, karena data lama harus divalidasi

Perubahan berisiko tinggi

• Mengganti nama kolom atau tabel yang dipakai banyak bagian aplikasi
• Menghapus kolom atau tabel
• Memecah atau menggabung tabel besar
• Memindahkan database ke mesin atau penyedia lain

Untuk perubahan berisiko tinggi, selalu gunakan pola bertahap. Mengganti nama sebaiknya dilakukan dengan menambah nama baru, menyalin, mengalihkan, lalu menghapus nama lama, bukan perintah ganti nama langsung.

Memindahkan data besar tanpa mengganggu pengguna

Menyalin jutaan baris dalam satu transaksi besar dapat mengunci tabel, menghabiskan memori, dan membuat replika database tertinggal. Cara yang lebih aman adalah mengisi ulang data (backfill) dalam potongan kecil.

Pola backfill yang aman

• **Potongan kecil**: proses ribuan baris per putaran, bukan jutaan sekaligus
• **Jeda antar putaran**: beri jeda singkat agar beban database tetap rendah bagi pengguna
• **Dapat dilanjutkan**: catat posisi terakhir sehingga proses yang terhenti dapat dilanjutkan, bukan diulang dari awal
• **Idempoten**: menjalankan potongan yang sama dua kali tidak merusak data
• **Pemantauan**: awasi waktu respons aplikasi, antrean, dan keterlambatan replikasi selama proses berjalan
• **Waktu pelaksanaan**: jalankan di luar jam sibuk, misalnya di luar jam transaksi toko atau jam tutup buku

Pendekatan ini serupa dengan pemrosesan di latar belakang pada arsitektur event-driven dan antrean pesan: pekerjaan berat dipecah menjadi unit kecil yang dapat dicoba ulang.

Memastikan data baru yang masuk selama migrasi

Selagi data lama disalin, pengguna terus membuat data baru. Pastikan aplikasi menulis ke kedua struktur (menulis ganda), atau gunakan mekanisme perubahan data (trigger atau log perubahan) agar tidak ada baris yang terlewat. Setelah selesai, jalankan pemeriksaan konsistensi: jumlah baris, total nilai, dan sampel acak harus cocok antara struktur lama dan baru.

Rencana pembatalan dan cadangan

Pertanyaan terpenting sebelum migrasi: "Jika ini gagal, bagaimana kita kembali?" Tim yang tidak punya jawaban jelas belum siap melakukan migrasi.

Cadangan yang benar-benar bisa dipulihkan

Memiliki cadangan tidak sama dengan memiliki cadangan yang bisa dipulihkan. Uji pemulihan ke lingkungan terpisah dan ukur berapa lama waktunya. Jika pemulihan memerlukan enam jam, jendela pemeliharaan satu jam tidak masuk akal. Strategi lengkapnya dibahas di strategi backup data bisnis dan rencana pemulihan bencana dan kesinambungan bisnis.

Titik keputusan "lanjut atau mundur"

Tetapkan di muka kriteria yang membuat Anda membatalkan: misalnya waktu respons melebihi ambang tertentu, tingkat error naik, atau pemeriksaan konsistensi gagal. Putuskan siapa yang berhak memutuskan, agar tidak ada perdebatan di tengah proses.

Rollback struktur versus rollback data

Mengembalikan struktur lebih mudah daripada mengembalikan data. Setelah pengguna menulis data baru ke struktur baru, mundur ke struktur lama bisa berarti kehilangan data tersebut. Karena itu pola menulis ganda sangat membantu: struktur lama tetap lengkap sehingga pembatalan aman sampai tahap kecilkan.

Menguji sebelum hari pelaksanaan

Migrasi yang tidak diuji adalah perjudian. Siapkan lingkungan uji yang menyerupai produksi.

• **Salinan data produksi**: gunakan salinan (dengan data pribadi disamarkan bila perlu) agar waktu dan perilaku mendekati kenyataan
• **Ukur durasi**: catat waktu tiap langkah, dan ekstrapolasi untuk pertumbuhan data
• **Uji kedua versi kode**: pastikan versi lama dan baru berjalan baik pada struktur campuran
• **Latihan pelaksanaan**: jalankan seluruh prosedur dari awal sampai akhir, termasuk pembatalan
• **Pengujian otomatis**: masukkan skrip migrasi ke alur integrasi berkelanjutan, sebagaimana dibahas di [pengujian otomatis dan CI/CD](/blog/pengujian-otomatis-dan-ci-cd-untuk-aplikasi-bisnis)
• **Uji penerimaan pengguna**: libatkan pengguna bisnis untuk memeriksa laporan dan angka kunci setelah uji coba, selaras dengan [UAT sebelum aplikasi diluncurkan](/blog/uat-pengujian-sebelum-aplikasi-diluncurkan)

Migrasi besar: pindah mesin database atau penyedia

Memindahkan database ke mesin berbeda (misalnya dari server lokal ke layanan terkelola di cloud, atau dari satu jenis database ke jenis lain) adalah kategori tersendiri. Pola umumnya:

• **Replikasi berkelanjutan**: jalankan database baru sebagai replika yang selalu menyusul database lama
• **Verifikasi paralel**: bandingkan hasil kueri penting pada kedua database selama beberapa hari
• **Peralihan singkat**: pada saat yang dipilih, hentikan penulisan sebentar, pastikan replika sudah sama, lalu alihkan aplikasi ke database baru
• **Masa siaga**: pertahankan database lama dalam mode baca saja untuk beberapa waktu sebagai jalan mundur
• **Penyesuaian aplikasi**: periksa perbedaan perilaku (urutan hasil, penanganan waktu, huruf besar kecil) yang bisa memicu bug halus

Pertimbangan strategis dan bahaya ketergantungan pada satu penyedia dibahas di vendor lock-in di cloud dan software bisnis. Untuk perpindahan keseluruhan sistem, termasuk data, lihat juga persiapan migrasi data sistem baru dan modernisasi sistem lama tanpa menghentikan operasional.

Kapan jendela pemeliharaan justru lebih baik

Nol downtime bukan tujuan mutlak. Untuk beberapa bisnis, jendela pemeliharaan terencana lebih murah dan lebih aman daripada rancangan bertahap yang rumit.

• Aplikasi internal yang dipakai jam kerja saja, dengan akhir pekan sepi
• Perubahan kecil yang hanya butuh beberapa menit pada tabel kecil
• Migrasi satu kali yang sangat kompleks, di mana risiko kesalahan pada pola ganda lebih besar daripada manfaatnya
• Bisnis dengan jam tutup yang jelas, misalnya toko yang tutup malam hari

Yang penting adalah jendela itu diumumkan, singkat, dan didukung rencana mundur. Hindari pemeliharaan mendadak tanpa pemberitahuan pada hari puncak penjualan. Sinkronkan dengan kalender bisnis: hindari akhir bulan saat tutup buku, hari gajian, dan musim promo.

Kolaborasi antara tim bisnis dan tim teknis

Migrasi database sering dianggap urusan teknis murni, padahal keberhasilannya bergantung pada koordinasi.

• **Pemilik proses bisnis** menyebutkan laporan dan angka yang harus tetap benar setelah migrasi
• **Tim teknis** menjelaskan risiko, durasi, dan opsi dalam bahasa yang dapat dipahami
• **Dukungan pelanggan** disiapkan menghadapi pertanyaan bila ada gangguan singkat
• **Pemilik data** menyetujui kriteria konsistensi, misalnya total saldo harus sama persis
• **Dokumentasi** mencatat apa yang diubah, mengapa, dan bagaimana mundur, mendukung [dokumentasi teknis dan serah terima proyek](/blog/dokumentasi-teknis-dan-serah-terima-proyek-software)

Apabila performa database menjadi alasan migrasi, tinjau juga performa database dan aplikasi bisnis yang melambat, karena sering kali masalahnya bisa diselesaikan dengan indeks atau kueri yang lebih baik tanpa migrasi besar.

Checklist ringkas sebelum menjalankan migrasi

• Cadangan terbaru ada dan pemulihannya sudah diuji
• Skrip migrasi sudah dijalankan pada salinan data produksi dan durasinya diketahui
• Versi kode lama dan baru kompatibel dengan struktur selama peralihan
• Rencana pembatalan tertulis lengkap dengan kriteria dan penanggung jawab
• Pemantauan siap: waktu respons, tingkat error, beban database
• Jadwal dikomunikasikan kepada pengguna dan dukungan pelanggan
• Pemeriksaan konsistensi pascamigrasi sudah ditentukan
• Tim berjaga selama dan sesudah pelaksanaan

Pertanyaan yang sering diajukan

Apakah semua migrasi bisa dilakukan tanpa downtime?

Tidak semua. Banyak perubahan bisa dibuat bertahap, tetapi beberapa memerlukan jeda singkat, misalnya saat peralihan akhir ke mesin database baru. Targetnya adalah jeda sesingkat mungkin dan terencana.

Berapa lama sebaiknya menyimpan struktur lama sebelum dihapus?

Cukup lama untuk memastikan tidak ada laporan, integrasi, atau skrip yang masih memakainya, biasanya beberapa minggu hingga satu siklus tutup buku. Pantau penggunaan sebelum menghapus.

Apakah perlu mengubah aplikasi hanya untuk migrasi?

Sering kali ya, minimal agar kompatibel dengan dua struktur selama peralihan. Tim sebaiknya memperhitungkan pekerjaan ini dalam estimasi, bukan menganggapnya gratis.

Bagaimana bila data yang dimigrasi ternyata tidak konsisten?

Itulah gunanya pemeriksaan konsistensi dan masa siaga. Bila ditemukan selisih, hentikan peralihan, perbaiki sumber masalah, dan ulangi. Kualitas data lama juga perlu diperiksa, lihat kualitas data dan tata kelola data.

Kesimpulan

Mengubah database yang sedang dipakai adalah soal disiplin, bukan keberanian. Dengan pola perluas-migrasikan-kecilkan, pemindahan data dalam potongan kecil, cadangan yang teruji, dan latihan pada salinan data produksi, perubahan besar dapat dipecah menjadi langkah-langkah kecil yang aman. Jika tidak bisa nol downtime, buat jendela pemeliharaan yang singkat, diumumkan, dan punya jalan mundur.