Patroni ile PostgreSQL High Availability: "Kesinti Olmazsa Olmaz, Patroni Varsa Sorun Olmaz!"

"PostgreSQL harika bir veritabanı... ama kesinti yaşandığında? Patroni burada devreye giriyor."

PostgreSQL, tek başına son derece güvenilir ve performanslı bir veritabanıdır. Ancak işler büyüdüğünde, yani veritabanını dağıtık bir sistem içinde birden fazla sunucuda yüksek erişilebilir şekilde kullanmak istediğinizde, birtakım zorluklar ortaya çıkar:

• Lider (primary) sunucu arızalanırsa ne olacak?
• Yedek sunucular (replica) ne zaman devreye girmeli?
• Manuel müdahale mi gerekiyor?
• Veri tutarlılığı ve erişilebilirlik arasında denge nasıl sağlanacak?

İşte bu gibi durumlarda Patroni hayat kurtarıyor.

Patroni, PostgreSQL için otomatik failover, leader election (lider seçimi), health check ve cluster yönetimi sağlayan bir HA (High Availability) yöneticisidir. Aslında Patroni, PostgreSQL'e HA kazandıran akıllı bir düzenleyici (orchestrator)'dir. Basit bir anlatımla Patroni:

• Etcd veya Consul gibi bir dağıtık KV store ile küme durumunu tutar,
• Sunucuların sağlığını izler,
• Lider düştüğünde otomatik olarak yeni bir lider seçer ve şekli değiştirir,
• PostgreSQL'in replikasyon ayarlarını dinamik olarak düzenler.

Bu yazıda HAProxy veya PgBouncer gibi ara katmanlardan bahsetmeyeceğiz. Onlara özel yazılar yakında yayınlanacak, takipte kalın!

CAP teoremi der ki: Üç şeyden sadece ikisini seçebilirsin:

1. Consistency (Tutarlılık)

2. Availability (Erişilebilirlik)

3. Partition Tolerance (Bölünebilirlik toleransı)

Dağıtık sistemlerde ağ bölünmeleri (partition) kaçınılmaz olduğuna göre, geriye tutarlılık (Consistency) ile erişilebilirlik (Availability) arasında bir seçim yapmak kalıyor. Patroni, "Consistency + Partition Tolerance" tarafını seçer. Neden?

• Birden fazla primary (yazılabilir) sunucuya izin vermez.
• Yazılacak verilerin tutarlığını korumaya öncelik verir.
• Ancak bu durum, bazen sistemi yazma işlemleri için geçici olarak erişilemez hale getirebilir.

Patroni, bir liderin kim olduğunu ve cluster'ın genel sağlık durumunu merkezi olarak tutmak için bir KV Store'a ihtiyaç duyar. Bu genellikle:

• etcd
• veya Consul üzerinden yapılır.

Bu sistemler:

• RAFT protokolü ile dağıtık bir consensus sağlar,
• Yüksek erişilebilirlik sağlamak için en az 3 node ile çalışırlar,
• Patroni her sunucuda bu KV store'a yazma ve okuma işlemleri yapar.

Patroni, lider seçimini Etcd üzerinden gerçekleştirir. Süreç şuna benzer:

1. Her PostgreSQL örneği, bağlı olduğu Patroni botu aracılığıyla Etcd'de belirli bir anahtarın süresi dolmuş olup olmadığını kontrol eder.

2. Eğer liderlik anahtarı boştaysa, bot bu anahtarı belirli bir süreliğine almak için Etcd'ye başvurur.

3. Etcd, arka planda RAFT protokolü kullanarak yalnızca bir örneğin bu anahtarı almasına izin verir. Böylece yarış durumları engellenmiş olur.

4. Anahtarı ilk alan örnek, sistemin lideri olarak kabul edilir ve Patroni botu bu PostgreSQL örneğini primary (lider) olacak şekilde yapılandırır.

5. Diğer örnekler, bu liderliği fark eder ve kendilerini otomatik olarak replica (yedek) moduna alır.

Bu sayede lider, merkezi bir kontrol noktası olmadan dağıtık biçimde ve tutarlı şekilde seçilir.

• Single Primary mimarisi: Aynı anda yalnızca bir sunucu yazılabilir durumda olur.
• Etcd/Consul'a bağımlılık: Bu sistemler de HA olmalı. Aksi halde Patroni de çalışamaz.
• Split-brain önleme: Yanlış lider seçimi olmaması için karmaşık kontrol mekanizmaları gerekir.

Basit bir örnek için 3 PostgreSQL + Patroni konteyneri ve 3 etcd konteyneri kullanabiliriz:

Öncelikle geliştirici github reposundan proje dosyasını temin ediniz. Proje dosyasındaki Dockerfile'ı build ederek örnekte kullanacağımız patroni docker image'ını oluşturunuz.

^{Konuya dair örnek (Yazar tarafından oluşturulmuştur)}

Patroni, PostgreSQL'i HA yapıya taşımak için oldukça etkili ve esnek bir çözümdür.

Bir sonraki yazımızda, Patroni cluster'ına HAProxy ile yönlendirme yapmayı ve PgBouncer ile bağlantı havuzu oluşturmayı anlatacağız. Kaçırmayın! 

Takipte Kalın, Verileriniz Ayakta Kalsın!