Database Migration Tanpa Drama: Cara Mengubah Struktur MySQL dengan Aman

Menambah kolom, mengganti nama tabel, atau mengubah tipe data di MySQL adalah pekerjaan yang hampir pasti muncul ketika website berkembang. Masalahnya, database bukan sekadar tempat menyimpan data. Struktur database terhubung langsung dengan kode PHP, API, laporan, proses login, hingga fitur pembayaran.

Karena itu, perubahan kecil pada database dapat menimbulkan efek besar. Aplikasi bisa gagal membaca data, proses deployment berhenti di tengah jalan, atau lebih buruk lagi: data pengguna berubah tanpa sengaja. Di sinilah database migration menjadi penting.

Migration adalah cara mencatat perubahan struktur database dalam file atau skrip yang bisa dijalankan secara berurutan. Alih-alih mengubah database secara manual melalui phpMyAdmin lalu berharap semua orang mengingat apa yang dilakukan, tim memiliki riwayat perubahan yang jelas, dapat diuji, dan bisa diterapkan di server lain.

Mengapa Perubahan Database Sering Menjadi Sumber Masalah?

Dalam proyek kecil, mengubah database secara manual mungkin terasa cepat. Namun, kebiasaan ini mulai berisiko ketika ada lebih dari satu lingkungan kerja, misalnya komputer lokal, server staging, dan server produksi.

Beberapa masalah yang umum terjadi antara lain:

• Perubahan sudah dilakukan di server produksi, tetapi belum diterapkan di komputer developer lain.
• Skrip SQL tidak dicatat sehingga sulit mengetahui perubahan apa saja yang pernah dibuat.
• Kolom dihapus sebelum kode lama berhenti menggunakannya.
• Perubahan tipe data membuat nilai lama terpotong atau gagal dikonversi.
• Migration dijalankan saat aplikasi masih memproses data dengan struktur lama.

Masalah ini bukan berarti MySQL tidak aman digunakan. Sumber risikonya biasanya adalah proses perubahan yang tidak terencana.

Migration Bukan Sekadar Kumpulan File SQL

File migration memang sering berisi perintah SQL seperti ALTER TABLE, CREATE TABLE, atau CREATE INDEX. Namun, tujuan utamanya lebih luas: membuat perubahan database menjadi bagian dari proses pengembangan aplikasi.

Setiap migration idealnya memiliki beberapa karakteristik:

• Berurutan: migration dapat dijalankan sesuai urutan waktu.
• Dapat dilacak: nama file atau versinya menjelaskan perubahan yang dibuat.
• Konsisten: semua lingkungan menggunakan perubahan yang sama.
• Dapat diuji: migration dijalankan lebih dulu di database pengujian.
• Memiliki strategi pemulihan: tersedia backup atau langkah pembatalan jika terjadi masalah.

Framework PHP seperti Laravel biasanya sudah menyediakan sistem migration. Untuk aplikasi PHP tanpa framework, konsep yang sama tetap bisa diterapkan menggunakan skrip SQL berversi, tool migration khusus, atau pipeline deployment.

Mulai dari Perubahan yang Paling Aman

Urutan perubahan sangat menentukan keamanan migration. Salah satu pola yang relatif aman adalah expand and contract. Pola ini membagi perubahan besar menjadi beberapa tahap kecil.

Misalnya, Anda ingin mengganti kolom nama menjadi nama_lengkap. Jangan langsung menghapus kolom lama dan menggantinya dalam satu deployment. Aplikasi yang masih menggunakan kode lama akan segera gagal.

Urutan yang lebih aman adalah:

1. Tambahkan kolom baru nama_lengkap.
2. Ubah kode aplikasi agar mulai menulis data ke kolom baru, tetapi masih bisa membaca kolom lama.
3. Salin data lama ke kolom baru secara bertahap.
4. Pastikan seluruh proses sudah menggunakan kolom baru.
5. Hapus kolom lama pada migration terpisah setelah tidak lagi diperlukan.

Dengan pendekatan ini, database dan kode aplikasi tidak dipaksa berubah secara ekstrem pada waktu yang sama.

Contoh Migration MySQL yang Lebih Terukur

Misalkan tabel orders perlu memiliki kolom status pembayaran. Migration sederhana dapat terlihat seperti ini:

ALTER TABLE orders
ADD COLUMN payment_status VARCHAR(20)
NOT NULL DEFAULT 'pending';

Perintah tersebut relatif aman karena kolom baru memiliki nilai default. Namun, tetap ada hal yang perlu diperiksa: ukuran tabel, waktu eksekusi, indeks yang terlibat, serta kemungkinan adanya proses lain yang sedang menulis data.

Untuk tabel kecil, perubahan mungkin selesai hampir seketika. Pada tabel besar, ALTER TABLE dapat menggunakan resource server dan menyebabkan lock atau penurunan performa. Karena itu, migration sebaiknya dicoba terlebih dahulu pada salinan database dengan ukuran yang mendekati produksi.

Jangan Menganggap Backup Sama dengan Rencana Rollback

Backup adalah salinan data sebelum perubahan. Rollback adalah rencana untuk mengembalikan sistem ke kondisi yang dapat digunakan jika migration menimbulkan masalah. Keduanya berkaitan, tetapi tidak selalu sama.

Jika migration menambahkan kolom, rollback mungkin cukup dengan menghapus kolom tersebut. Namun, jika migration mengubah atau menghapus data, rollback otomatis bisa menjadi rumit. Data yang sudah diubah belum tentu dapat dikembalikan hanya dengan menjalankan perintah SQL kebalikan.

Sebelum menjalankan migration penting, lakukan beberapa hal berikut:

• Buat backup dan pastikan file backup benar-benar dapat dibaca.
• Catat estimasi waktu migration.
• Tentukan siapa yang memantau server saat perubahan dilakukan.
• Siapkan prosedur penghentian deployment jika terjadi error.
• Uji proses pemulihan pada lingkungan non-produksi.

Backup yang tidak pernah diuji hanya memberi rasa aman, bukan kepastian.

Perhatikan Data Lama, Bukan Hanya Struktur Baru

Kesalahan migration sering terjadi karena developer hanya melihat struktur tabel dan lupa memeriksa isi datanya. Kolom baru mungkin memiliki aturan NOT NULL, padahal data lama tidak memiliki nilai yang sesuai.

Sebelum menetapkan constraint baru, periksa kondisi data terlebih dahulu. Contohnya:

SELECT COUNT(*)
FROM users
WHERE email IS NULL;

Jika hasilnya masih lebih dari nol, menambahkan aturan NOT NULL pada kolom email dapat gagal atau memaksa proses yang tidak diinginkan. Bersihkan dan lengkapi data lebih dulu, lalu tambahkan constraint pada tahap berikutnya.

Hal serupa berlaku untuk indeks, nilai unik, format tanggal, dan relasi antar-tabel. Data yang tampak baik dalam beberapa baris belum tentu memenuhi aturan ketika jumlahnya sudah jutaan.

Hubungkan Migration dengan Deployment

Migration sebaiknya tidak menjadi aktivitas terpisah yang hanya dilakukan oleh satu orang. Masukkan file migration ke version control seperti Git, lalu jalankan melalui proses deployment yang terdokumentasi.

Pastikan pipeline memiliki langkah yang jelas: mengambil kode terbaru, menjalankan pemeriksaan, membuat backup bila diperlukan, menjalankan migration, kemudian mengaktifkan versi aplikasi yang sesuai. Untuk perubahan berisiko tinggi, migration dapat dijalankan terlebih dahulu dalam mode manual dengan persetujuan khusus.

Hindari menjalankan migration langsung dari laptop tanpa catatan. Cara tersebut sulit diaudit dan membuka peluang bahwa database produksi berbeda dari kode yang tersimpan di repository.

Checklist Sebelum Mengubah Database Produksi

1. Apakah perubahan sudah diuji dengan data yang realistis?
2. Apakah migration tersimpan di version control?
3. Apakah kode aplikasi lama tetap kompatibel selama masa transisi?
4. Apakah backup sudah dibuat dan diuji?
5. Apakah perubahan berpotensi mengunci tabel besar?
6. Apakah ada rencana pemantauan setelah deployment?
7. Apakah tim tahu cara menghentikan atau memulihkan proses?

Apa Artinya bagi Kita?

Database migration bukan fitur khusus untuk perusahaan besar. Bahkan website sederhana akan lebih mudah dirawat jika setiap perubahan database dicatat dan dapat diulang.

Langkah pertama tidak harus rumit. Buat folder migration, gunakan penamaan berdasarkan waktu atau nomor urut, simpan semua perubahan di Git, dan jangan mengubah database produksi secara manual tanpa dokumentasi. Setelah itu, biasakan menguji migration pada salinan database sebelum menyentuh data sebenarnya.

Perubahan database yang aman bukan soal memiliki perintah SQL yang sempurna. Yang lebih penting adalah memahami dampaknya terhadap data, kode aplikasi, pengguna, dan proses deployment. Dengan pendekatan bertahap, perubahan yang biasanya menegangkan bisa menjadi pekerjaan rutin yang dapat diprediksi.

– Rio Yotto @rioyotto