PostgreSQL HA: Patroni ile Failover Runbook’u

PostgreSQL yüksek erişilebilirlik (HA) konusu genelde “replication var mı?” sorusuna sıkışır. Oysa üretimde asıl soru şudur: primary gittiğinde kim lider olacak ve uygulama ne kadar sürede toparlanacak?

Patroni, bu problemi otomatik lider seçimi ve kontrollü failover/switchover ile çözer. Ama Patroni’yi “kurup bırakmak” yerine runbook olarak işletmek gerekir; yoksa kriz anında split-brain, veri kaybı veya uzun kesinti üretirsiniz.

1) Ön koşullar: HA tasarımının kırmızı çizgileri

Bu yazı vendor/ortam bağımsızdır ama bazı gerçekler değişmez:

• Patroni, bir DCS (Distributed Configuration Store) ile lider seçer (etcd/Consul/ZooKeeper vb.)
• DCS quorum’u bozulursa, HA “otomatik” olmaktan çıkar
• Replika gecikmesi (lag), failover kararını doğrudan etkiler

2) Minimum gözlem seti

Üretimde Patroni işletmek için minimum sinyaller:

• DCS sağlığı: quorum, leader, latency
• Patroni cluster durumu: primary/replica rol dağılımı
• Replication lag (byte/time)
• DB health: connection count, locks, WAL, disk
• Uygulama tarafı: reconnect davranışı ve timeout

3) Günlük kontrol: “her şey yolunda mı?”

3.1 Cluster görünümü

En azından şu ritmi oturtun:

• günde 1 kez patronictl list çıktısına bakmak
• “hangi node leader?” sorusunun her zaman net olması

3.2 Replica gecikmesi

Failover sırasında en kritik risk “geride kalmış replica’nın leader olması”dır. Bu yüzden:

• lag için SLO belirleyin (ör. p95 < 1s veya < 16MB)
• lag artınca “failover yeteneği düşer” diye düşünün

4) Planlı geçiş: Switchover runbook’u

Switchover, kontrollü bir primary değişimidir. Üretimde en çok değer üreten test budur çünkü:

• gerçek kullanıcı trafiği altında çalışır
• risk daha yönetilebilir

Minimum akış:

1. DCS quorum sağlıklı
2. Replica lag düşük
3. Uygulama connection pool retry stratejisi doğrulandı
4. Switchover başlat (Patroni komutu)
5. Yeni leader doğrulama: read/write test
6. Eski leader’ın replica olduğundan emin ol

5) Plansız kayıp: Failover triage runbook’u

5.1 İlk 5 dakika kontrol listesi

• Primary gerçekten down mı? Yoksa network/dns mi bozuldu?
• DCS quorum var mı? (quorum yoksa otomatik failover durabilir)
• Replica lag anormal mi? (yüksek lag → veri kaybı riski)
• Uygulama tarafında “read-only” veya retry storm var mı?

5.2 En sık hata: Network partition’ı “DB down” sanmak

Primary canlı ama ekip erişemiyorsa:

• Patroni diğer node’u leader yapabilir
• Primary de kendini leader sanmaya devam edebilir

Bu split-brain için en tipik zemin. Bu yüzden partition şüphesi varsa:

• önce network/DCS tarafını doğrulayın
• gerekirse failover’ı durdurup kontrolü ele alın

6) Geri dönüş: Failover sonrası stabilizasyon

Failover başarıyla olduysa iş bitmez:

• Eski primary’nin tekrar cluster’a dönüşü (rejoin) kontrollü yapılmalı
• Uygulama pool’ları yeni leader’a düzgün bağlanmış olmalı
• Replika sayısı ve dağılımı tekrar “beklenen” hale getirilmeli

Minimum checklist:

• Yeni primary write alıyor
• Replica’lar stream ediyor
• Lag normal sınıra döndü
• Connection pool saturation yok
• Backup job’ları yeni primary’ye göre çalışıyor

PostgreSQL HA, sadece “replication açık” demek değildir. Patroni ile asıl kazanç; lider seçimi, otomatik karar ve runbook disiplinidir. Quorum’u birinci sınıf tasarlayıp switchover tatbikatını rutin hale getirdiğinizde, HA üretimde gerçekten HA olur.