Perubahan Database Aditif: Cara Menambah Tanpa Merusak Produksi

Anda memiliki aplikasi yang berjalan dengan ribuan pengguna aktif. Tim Anda perlu menambahkan kolom nomor telepon ke profil pengguna. Perubahannya terlihat kecil, tetapi membayangkan menjalankan ALTER TABLE di database produksi membuat semua orang gugup. Bagaimana jika migrasi mengunci tabel? Bagaimana jika kode aplikasi lama crash karena tidak menduga adanya kolom baru?

Situasi ini terjadi di hampir setiap tim teknik yang mengelola database mereka sendiri. Kabar baiknya adalah satu kategori perubahan skema sangat aman, bahkan di bawah beban produksi. Memahami kategori ini mengubah cara Anda merencanakan deployment, berkoordinasi dengan tim, dan menanggung risiko saat mengembangkan database.

Apa yang Membuat Perubahan Bersifat Aditif

Perubahan aditif adalah modifikasi yang hanya menambahkan sesuatu yang baru ke skema database tanpa mengubah atau menghapus apa pun yang sudah ada. Daftarnya sederhana:

  • Menambahkan kolom baru ke tabel yang sudah ada
  • Membuat tabel baru
  • Menambahkan indeks baru
  • Menambahkan constraint yang tidak membatasi data yang sudah ada

Properti utamanya adalah Anda memperluas skema. Anda tidak mengganti nama kolom, mengubah tipe data, menggabungkan tabel, atau menghapus apa pun. Bagian lama dari skema tetap persis seperti sebelumnya.

Mengapa Perubahan Aditif Aman

Keamanan berasal dari fakta sederhana: kode aplikasi lama tidak bergantung pada hal baru yang baru saja Anda tambahkan. Saat Anda menambahkan kolom phone ke tabel users, kode aplikasi yang sudah ada terus membaca dan menulis name, email, dan password persis seperti biasanya. Kode tersebut tidak tahu bahwa kolom baru ada. Tidak mencoba membacanya, dan tidak mencoba menulis ke kolom tersebut. Tidak ada yang rusak.

Ini tidak berlaku untuk jenis perubahan lain. Jika Anda mengganti nama kolom dari phone menjadi phone_number, kode aplikasi lama akan mencoba membaca phone dan gagal karena kolom tersebut sudah tidak ada. Jika Anda mengubah tipe kolom dari VARCHAR menjadi INT, kode lama mungkin menulis nilai string yang tidak bisa lagi diterima database. Jika Anda menggabungkan dua tabel, query lama yang mereferensi struktur tabel asli akan rusak.

Perubahan aditif menghindari semua masalah ini karena tidak menyentuh apa pun yang diandalkan oleh kode lama.

Satu Aturan Kritis

Ada satu kondisi yang membuat perubahan aditif aman: kolom baru harus nullable atau memiliki nilai default.

Jika Anda menambahkan kolom dengan NOT NULL tanpa default, setiap baris yang sudah ada di tabel akan langsung melanggar constraint. Database akan menolak migrasi. Dalam kasus terburuk, migrasi berjalan sebagian, berhasil untuk beberapa baris, lalu gagal, meninggalkan data yang tidak konsisten dan sulit dibersihkan.

Pola standarnya seperti ini:

ALTER TABLE users ADD COLUMN phone VARCHAR(20) NULL;

Jika Anda tahu kolom tersebut pada akhirnya akan wajib diisi, tambahkan nilai default terlebih dahulu:

ALTER TABLE users ADD COLUMN phone VARCHAR(20) NOT NULL DEFAULT '';

Dengan nilai default, setiap baris yang ada mendapatkan string kosong. Kode aplikasi lama masih bisa membaca kolom tersebut tanpa error. Nanti, setelah semua instance aplikasi diperbarui untuk menangani kolom baru dengan benar, Anda dapat menghapus default atau menambahkan constraint NOT NULL di migrasi terpisah.

Menjalankan Perubahan Aditif Selama Jam Produksi

Salah satu keuntungan praktis terbesar dari perubahan aditif adalah Anda dapat menjalankannya saat produksi sedang sibuk. Di sebagian besar database modern, ALTER TABLE ADD COLUMN dengan kolom nullable adalah operasi ringan yang tidak mengunci tabel dalam waktu lama.

Ada pengecualian. Versi MySQL yang lebih lama dapat mengunci tabel selama ALTER TABLE. Menambahkan kolom di posisi tertentu menggunakan AFTER juga dapat menyebabkan lebih banyak penguncian daripada menambahkannya di akhir. Namun secara umum, menambahkan kolom nullable adalah salah satu operasi teraman yang dapat Anda lakukan di database langsung.

Ini berarti Anda tidak perlu jendela pemeliharaan. Anda tidak perlu menunggu jam lalu lintas rendah. Anda dapat menjalankan migrasi di siang hari, memverifikasi bahwa migrasi berfungsi, dan melanjutkan ke langkah deployment berikutnya.

Bagaimana Ini Memungkinkan Deployment Bertahap

Perubahan aditif membuka strategi deployment yang sulit dicapai dengan jenis perubahan skema lain: pembaruan bergulir tanpa koordinasi.

Bayangkan Anda memiliki sepuluh instance aplikasi yang berjalan di belakang load balancer. Anda ingin men-deploy versi baru yang membaca dan menulis kolom phone. Berikut cara kerjanya:

  1. Jalankan migrasi untuk menambahkan kolom phone. Skema sekarang memiliki kolom baru, tetapi kesepuluh instance masih menjalankan kode lama yang mengabaikannya.
  2. Perbarui satu instance ke kode baru. Instance itu mulai membaca dan menulis kolom phone. Sembilan instance lainnya terus bekerja normal karena tidak pernah menyentuh kolom baru.
  3. Perbarui secara bertahap instance yang tersisa satu per satu. Pada titik mana pun dalam proses ini, instance lama dan baru hidup berdampingan tanpa konflik.

Ini hanya mungkin karena perubahan skema bersifat aditif. Jika perubahan memerlukan penghapusan kolom atau penggantian nama, instance lama akan rusak begitu migrasi dijalankan. Anda akan terpaksa memperbarui semua instance sekaligus, yang meningkatkan risiko dan memerlukan koordinasi yang cermat.

Kapan Harus Melampaui Perubahan Aditif

Perubahan aditif aman, tetapi tidak selalu mencukupi. Pada akhirnya, Anda perlu menghapus kolom yang tidak digunakan, mengubah tipe data untuk memperbaiki masalah kinerja, atau merestrukturisasi tabel untuk mendukung fitur baru. Perubahan tersebut membawa lebih banyak risiko dan memerlukan strategi yang berbeda.

Urutan praktisnya: mulai dengan perubahan aditif untuk memperkenalkan kolom dan tabel baru, biarkan kode aplikasi mengejar, lalu rencanakan perubahan yang lebih invasif di migrasi terpisah. Setiap migrasi harus melakukan satu hal dan hanya satu hal. Jangan mencampur perubahan aditif dengan perubahan destruktif dalam skrip migrasi yang sama.

Daftar Periksa Cepat untuk Perubahan Aditif

Sebelum menjalankan perubahan aditif di produksi, lakukan pemeriksaan berikut:

  • Apakah kolom baru nullable, atau memiliki nilai default?
  • Apakah migrasi hanya menambahkan sesuatu, tidak memodifikasi atau menghapus skema yang ada?
  • Apakah Anda sudah menguji migrasi pada salinan data produksi?
  • Apakah Anda memiliki rencana rollback? (Untuk perubahan aditif, rollback biasanya hanya ALTER TABLE DROP COLUMN, tetapi verifikasi bahwa itu berfungsi.)
  • Bisakah kode aplikasi lama tetap berjalan tanpa perubahan setelah migrasi?

Jika Anda bisa menjawab ya untuk semua pertanyaan ini, Anda siap menjalankan migrasi dengan percaya diri.

Intisari Konkret

Perubahan aditif adalah kategori modifikasi skema database yang paling aman karena memperluas skema tanpa merusak apa pun yang diandalkan oleh kode lama. Gunakan kolom nullable atau nilai default, jalankan selama jam kerja normal, dan deploy instance aplikasi Anda secara bertahap. Pendekatan ini menghilangkan ketegangan antara mengembangkan database dan menjaga stabilitas produksi. Mulailah setiap perubahan skema dengan bertanya: bisakah saya membuat ini aditif? Jika ya, lakukan itu terlebih dahulu. Simpan perubahan yang lebih berisiko untuk nanti, ketika skema baru sudah digunakan dan kode lama sudah pensiun.