Kesintisiz Postgres Yükseltmesi

Postgres yükseltmesi için hazırlık

• Risk değerlendirmesi: Yükseltme sürecinde ortaya çıkabilecek risklerin bir listesini hazırlayın ve önem derecesine göre sıralayın.
• Risk çözüm yolları arama: Riskleri tamamen ortadan kaldırabilecek veya zamana yayarak dağıtabilecek çözümleri değerlendirin.
• Risk listesini güncelleme: Proje ilerledikçe yeni riskler keşfedildiğinde listeyi güncelleyin.

İzleme ve metrikler hakkında

• Sistem izleme: Veritabanı ve sistem sağlığını izlemek için kapsamlı araçlar kullanın.
• Temel metrikleri gözlemleme: Transaction ID, CPU kullanımı, bekleyen oturumlar, sorgu gecikmesi, API yanıt gecikmesi gibi temel metrikleri izleyin.

Postgres yükseltme seçenekleri

Yerinde yükseltme (sıfır kesintiyle yükseltme için uygun değil)

• Yerinde yükseltmenin sınırlamaları: AWS RDS üzerinde çalıştırıldığında veritabanının yeniden başlatılması gerekir; süre veri miktarına göre değişir.

Replikasyon tabanlı yükseltme

• Replikasyon tabanlı yükseltmeyi seçme: Kademeli migration adımları sunar, yeni veritabanını gerçek iş yükü ve verilerle test etmeyi sağlar ve yükseltme üzerinde daha fazla kontrol verir.
• Kaynak ve hedef veritabanını yapılandırma: Replikasyon slotlarını ayarlayın, wal_level değerini logical olarak belirleyin.

Tablo replikasyon yöntemini seçme

"Küçük" tabloların replikasyonu

• Küçük tablo replikasyonu: Basit bir ekleme ve abonelik yenilemesiyle replikasyon yapılabilir.

Büyük, yalnızca ekleme yapılan tablolar

• Yalnızca ekleme yapılan tabloların replikasyonu: copy_data seçeneğini false olarak ayarlayıp yalnızca gelecekteki değişiklikleri replike edin, ardından eski verileri yedekten backfill yapın.

Çok sayıda güncelleme alan büyük tablolar

• Yoğun güncellenen büyük tabloların replikasyonu: Tablo boyutunu küçültün, VACUUM çalıştırın ve tablo partitioning kullanmayı değerlendirin.

Tablo replikasyon durumunu kontrol etme

• Replikasyon durumunu izleme: Replikasyon durumunu pg_subscription_rel sistem tablosu üzerinden kontrol edin; aynı anda yalnızca bir tablonun replike edilmesi önerilir.

Replikasyonu durdurma

• Replikasyonu durdurma yöntemi: Gerekirse tablo replikasyonunu durdurabilir ve abonelik yenilemesiyle rollback yapabilirsiniz.

Replikasyon slotu taşıma konusunda dikkat

• Replikasyon slotu taşıma sorunu: Replikasyon slotunun LSN değeri birincil veritabanına özgü olduğundan yeni veritabanına doğrudan kopyalanamaz.

Migration'ı tamamlama

• Tablo tutarlılığını doğrulama: İki veritabanı arasında tablo satır sayılarının eşleştiğini doğrulayın; gerekirse rastgele örnekleme ile veri tutarlılığını kontrol edin.

Uygulama düzeyinde değişiklikler

• Veritabanı bağlantısını değiştirme: Uygulamayı yeni veritabanına bağlayacak şekilde değiştirin ve trafik geçiş stratejisini planlayın.

Sequence'ler hakkında ek notlar

• Sequence senkronizasyonu: Replikasyon sürecinde sequence değerleri senkronize edilmez; bu nedenle sequence değerlerini manuel olarak ayarlayın.

Son kontrol checklist'i

• Son kontrol: Tablo tutarlılığı, abonelik durumu, şema eşleşmesi, veritabanı boyutu, replika ekleme, indeks yeniden oluşturma, performans testi, risk değerlendirmesi ve staging ortamında prova.

Son geçiş

• Son geçişin uygulanması: Akşam saatlerinde tablo replikasyonu yapın, staging ortamında birden fazla kez prova ettikten sonra son kontrolü tamamlayın ve flag değişimini gerçekleştirin.

GN⁺ görüşü

• Önem: Knock, Postgres 11.9'dan 15.3'e sıfır kesintiyle yükseltmenin karmaşık sürecini başarıyla tamamladı. Bu, veritabanı yönetimi ve hizmet erişilebilirliği açısından önemli bir dönüm noktasıdır.
• İlgi çekicilik: Replikasyon tabanlı yükseltme yaklaşımı, veritabanı yöneticilerine yeni veritabanına sorunsuz bir geçiş olanağı sunuyor; bu da teknik topluluğun büyük ilgisini çekebilir.
• Eğlenceli yön: Knock'un yükseltme süreci, sistematik risk yönetimi ve problem çözme adımlarıyla karmaşık teknik zorlukların nasıl aşılabileceğine dair örnek bir uygulama gösteriyor.

[GN⁺]

Hacker News görüşü

• Büyük tabloları kopyalamaktan daha iyi bir yöntem var.

  • Replikasyon slotu oluşturma, snapshot alma, snapshot’ı yeni instance’a geri yükleme, LSN ilerletme ve replikasyonu başlatma adımlarıyla mantıksal bir replika oluşturulabilir.
  • Instacart’ın yazısı bu süreci açıklıyor.
  • Yazıda küçük hatalar olabilir, ancak TB ölçeğindeki instance’ları yükseltmek için bu yöntem defalarca başarıyla kullanıldı.

• Burada sunulan yaklaşım ilginç ve iyi belgelenmiş, ancak "modern müşteriler %100 erişilebilirlik bekler" cümlesine katılmıyorum.

  • Müşteri ya da sağlayıcı olarak deneyimime göre, erişilebilirlikten çok tutarlılık önemli.
  • Bir vendor planlı bir kesinti duyurduğunda, bunu verilere özenle yaklaşıldığının işareti olarak görüp rahatlıyorum.

• AWS artık blue-green deployment destekliyor.

• Sorunların çoğunu otomatikleştiren bir araç yazdım.

  • Araç GitHub’da paylaşılıyor ve geri bildirim ya da fikirlerle genişletilebilir.

• hava.io’da AWS RDS PostgreSQL 11.13’ten 15.5’e geçiş yapıyoruz.

  • pglogical kullanan tek yönlü replikasyon yaklaşımını seçtik.
  • Bu yaklaşım hızlı değil, ancak veritabanını yeni instance’a kademeli olarak kopyalamak birkaç gün sürebiliyor.
  • Depolama türünü ve boyutunu değiştirmek için daha fazla esneklik sağlıyor.

• Knock hizmeti için hiçbir kesintinin kabul edilemez olduğu iddiasına şüpheyle yaklaşıyorum.

  • Karmaşık sistemlerde kazalar ve kesintiler olur.
  • Önceden duyurulmuş 15 dakikalık bir kesinti çoğu SaaS işi için sorun değildir.
  • Mühendislik zamanını ürün geliştirmeye ya da geliştirme ekibinin hızını artırmaya yatırmak, kullanıcılara daha fazla memnuniyet sağlayabilir.
  • Veritabanı migration’larında "az kesinti" ile "sıfır kesinti" çözümü üretmek arasındaki iş yükü farkı büyüktür.

• Replikasyonun yedekten başlatılamamasına şaşırdım.

  • Mevcut kararlı DB içeriğini yeni sunucuya stream etme zahmetini azaltabilirdi.
  • "Sıfır kesinti" deniyor ama gerçekte yeni sunucuya geçiş sırasında birkaç saniyelik kesinti var.
  • Tutarlılığın nasıl korunduğuna dair ayrıntılar eksik.
  • Geri alma seçeneğinden söz edilmiyor; büyük veriler için tek seferlik bir taşıma işlemi yaparken her zaman önceki aşamaya dönecek bir plan gerekir.

• Sadece veritabanı kimlik bilgilerini girerek Postgres’i sıfır kesintiyle güncelleyen hepsi bir arada bir araca ilgi olup olmadığını soruyor.

• Sequence kullanımıyla ilgili kısım ilginç.

  • Sequence yerine çoğunlukla sıralı UUID ya da HiLo algoritması kullanıyorum.

• Dağıtık sistemlerde ortaya çıkan sorunların uygun bir sleep(1000) ile çözülebileceğini şakayla söylüyor.

  • Postgres DBA’lere çok tanıdık gelen bir sistem değil, ama eskisine göre daha iyi.