PostgreSQL Destek ve Danışmanlık

Autovacuum ayarlarını tablo bazında yapılandırıyoruz #

PostgreSQL bir satırı güncellediğinde eski sürümü silmez, yeni bir satır sürümü yazar ve eskisini ölü (dead tuple) olarak işaretler. Çok sürümlü eşzamanlılık denetimi (MVCC) adı verilen bu tasarım, okuyan işlemlerin yazan işlemleri beklememesini sağlar. Karşılığında ölü satırların düzenli olarak temizlenmesi gerekir ve temizliği autovacuum süreci yürütür.

Autovacuum varsayılan ayarlarıyla küçük tablolarda sorunsuz çalışır. Sorun tablo büyüdükçe ortaya çıkar. Varsayılan eşik, tablodaki satırların yaklaşık yüzde yirmisi ölü hâle geldiğinde temizliği başlatır. Yüz milyon satırlık bir tabloda bu eşik, bakımın yirmi milyon ölü satır biriktikten sonra başlaması demektir. Temizlik bu hacimde hem uzun sürer hem de üretim yükünü belirgin şekilde etkiler. Doğru yaklaşım eşikleri tablo bazında düşürmek, yani bakımı daha sık ve daha küçük parçalar hâlinde çalıştırmaktır.

Temizlenmeyen ölü satırların bir başka sonucu şişmedir (bloat). Tablo ve indeks dosyaları diskte büyümeye devam eder, sorgular aynı veriyi okumak için daha fazla disk bloğu taramak zorunda kalır ve planlayıcı yanlış tahminler üretmeye başlar. Şişmeyi pgstattuple ile ölçüyor, tespit ettiğimiz tabloları üretimi durdurmadan çalışan pg_repack aracıyla topluyoruz.

En sert sonuç ise işlem numarası sarmasıdır (transaction ID wraparound). PostgreSQL işlem numaralarını sınırlı bir aralıkta tutar ve autovacuum bu numaraları düzenli olarak dondurarak aralığın tükenmesini engeller. Bakım yapılmayan bir sistemde aralık tükendiğinde veritabanı, veri bütünlüğünü korumak amacıyla yeni yazma işlemlerini kabul etmeyi bırakır. Sarma durumundan çıkış yalnızca planlı kesinti alınarak yapılan bir bakımla mümkün olur ve kesinti süresi veri boyutuyla doğru orantılı büyür.

Devraldığımız her PostgreSQL sisteminde ilk olarak en çok ölü satır biriktiren tabloları, son autovacuum zamanlarını ve işlem numarası aralığında kalan payı ölçüyoruz.

Bağlantı havuzunu uygulamanın davranışına göre kuruyoruz #

PostgreSQL, kendisine bağlanan her istemci için ayrı bir işletim sistemi süreci başlatır. Süreç başına ayrılan bellek ve zamanlayıcı maliyeti, bağlantı sayısı arttıkça doğrusal biçimde büyür. Birkaç yüz eşzamanlı bağlantıya ulaşan sistemlerde sunucu, asıl işi yapmak yerine bağlantı yönetmekle meşgul olmaya başlar.

Çözümü max_connections değerini yükseltmek değil, bağlantı havuzu (connection pooling) kurmak sağlar. PgBouncer uygulama ile PostgreSQL arasına girer ve gelen bağlantıları arka uçta çok daha az sayıda bağlantı üzerinden karşılar.

Havuz modunun seçimi kurulumun asıl kararıdır:

• Session modu, bağlantıyı istemci kapatana kadar aynı arka uç bağlantısına bağlı tutar. Uygulama açısından en güvenli moddur, kazanç ise en düşük seviyede kalır.
• Transaction modu, arka uç bağlantısını her işlem sonunda havuza iade eder ve en yüksek verimi sağlar. Buna karşılık advisory lock, oturum değişkenleri, LISTEN/NOTIFY ve geçici tablolar gibi oturum düzeyinde durum tutan özellikler bu modda güvenilir çalışmaz.

Uygulamanın bu özellikleri kullanıp kullanmadığını kurulum öncesinde ölçüyoruz. Ölçüm yapılmadan transaction moduna geçirilen bir sistemde ortaya çıkan hatalar, tek tek yeniden üretilmesi güç olan türdendir.

Sürüm yükseltmelerini kesinti bütçesine göre planlıyoruz #

PostgreSQL her yıl yeni bir ana sürüm yayımlar ve her ana sürüm ilk yayımından itibaren beş yıl boyunca desteklenir. Destek süresi dolan sürümler için güvenlik yaması yayımlanmaz. Üretim sistemlerinde sürüm planını takvime bağlıyor, destek kapsamının bir parçası olarak yürütüyoruz.

Yükseltme iki yöntemden biriyle yapılır ve seçim kabul edilebilir kesinti süresine bağlıdır:

• pg_upgrade, bağlantı (link) modunda çalıştırıldığında veri dosyalarını kopyalamaz. Yükseltme süresi veri boyutuna değil veritabanındaki nesne sayısına bağlı kalır ve kopyalama yapan yönteme göre çok daha kısa sürer. Karşılığında kısa bir planlı kesinti alınır ve geri dönüş için önceden alınmış bir yedek gerekir.
• Mantıksal çoğaltma (logical replication) üzerinden yükseltme, yeni sürümü ayrı bir sunucuda ayağa kaldırır ve veri akışını kurar. Kesinti yalnızca uygulamanın yönlendirilmesi kadar sürer. Dizilerin (sequence) ve şema değişikliklerinin çoğaltılmadığı bilinmeli, geçiş planı bunları ayrıca ele almalıdır.

Eklentileri ve dağıtımı sistemin ihtiyacına göre seçiyoruz #

PostgreSQL’in yeteneklerinin önemli bölümü eklentilerle gelir ve hangi eklentinin kurulacağı, sistemin ne yapması gerektiğine göre belirlenir. Operasyonel tarafta şu eklentileri düzenli olarak kullanıyoruz: sorgu istatistikleri için pg_stat_statements, şişme ölçümü için pgstattuple, bakım için pg_repack, denetim kaydı için pgaudit, veri maskeleme ve anonimleştirme için PostgreSQL Anonymizer.

Disk üzerinde şifreleme (encryption at rest) ayrı bir başlıktır ve burada dağıtım tercihi belirleyici olur. Çekirdek PostgreSQL bu yeteneği içermez. Şifrelemeyi, Percona’nın açık kaynak dağıtımıyla gelen pg_tde bileşeni sağlar ve bu bileşen dağıtımın kendi yamalarına ihtiyaç duyar. KVKK denetimlerinde şifreleme talebi gündeme geldiğinde, çekirdek PostgreSQL’den Percona dağıtımına geçişi de kapsayan bir plan çıkarıyoruz.

Bu geçişi de üreticiden bağımsız yürütüyoruz. Kullandığımız bileşenlerin tamamı açık kaynak lisanslıdır ve kurulum ile entegrasyon hakkımız bu lisanslardan doğuyor.

Yönetilen bulut servislerinde PostgreSQL desteği #

Amazon RDS for PostgreSQL, Amazon Aurora PostgreSQL, Google Cloud SQL ve Azure Database for PostgreSQL kullanan kurumlara da destek veriyoruz. Yönetilen serviste gerçek anlamda superuser yetkisi verilmez ve kurulabilecek eklentiler sağlayıcının izin verdiği listeyle sınırlı kalır. shared_preload_libraries gibi parametreler yalnızca parametre grupları üzerinden değiştirilebilir.

Buna karşılık bu sayfanın anlattığı bakım çalışmasının neredeyse tamamı yönetilen serviste de geçerlidir. Autovacuum eşikleri tablo bazında ayarlanır, şişme ölçülür, pg_stat_statements verisi analiz edilir, indeks tasarımı ve bağlantı yönetimi aynı şekilde ele alınır. Sağlayıcı donanımı, yedeği ve sürüm yükseltmesinin altyapısını yönetir. Tablo bakımı ile sorgu tasarımı ise kurumun kendi sorumluluğunda kalır.

Aurora PostgreSQL’de çoğaltma mimarisi paylaşımlı depolama katmanı üzerine kuruludur ve standart streaming replication’dan farklı davranır. Erişilebilirlik tasarımını bu farkı hesaba katarak yapıyoruz.

Çalışma biçimimiz #

Sistemlerinize gizlilik sözleşmesi (NDA) kapsamında, atlama sunucunuz (jump host) ya da VPN’iniz üzerinden uzaktan bağlanıyoruz. PostgreSQL kullanıcımız için yalnızca yapılacak işin gerektirdiği yetkileri talep ediyor, uyguladığımız her değişikliği kayıt altına alıyoruz.

Çalışmaya ölçümle başlıyoruz. Bir PostgreSQL sistemini ilk devraldığımızda sürüm ve yapılandırma envanterini, autovacuum ve şişme tablosunu, replikasyon topolojisini, yedekleme ve geri yükleme durumunu, bağlantı profilini ve iş yükünün sorgu profilini çıkarıyoruz. Önerileri bu ölçümün üzerine kuruyoruz.

Bakımını sürdürdüğümüz sistemlerde yük ve yavaş sorgu ölçümlerini proaktif izleme kapsamında yaklaşık gerçek zamanlı (near real-time) değerlendiriyor, oluşabilecek sorunları ortaya çıkmadan önce raporluyoruz. Aynı ölçümler kurumun kapasite ve yük planlamasına da veri sağlıyor.

Üretim ortamındaki değişiklikleri önce test ortamında doğruluyor, her biri için geri dönüş adımını önceden hazırlıyoruz. Her değişikliği uygulamadan önce raporlayıp onayınızı alıyor, değişiklik yönetimi (change management) ilkesi gereği her seferinde tek değişiklik uyguluyoruz. Kendi değişiklik kaydımıza ek olarak, tüm işlemlerimizin sunucu tarafında izlenebilmesi için PostgreSQL denetim kaydı (audit log) tutulmasını talep ediyoruz.

İlgili hizmetler #

Aynı çalışmaları MySQL, MariaDB ve MongoDB için de yürütüyoruz: MySQL Destek · MariaDB Destek · MongoDB Destek

Bağlantı katmanında MySQL tarafındaki karşılığı ProxySQL’dir. Okuma ve yazma trafiğinin ayrılması aynı problemin çözümüdür: ProxySQL Destek ve Danışmanlık

PostgreSQL destek talebinizi iletin