PostgreSQL’de sürekli erişilebilir (HA) bir küme yapılandırması (cluster configuration) kurmak, çeşitli replikasyon (replication) metodları ile mümkündür. Sıklıkla Warm Standby veya Log Shipping şeklinde anılan replikasyon modellerinde sürekli arşivleme (continuous archiving); birincil/ana (primary/master) sunucu başarısız olursa işlemleri devralmaya hazır bir ya da daha fazla yedek (replica) sunucu olması ile sağlanır.
Bu yazıda, ana (master) sunucuyu çeşitli sebeplerden dolayı kaybedersek (fail scenarios) replika (yedek) sunucuyu nasıl birincil/ana sunucuya yükseltebileceğimizi (promote) göreceğiz.
Öncelikle yük dağıtma (failover) senaryosunun düzgün tamamlanabilmesi için ana sunucudaki postgresql servisinin durmuş olduğundan emin olmalıyız. Aynı anda çift master rolü olan bir replikasyon beklenmedik sonuçlar doğuracaktır. O yüzden imkan varsa -sunucu erişilmez hale gelmiş olabilir; donanımsal sorunlar vs-, önce ana (master) sunucudaki postgresql servisini durdurmalıyız.
[root@master~]# service postgresql stop
Daha sonra replika sunucuya geçip onu “promote” edeceğiz. Replika sunucusu biz işleme başlamadan önceki halinde kurtarma (recovery) modundadır, “promote” ettiğimiz zaman kurtarma (recovery) modundan çıkıp okuma-yazma operasyonlarını kabul edecek hale gelir.
Replika sunucunun kurtarma (recovery) modunda olduğunu şu basit sorgu ile anlayabiliriz:
postgres=# Select pg_is_in_recovery(); pg_is_in_recovery ------------------- t (1 row)
Replika sunucuda bu sorgunun sonucu yukarıdaki gibi doğru (true) dönecektir, master sunucuda ise yanlış (false) döndüğünü deneyip görebilirsiniz.
Terfi (promote) işleminden sonra şu an ‘t’ dönen sonuç ‘f’ olarak değişecektir. Promote pg_ctl ile sağlanan komutlardan biridir.
pg_ctl komutlarını çalıştırmak için postgres kullanıcısına geçiyoruz ve pg_ctl promote komutunu aşağıdaki gibi çalıştırıyoruz:
[root@replica~]# su postgres bash-4.1$ /usr/pgsql-9.2/bin/pg_ctl promote -s -D /var/lib/pgsql/9.2/data
Komut içinde kullandığımız -s parametresi sadece hata olursa mesaj basan, bilgilendirme mesajlarını basmayan sessiz modda çalışması içindir. Diğer parametre olan -D parametresi ise data dizininin yoludur yani veri tabanı dosyalarının sistemde bulunduğunu yeri verdiğimiz parametredir. Biz bunu belirtmezsek PGDATA ile belirtilen yolu kullanacaktır.
Komut çalıştırıldığında replika sunucumuz artık ana sunucu olmuştur ve okuma yazmaya açıktır.
Bu işlemi yapmanın promote dışındaki yolu recovery.conf dosyasında yolu belirtilen şekilde ve o isimde bir trigger dosyası yaratmaktır. Ben “promote” metodunu kullanmayı seviyorum.
Bu şekilde sorunsuzca çok sayıda terfi (promote) işlemini tamamladım.
Ek not olarak pg_hba.conf dosyasını eskiden master olan sunucuda nasılsa o şekilde replikaya almakta fayda var. Böylece ana sunucuya bağlanması gerekenlerin izinlerini, sistemde kopma yaşamadan vermiş olursunuz. Bu gerekçeler yüzünden bu tip sorunlar ile karşılaşmadan önce tüm konfigürasyon dosyalarınızı yedeklemenizi tavsiye ederim. Gitlab/Github ve türevleri üzerinde bir config reposu oluşturup tüm postgresql.conf, pg_hba.conf, recovery.conf gibi konfigürasyon dosyalarınızı versiyonlayarak yedekleyebilirsiniz.
Bir de terfi (promote) işlemini yaptıktan sonra PostgreSQL loglarına bakıp, bir süre izlemenizde fayda vardır. Gözden kaçan ufak tefek şeyler olabilir. Ayrıca böyle bir durumdan sonra incelediğiniz loglar replikanız master olduğunda nasıl davrandı, normale nasıl döndü, sonrasında neler yazıldı görmek açısından avantajlıdır. Böylece sorunlu durum ile sağlıklı durum arasındaki geçişte deneyim edinmiş olursunuz.
İşinize yaraması dileğimle.
Kaynaklar