Amazon RDS’de PostgreSQL 17.4 analizi - Snapshot Isolation garanti edilmiyor

• Amazon RDS for PostgreSQL’ün multi-AZ kümesi resmî olarak Snapshot Isolation’ı desteklese de, pratikte bunu ihlal eden G-nonadjacent cycle ve Long Fork olayı sıkça ortaya çıkıyor
• Testler, doğrudan yapılandırılmış PostgreSQL transaction workload’u temel alınarak yürütüldü ve PostgreSQL 13.15’ten 17.4’e kadar tüm sürümlerde tutarlılık hataları oluştuğu görüldü
• Bu hatalar çoğunlukla salt okunur secondary node’larda ortaya çıkıyor ve "Repeatable Read" düzeyinde bile Snapshot Isolation bozuluyor
• RDS kümesi Parallel Snapshot Isolation düzeyinde tutarlılık sağlıyor olabilir; bu, temel PostgreSQL tek düğüm modelinden daha zayıf bir model
• Salt okunur transaction’lar birbirinden farklı transaction sıralamaları gözlemleyebilir ve bu tür uyumsuzluklar veri bütünlüğü hatalarına yol açabilir

---

Background

• PostgreSQL, MVCC tabanlı açık kaynaklı bir SQL veritabanıdır ve çeşitli transaction isolation düzeyleri sunar. Repeatable Read, pratikte Snapshot Isolation anlamına gelir
• Amazon RDS, PostgreSQL’ü yönetilen bir küme olarak sunar ve Multi-AZ yapılandırması replikasyon ile hata toleransı için kullanılan bir mimaridir
• Birincil endpoint okuma/yazma destekler, secondary’ler salt okunurdur ve Serializable düzeyini desteklemez

Test Design

• Jepsen PostgreSQL test aracı, RDS’ye uyarlanacak şekilde sarmalanarak otomatik transaction testleri yürütüldü
• Transaction’lar, belirli anahtarlardaki listeleri okumak veya benzersiz tam sayılar append etmek üzere tasarlandı; cycle tespiti için Elle checker kullanıldı
• 150 TPS yazma ve 1600 TPS okuma yükünde 2 dakika içinde Long Fork ve G-nonadjacent ortaya çıktığı doğrulandı

Results

• 4 transaction’dan oluşan bir G-nonadjacent cycle üzerinden Snapshot Isolation ihlali kanıtlandı
  • T₂, T₁’in değişikliklerini gözlemledi ama T₃’ü görmedi; T₄ ise T₃’ü gördü ama T₁’i görmedi → zamansal sırada karşılıklı çelişki oluşuyor
• Bu durum Long Fork olayıdır ve aynı zamanda Snapshot Isolation ihlalini gösteren güçlü bir örnektir
• Write Skew tespit edilmemesi, Parallel Snapshot Isolation olasılığını destekliyor

Discussion

• Multi-AZ RDS, tek düğümlü PostgreSQL’den daha düşük bir tutarlılık düzeyi sunuyor
• Salt okunur node kullanıldığında tutarlılık hatası olasılığı bulunduğu için, yalnızca yazma düğümünü kullanmak veya tüm transaction’lara en az bir yazma işlemi eklemek değerlendirilmeli
• Bu analiz ilk test düzeyindedir ve sorunun varlığını kanıtlar, ancak yokluğunu garanti etmez

[GN⁺]

Hacker News görüşü

• Başlıkta açıkça belirtilmemiş olsa da, bu RDS'nin yeni özelliği olan multi-AZ cluster ile ilgili

  • Multi-AZ instance, birincil veritabanının başka bir AZ'deki ikincil veritabanına senkron olarak çoğaltıldığı eski özelliktir
  • Multi-AZ cluster'da iki ikincil veritabanı bulunur ve transaction en az bir ikincil veritabanına senkron olarak çoğaltılır
  • Bu, ikincil veritabanı başarısız olduğunda veya performansı düştüğünde daha dayanıklıdır ve ikincil veritabanına salt okunur erişim sağlar
  • Multi-AZ cluster, standart bir Postgres özelliği değildir ve Jepsen testinde başarısız olmasının nedeni bu olabilir

• Önceki şirkette yedekleme betiğindeki pg_dump komutunu paralel worker'lar (-j bayrağı) kullanacak şekilde değiştirdiğimizde, yedek geri yükleme sırasında tutarlılık sorunları (yinelenen anahtar hataları ve fk kısıt hataları) ortaya çıkmıştı

  • Sorunu AWS ve Postgres mailing listelerine bildirdik, ancak kolayca yeniden üretilemediği için çözülemedi
  • Sonunda tekrar tek iş parçacıklı dump'a döndük; bunun yaşadığımız davranışla ilgili olup olmadığını merak ediyorum

• Jepsen bu çalışmayı bağımsız olarak yürüttü ve bunun için ödeme almadı

  • Bu, iyi bir günde RDBMS paydaşlarının duymak istemeyeceği türden bir haber
  • aphyr'e saygılar

• Bu sorunun pratik anlamı, aynı satıra yapılan bir yazmadan kısa süre sonra gerçekleşen okumanın eski veriyi döndürebilmesidir

  • Yazma transaction'ı tamamlandı olarak işaretlenmeden önce multi-AZ RDS instance'ının tüm dağıtık katmanları tam olarak güncellenmediğinden, anlık okuma var olmayan satırları veya eski değerleri döndürebilir
  • PostgreSQL'in snapshot yaklaşımı nedeniyle, multi-byte sütun türlerinde yalnızca bazı baytların güncellenmesi ve okumanın anlamsız bir değer alması gibi bir durum söz konusu değil
  • Bu, sonuçta tutarlı hale gelen bir race condition gibi görünüyor

• Multi-instance upstream Postgres cluster'da sorun olmadığı net değil

  • AWS'nin cluster yapılandırmasına bir şey ekleyip eklemediğini veya bu davranışa yol açan bir patch ekleyip eklemediğini merak ediyorum

• Gönderilen başlık asıl noktayı gizliyor: PostgreSQL 17.4 için RDS, snapshot isolation'ı düzgün şekilde uygulamıyor

• Geliştiriciler snapshot isolation varsayarken Amazon RDS for PostgreSQL gerçekte yalnızca parallel snapshot isolation sağlıyorsa, özellikle read replica endpoint kullanan multi-AZ yapılandırmalarında bunun ne tür güvenlik veya uygulama düzeyi hatalara yol açabileceğini merak ediyorum

• Test edilen 13.15'ten 17.4'e kadar tüm sürümlerde bu durum görüldü

  • Ana sürümü yükseltmenin yanlış bir seçim olup olmadığından endişe etmiştim, ancak bu bir regression değil; bir özellik talebi ya da uzun süredir var olan bir hata

• Amazon RDS'nin tüm sürümlerinin Jepsen ile test edilmesi iyi olurdu

• AWS'nin bunu iletmek için belgeleri güncellemesi gerekir

  • Snapshot isolation düzeltmesinin gecikme veya throughput açısından performans gerilemesine yol açıp açmayacağını ya da mevcut durumun yeterince güçlü olduğunu iddia edip etmeyeceklerini merak ediyorum
  • Her iki durumda da AWS'nin bundan bahsetmesi gerekir