PostgreSQL High Availability - Patroni 1

Patroni, PostgreSQL HA (High Availability) Cluster yapısının kurulması ve yönetimi için kullanılan open source bir araçtır. Patroni, PostgreSQL Cluster’inin kurulumu (bootstrap), replikasyonunun kurulumu, PostgreSQL otomatik failover yapılması amacıyla kullanılır. Python ile yazılmıştır.

Bir önceki yazıda PostgreSQL'de Autofailover araçlarının ne olduğu ve neden Autofailover'a gereksinim duyulduğu konusunda yazı paylaşmıştım. Yazıya buradan ulaşabilirsiniz.

Patroni Kurulumu İçin Gereksinimler nedir?
Patroni’nin tek başına kurulumu autofailover yapısını yapılandırmak için yeterli değildir. Patroni ile Autofailover yapısının kurulması için DCS (Distributed Configuration Store) araçlarından birine ihtiyaç vardır. Bunlardan bazıları; ETCD, Consul, ZooKeeper, Kubernetes.

PostgreSQL üzerinde Autofailover araçlarından Patroni entegre edecekseniz DCS araçlarından birini kullanmanız gerekecek. DCS dediğimiz şey aslında Service Discovery araçlarından biri olduğundan bu iki tanımın ne anlama geldiğini öğrenmek, autofailover yapısının entegre edilmesinde konuyu kavramak açısından önemlidir.

Service Discovery Nedir?
Uygulamalar ve veritabanları monolitic tarzda kurgulanmaya başlandı son zamanlarda. Microservice adı verilen bu monolitic yapılar kendi içinde birden fazla komponent barındırırlar. Amaç, küçük parçaların diğerlerinden bağımsız maintain edilmesi ve bu sırada senkronize çalışan diğer parçaların bundan etkilenmemesidir.

Service Discovery, microservice’lerin birbiri arasındaki iletişiminden sorumludur. Microservice mimarisini oluşturan sunucular statik IP’ye sahiptir. IP’lerin değişmesi gibi bir durum söz konusu olduğunda değişen bu IP adresleri konfigürasyon dosyalarından okunur.

Modern microservice’lerde uygulamaların doğru network lokasyonu dinamik IP adreslerinin kullanılmasıyla daha da zorlaşabilir. Bu durumda Service Discovery araçları ile Key-Value değerinin saklanmasıyla (service registry) sunucular arasında iletişim sağlanabilir. Yani IP bağımsız sunucu arasında iletişimi sağlar.

Sunucular service registry üzerinde kaydedilir ve servis down olduğunda veya healthy olmadığında silinir. Service registry olduğunda sunuculardaki servisler birbirlerinin network lokasyonlarını bilir. Yeni bir komponent deploy edilmesiyle diğer servislerin ednpoint’lerinin latency olmadan bulunması oldukça etkili hale gelir.

Service Discovery üç ana yapıdan oluşur:

• Service Provider: Servis registry olduğunda kendini register eder, sistemden ayrıldığında kendini deregister eder.
• Service Consumer: Registery’den provider’ın (salayıcı) lokasyonunu bulur ve provider ile konuşur.
• Service Registy: Provider’ların son lokasyonlarını maintain eder.

DCS (Distributed Configuration Store) Nedir?
DCS dediğimiz yapı, Service Discovery yapısının bir parçasıdır. Konfigürasyon dosyalarının cluster içindeki node'lar arasında güncel kalmasını sağlarlar. Global Distributed Service Discovery sisteminin avantajlarından biri komponentlerin çalışması için gereksinim duyduğu herhangi tipteki konfigürasyon dosyasının saklanabilir olmasıdır.

Autofailover yapısını 3 node’lu bir veritabanı Cluster’ı için kurduğumuzu düşünelim. Tüm node’lar üzerindeki konfigürasyon dosyalarının birbiri arasında güncel kalmasını sağlayan yapıya gereksinim vardır çünkü iki standby sunucular primary olarak çalışma durumu söz konusu olabilir. Aynı konfigürasyon değerlerinin yeni primary için de geçerli olması gerekir.

Patroni ve DCS
Patroni konfigürasyonu da DCS içinde saklanır. Patroni için üç ayrı konfigürasyon çeşidi vardır.

• Dynamic Configuration: Dinamik konfigürasyonlar DCS içinde saklanır ve bir değişiklik olduğunda tüm node’lara aynı değişiklik async olarak uygulanır. Startup konfigürasyonlarından olmayan değişiklikler DCS içinde herhangi bir zamanda set edilebilir. Dinamik konfigürasyon parametrelerinden bazıları şunlardır: ttl, loop_wait, synchronous_mode..
• Local Configuration (patroni.yml): patroni.yml içinde yapılacak konfigürasyon değişikliği dynamic konfigürasyonda olan değişikliği ezer. Değişikliğin gerçekleşmesi Patroni’yi restart etmeden sadece reload edilmesi ile gerçekleştirilir.
• Environment Configuration: Patroni konfigürasyon dosyasındaki değişiklikler Environment değişkenlerinin set edilmesiyle mümkün olur. Aşağıda bazı Environment Configuration parametreleri bulunmaktadır. Bu parametrelere buradan ulaşabilirsiniz.

Failure Saptaması Nasıl Gerçekleşir?
Component’lerden birinin fail olduğunu discovery service yardımıyla bilinebilir. Birçok discovery service platformları timeout kontrolü ile ilerler. Component’in timeout’a düşmesi ile bir değişkene yeni değer verilir ve discovery service belirli aralıklarla component’lere ping atar. Eğer component fail olur ve timeout süresine ulaşılırsa instance’in bağlantı bilgileri store üzerinden silinir.

Bir sonraki yazıda Patroni kurulumu mevcut. Yazıya buradan ulaşabilirsiniz.

Autofailover yazı serilerine aşağıdan ulaşabilirsiniz.

PostgreSQL ve Autofailover
PostgreSQL'de Autofailover ve Patroni 1 (Giriş)
PostgreSQL'de Autofailover ve Patroni 2 (Kurulum, Konfigürasyon ve Yönetim)
PostgreSQL'de Autofailover ve Patroni 3 (Mevcut PostgreSQL Cluster'inin Patroni'ye Geçirilmesi)