PostgreSQL 19, veri sağlama toplamlarını (checksum) çevrimiçi etkinleştirerek sessiz depolama bozulmalarını yakalıyor

Yeni olan ne

PostgreSQL 19, cluster trafik hizmet vermeye devam ederken veri checksum'larını açma yeteneği ekliyor. dev.to'da Franck Pachot'un paylaştığı uygulamalı bir yazıya göre, yeni bir fonksiyon olan pg_enable_data_checksums(), checksum'ları arka planda etkinleştiriyor ve cluster'ı kapatma olmadan tamamen doğrulanmış bir duruma getiriyor; çalışan iş yükü üzerindeki etkiyi azaltmak için kısıtlama (throttling) uygulanabiliyor.

Checksum'lar neden önemli

Checksum'lar olmadan PostgreSQL, diskten okuma yaparken her sayfa başlığında yalnızca temel sağlamlık kontrolleri yapar. Sayfa içeriklerinin kendisi kriptografik olarak doğrulanmaz; bu yüzden veritabanının altında, depolama veya I/O katmanında oluşan bozulmalar fark edilmeden geçebilir ve sessizce yanlış sorgu sonuçları üretebilir.

Riski göstermek için Pachot, PostgreSQL 19 beta 3 container imajını kullanarak bir cluster'ı initdb'nin --no-data-checksums seçeneğiyle başlattı, 'Hello World!' metnini içeren bir tablo oluşturdu ve veriyi shared buffers'dan dışarı çıkardı. Ardından dosyanın içeriğini doğrudan sed ile değiştirdi. PostgreSQL tabloyu tekrar okuduğunda, hiçbir uyarı vermeden değiştirilmiş değeri döndürdü.

Yazının belirttiği gibi, checksum'lar PostgreSQL 18'den itibaren yeni başlatılan cluster'larda varsayılan olarak geliyor; diskten her okumada doğrulanıyor ve her yazmada yeniden hesaplanıyorlar. Ancak önceki sürümlerden yükseltilen cluster'lar genellikle hâlâ checksum'sız çalışıyor ve geleneksel çözüm olan pg_checksums aracı, büyük kurulumlarda ciddi zaman alabilecek bir tarama için cluster'ın kapatılmasını gerektiriyor.

Çevrimiçi etkinleştirme nasıl çalışıyor

Yeni fonksiyon superuser erişimi gerektiriyor ve primary üzerinde çalıştırılmalı; ortaya çıkan durum değişiklikleri WAL üzerinden standby'lara kopyalanıyor. İlerleme, mevcut aşamayı ve tamamlanan veritabanı, ilişki (relation) ve blok sayılarını raporlayan pg_stat_progress_data_checksums görünümünden izlenebiliyor. data_checksums ayarı, off durumundan ara bir inprogress-on durumu üzerinden, tüm bloklar işlendikten sonra on durumuna geçiyor. Yardımcı bir fonksiyon olan pg_disable_data_checksums(), aynı kısıtlamalar altında ayarı geri alıyor.

Checksum'lar açıldığında ne değişiyor

Korumalı bir cluster üzerinde dosya değiştirme deneyinin tekrarlanması, bozuk çıktı yerine etkilenen ilişkiyi ve bloğu belirten sert bir invalid-page hatası üretti. Bu hata, özelliğin amaçlandığı gibi çalıştığının göstergesi: görünmez bir sorunu görünür bir soruna dönüştürüyor ve operatörün, kötü veri daha fazla yayılmadan önce bir standby'a geçmesini veya bir yedekten geri yüklemesini sağlıyor.

Yedekler de koruma kazanıyor. Demoda pg_basebackup, kopyalama sırasında checksum'ları doğruladı ve bir uyuşmazlık bildirdikten sonra iptal etti. Doğrulama yapmayan yedekleme araçları için Pachot, geri yüklemeyi pg_checksums --check ile doğrulamayı öneriyor.

Planlama sırasında dikkat edilecek noktalar

Yazı several operasyonel dikkat noktası sıralıyor:

• Etkinleştirme işlemi iki background-worker slotu tüketir, bu yüzden max_worker_processes için pay bırakmak gerekir.
• Her veritabanındaki açık transaction'ların ve geçici tabloların bitmesini bekler; tek bir uzun oturum işlemi süresiz geciktirebilir.
• Sayfalar çalışma sırasında checksum'lanır, ancak okumalar yalnızca on'a yapılan son geçişten sonra doğrulanır.
• inprogress-on durumundayken bir çökme veya yeniden başlatma, tüm sürecin baştan başlaması anlamına gelir.
• Standby'larda WAL replay'i engelleyen zorunlu restart point'lere ihtiyaç duyulabilir; bu da birincil duraklatabilecek replikasyon gecikmesi yaratabilir. İşlem öncesi max_wal_size'ı azaltmak bunu hafifletebilir.

Neden önemli

Sessiz veri bozulması, bir veritabanının yaşayabileceği en kötü arıza türlerinden biridir; çünkü yedekler, kopyalar ve uygulamalar depolama katmanının teslim ettiği her şeyi sadakatle yayarak aktarır. Checksum'lar bu senaryoyu açık bir hataya dönüştürür. Şimdiye kadar mevcut bir cluster'da bunları etkinleştirmek, verinin boyutuyla orantılı bir bakım penceresi anlamına geliyordu; uzun süredir çalışan birçok kurulumun bunu hiç yapmamış olmasının nedeni muhtemelen buydu. Çevrimiçi etkinleştirme, çoğu kurulum için bu engeli kaldırıyor; ancak dikkat noktalarının gösterdiği gibi, sıfır etkili bir işlem değil ve diğer her bakım görevinde olduğu gibi aynı zamanlama ve izleme özenini hak ediyor.