Tailscale, SQLite'ın Write-Ahead Logging (WAL) mekanizmasındaki 16 yıllık bir hatanın veritabanlarını sessizce bozabileceğini doğruladı ve şirket, bu hatayı gidermek için SQLite yöneticileriyle birlikte çalışarak 3.46.1 sürümünde bir düzeltme yayınladı. Bu keşif önemlidir çünkü birçok modern servis hala SQLite'ı WAL modunda çalıştırmaktadır ve tespit edilemeyen bozulmalar yapılandırma verilerini silebilir ve ağ düğümlerini bozabilir.

Hata nasıl gözden kaçtı

Hata, 2010 yılından beri WAL mekanizmasında mevcuttu. Yüksek eşzamanlılık içeren erişim modelleri ile belirli dosya sistemi davranışları arasındaki nadir bir etkileşim, sessiz veri bozulmasını tetikliyor ve standart sağlık kontrolleri bunu fark edemiyordu.

Tailscale mühendisleri, ilk olarak bir avuç düğümün herhangi bir bariz hata mesajı olmaksızın saklanan durumlarını (state) kaybettiğini gördü. "Veritabanı ayakta mı?" diye soran kontroller başarıyla sonuçlanmaya devam ediyor ancak yapılandırma girişleri yok oluyordu. Sorunu yeniden oluşturmak, WAL yolunu zorlayan ve dosya sistemi zamanlamasını ayarlayan özel araçlar gerektiriyordu; bu nedenle sorun on yıldan fazla bir süre boyunca gizli kaldı.

Kimler endişelenmeli

  • WAL etkinleştirilmiş şekilde SQLite çalıştıran tüm uygulamalar, özellikle de birden fazla işlem (process) veya iş parçacığı (thread) eşzamanlı olarak yazma yapıyorsa.
  • Gecikme süresinin ve önbelleğe almanın zamanlama uç durumlarını (edge cases) artırdığı, standart olmayan veya ağ üzerinden erişilen dosya sistemlerindeki dağıtımlar.
  • Sağlıklı görünen bir SQLite dosyasını veri bütünlüğünün garantisi olarak kabul eden altyapı servisleri.

Önleme adımları

  1. SQLite'ı Güncelleyin – 3.46.1 veya daha yeni bir sürüme geçin; WAL hatası burada düzeltildi.
  2. Bütünlük kontrolleri çalıştırın – Veritabanının dahili yapılarını doğrulamak için periyodik olarak PRAGMA integrity_check; veya daha hızlı olan PRAGMA quick_check; komutunu çalıştırın.
  3. WAL kullanımını denetleyin – Kod tabanlarında journal_mode=WAL ayarlarını tarayın ve eşzamanlılık seviyesinin bunları hak edip etmediğine karar verin.
  4. İzlemeyi güçlendirin – Sadece erişilebilirliği onaylamak yerine, beklenen veri modellerini veya satır sayılarını karşılaştıran kontroller ekleyin.
  5. Sürekli yedek alın – Bozulma gerçekleşirse bir güvenlik ağı sağlayan ve SQLite değişikliklerini gerçek zamanlı olarak kopyalayan Litestream gibi araçlar kullanın.

Bu olay ne öğretiyor

  • Eski hatalar yeni yükler altında ortaya çıkabilir – Servisler ölçeklendikçe, bir zamanlar nadir olan modeller yaygınlaşır ve eski kusurları açığa çıkarır.
  • Sessiz bozulma, bir çökmeden daha tehlikelidir – Bir çökme yeniden başlatmaya zorlar ve genellikle uyarıları tetikler; sessiz veri kaybı ise haftalarca fark edilmeyebilir.
  • Açık post-mortem raporları ekosisteme yardımcı olur – Tailscale'in ayrıntılı yazısı, diğer ekiplere kendi dağıtımlarını hızlıca denetlemek için ihtiyaç duydukları bilgiyi sağladı.

Bundan sonra neye dikkat edilmeli

Tailscale, haberi paylaşmadan önce bir düzeltmenin hazır olduğundan emin olmak için SQLite ekibiyle birlikte çalıştı.

Özetle: 16 yıl boyunca fark edilmeden kalan bir hata, modern iş yüklerinin SQLite'ı orijinal geliştiricilerinin asla hayal etmediği şekillerde zorlaması nedeniyle yeniden ortaya çıktı. Kütüphaneyi güncellemek, bütünlük kontrolleri çalıştırmak ve gözlemlenebilirliği artırmak, benzer gizli hatalara karşı korunmanın en hızlı yollarıdır.