Dump Users Tetap Hidup Saat db-push Mengganti Database

Skrip db-push rutin dijalankan, semua tampak selesai, lalu saya coba masuk ke admin staging KotaPortal. Login gagal. Tabel users benar-benar kosong: akun akun pengujian yang kemarin ada, hilang tanpa jejak dan tanpa satu pun pesan error.

Dugaan pertama: skrip korup, atau ada yang iseng menghapus tabel. Dua-duanya meleset. Polanya terlalu konsisten: hilangnya selalu bertepatan dengan db-push, dan selalu hanya tabel itu. Pelakunya adalah db-push itu sendiri: seluruh database staging diganti dengan dump dari lingkungan pengembangan, dan dump dev itu memang mengecualikan tabel users. Setiap push adalah pergantian database penuh, dan akun staging adalah korban rutin yang tidak pernah dicatat.

Dua Dump, Dua Sumber Kebenaran

Fixnya bukan mengecualikan users dari penggantian, karena import penuh tetap dibutuhkan. Bentuknya dua dump yang kecil: skema dan data lain tetap dari dev, data users diselamatkan dari staging sebelum DROP dijalankan, lalu dikembalikan setelah import selesai. mysqldump sudah menyediakan pisau untuk ini: --no-create-info menulis tanpa CREATE TABLE, artinya data murni tanpa definisi tabel [1], dan --no-data adalah kebalikannya untuk skema tanpa isi.

Untuk dump users, kuncinya --complete-insert: INSERT yang mencantumkan nama kolom [1]. Di sinilah kompatibilitas skema terjadi. Skema staging tertinggal satu kolom dari dev, dan dengan nama kolom eksplisit, 19 akun staging terimport bersih ke skema dev yang lebih lebar. Kolom tambahan terisi DEFAULT yang sudah ditentukan. Tidak ada konversi skrip yang perlu ditulis ulang tiap skema bergeser.

Cara pandang yang berubah dari kejadian ini: dump penuh itu bukan backup, ia replace. Selama isi database dev dan staging tidak identik, pergantian penuh pasti memakan bagian yang hanya hidup di satu sisi. Tabel users hanya kebetulan yang paling terasa karena akun admin ikut lenyap, tapi pola yang sama bisa menimpa tabel konfigurasi lingkungan, flag fitur staging, atau data referensi lokal mana pun yang tidak pernah ikut skema dev.

Urutan operasinya juga pelajaran tersendiri. Dump data users harus selesai dan lolos sanity check sebelum satu pun DROP dijalankan, bukan sesudahnya. Urutan itu yang membedakan script yang gagal aman dari script yang gagal sambil menghapus: kalau dump kosong karena koneksi SSH putus di tengah, kondisi database staging masih utuh dan push bisa diulang; kebalikannya, akun hilang permanen dan pemulihan tinggal harapan pada backup lama.

Guard yang Dibayar dari Keterbacaan

Saya menambahkan --skip-extended-insert yang memaksa satu INSERT per baris [1]. File jadi lebih besar, tapi guard jadi murah: dump terpotong terdeteksi dari header mysqldump yang hilang di baris akhir, tanpa parsing SQL. Rantai gagalnya berlapis: dump users gagal, proses berhenti sebelum DROP dieksekusi; dump terdeteksi terpotong, berhenti juga; restore gagal setelah penggantian, skrip keluar exit 1 sambil menunjuk backup pra-push sebagai jalur pemulihan manual. Kegagalan paling parah pun tidak pernah meninggalkan staging kosong tanpa pintu kembali.

Satu titik lagi yang paling sering diremehkan: nama database disisipkan langsung ke perintah jarak jauh SSH, dan ssh mengeksekusi perintah itu di host jarak jauh dengan argumen yang digabung spasi [2]. Interpolasi seperti itu adalah pintu injeksi klasik, jadi nama dibatasi ketat ke karakter [A-Za-z0-9_] sebelum menyentuh baris perintah. Validasi, bukan escaping, dan sudah terbukti cukup.

Terakhir, dump users itu membawa hash password. Sejak detik ia ada, ia artefak rahasia: chmod 600 memasangnya ke pemilik saja, baca dan tulis [3], sebelum file pindah ke mana pun. Push database memang pekerjaan destruktif, tapi dengan dua dump yang kecil dan guard yang jujur, tabel users tidak perlu mati lagi setiap kali dev mau kirim kode. Pengujian akhirnya nyata dan tidak pakai dramatisasi: push dijalankan, 19 akun staging kembali otomatis, login admin jalan tanpa kreasi manual. Skema staging yang masih 13 kolom pun tidak jadi soal karena INSERT bernama kolom melewatinya. db-push berikutnya tinggal rutinitas, bukan momen tegang.

Satu kebiasaan kecil yang ikut terbawa sejak kejadian: setiap skrip yang menembak database via SSH sekarang melewati daftar periksa yang sama di kepala saya. Apa artefak yang dihasilkan sebelum langkah destruktif, apa yang membuktikan artefak itu utuh, dan ke mana menunjuk kalau langkah terakhir gagal. Tiga jawaban itu yang membedakan otomasi yang bisa ditidurkan dari otomasi yang harus ditunggui.

## Sources [1] https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html [2] https://man7.org/linux/man-pages/man1/ssh.1.html [3] https://man7.org/linux/man-pages/man1/chmod.1.html