PostgreSQL 12 ile Ubuntu 20.04 Üzerinde Fiziksel Akış Replikasyonu (Streaming Replication) Kurulumu

PostgreSQL 12 ile Ubuntu 20.04 Üzerinde Fiziksel Akış Replikasyonu (Streaming Replication) Kurulumu

Replikasyon Nedir ve Neden Önemlidir?

Veritabanı sistemlerinde replikasyon (çoğaltma), verinin bir veritabanı sunucusundan (primary/ana sunucu) bir veya daha fazla başka sunucuya (standby/bekleme sunucusu) kopyalanması ve senkronize edilmesidir. Bu süreç, modern veritabanı mimarilerinin temel taşlarından biridir ve kritik iş uygulamaları için vazgeçilmezdir. PostgreSQL gibi kurumsal düzeyde bir veritabanı yönetim sistemi, çeşitli replikasyon yöntemleri sunarak veri güvenliği, yüksek erişilebilirlik (High Availability – HA) ve yük dengeleme (Load Balancing) gibi ihtiyaçları karşılar.

Replikasyonun başlıca faydaları şunlardır:

* Veri Güvenliği ve Felaket Kurtarma (Disaster Recovery): Ana sunucunun donanımsal arıza, yazılım hatası veya doğal afet gibi nedenlerle erişilemez hale gelmesi durumunda, replike edilmiş bir yedek sunucu sayesinde veri kaybı en aza indirilir ve hizmet kesintisi süresi kısaltılır.
* Yüksek Erişilebilirlik: Birincil sunucu çevrimdışı kaldığında, bekleme sunucusu hızlı bir şekilde birincil sunucu rolünü üstlenerek uygulamanın çalışmaya devam etmesini sağlar. Bu, hizmetin sürekli olarak erişilebilir olmasını garanti eder.
* Yük Dengeleme: Salt okunur sorgular (read-only queries), bekleme sunucularına yönlendirilerek birincil sunucunun yükü azaltılabilir. Bu sayede birincil sunucu, yazma işlemlerine daha fazla odaklanabilir ve genel sistem performansı artırılabilir.
* Raporlama ve Analiz: Yoğun raporlama veya analiz işlemleri, üretim veritabanını etkilemeden bekleme sunucuları üzerinde çalıştırılabilir.

PostgreSQL, temel olarak iki tür replikasyon sunar:
* Mantıksal Replikasyon (Logical Replication): Belirli tabloları veya veritabanlarını replike etmek için kullanılır. Farklı PostgreSQL sürümleri veya hatta farklı veritabanı sistemleri arasında replikasyon yapılmasına olanak tanır. Veri değişimleri, SQL düzeyinde mantıksal bir formatta gönderilir.
* Fiziksel Replikasyon (Physical Replication): Veritabanı kümesinin tamamını, blok seviyesinde kopyalar. Bu, birincil sunucunun birebir kopyasını oluşturur. Bu makalede odaklanacağımız “Streaming Replication” (Akış Replikasyonu) fiziksel replikasyonun bir türüdür.

Fiziksel akış replikasyonu, PostgreSQL’in Write-Ahead Log (WAL) dosyalarını kullanarak çalışır. Birincil sunucuda yapılan her değişiklik (ekleme, güncelleme, silme), WAL dosyalarına yazılır. Bekleme sunucusu, bu WAL kayıtlarını sürekli olarak birincil sunucudan alır ve kendi veri dizinine uygular. Bu sayede, bekleme sunucusu her zaman birincil sunucunun güncel bir kopyası olarak kalır. Fiziksel replikasyonun avantajları arasında yüksek performans, kolay kurulum (özellikle pg_basebackup ile) ve birincil sunucuyla tam uyumluluk bulunur.

Ön Gereksinimler

Bu makaledeki kurulum adımlarını takip etmek için aşağıdaki ön gereksinimlere sahip olmanız gerekmektedir:

* İki Adet Ubuntu 20.04 Sunucusu:
* Birincil (Primary) Sunucu: PostgreSQL 12 kurulu ve çalışır durumda. Örnek IP: 192.168.1.10
* Bekleme (Standby) Sunucu: PostgreSQL 12 kurulu, ancak replikasyon kurulumu sırasında veritabanı durdurulacak ve temizlenecektir. Örnek IP: 192.168.1.11
* Ağ Bağlantısı: Her iki sunucu arasında ağ bağlantısı olmalı ve 5432 numaralı PostgreSQL portu üzerinden iletişim kurulabilmelidir.
* Güvenlik Duvarı Ayarları: Gerekirse, her iki sunucunun güvenlik duvarında 5432 portunun açıldığından emin olun.
* SSH Erişimi: Her iki sunucuya da root veya sudo yetkilerine sahip bir kullanıcı ile SSH üzerinden erişiminiz olmalı.
* PostgreSQL 12 Kurulumu: Her iki sunucuya da PostgreSQL 12’nin kurulu olduğundan emin olun. Kurulum talimatları bu makalenin kapsamı dışında tutulsa da, genel olarak sudo apt update && sudo apt install postgresql-12 komutu ile kurulabilir.
* Yeterli Disk Alanı: Her iki sunucuda da veritabanı boyutunu kaldırabilecek yeterli disk alanı bulunmalıdır.

Terminoloji ve Kavramlar

Replikasyon kurulumuna başlamadan önce bazı temel terimleri anlamak faydalı olacaktır:

* Primary (Ana) Sunucu: Veritabanına yazma işlemlerinin yapıldığı ve tüm değişikliklerin başladığı sunucudur. Aynı zamanda bekleme sunucularına WAL kayıtlarını gönderir.
* Standby (Bekleme) Sunucu: Birincil sunucudan WAL kayıtlarını alarak kendini güncel tutan sunucudur. Fiziksel replikasyonda, bekleme sunucusu birincil sunucunun tam bir kopyasıdır. Hot Standby modunda okuma sorgularına izin verebilir.
* WAL (Write-Ahead Log): PostgreSQL’in veri bütünlüğünü sağlamak ve felaket kurtarma yeteneklerini desteklemek için kullandığı işlem günlüğü dosyalarıdır. Her veritabanı değişikliği önce WAL’a yazılır, ardından veri dosyalarına uygulanır. Replikasyon, bu WAL dosyalarının bekleme sunucusuna aktarılmasıyla gerçekleştirilir.
* Timeline (Zaman Çizelgesi): Bir PostgreSQL veritabanı kümesinin yaşam döngüsündeki bir noktayı temsil eder. Birincil sunucu bir hata durumunda kurtarıldığında veya bir bekleme sunucusu birincil sunucuya terfi ettirildiğinde yeni bir zaman çizelgesi (timeline) oluşturulur. Bu, geçmiş WAL dosyalarının karışmasını önler.
* Replication Slot (Akış Replikasyonu Yuvası): Birincil sunucuda tanımlanan kalıcı bir mekanizmadır. Bekleme sunucusunun WAL kayıtlarını almayı bırakması durumunda, birincil sunucunun bu WAL kayıtlarını silmesini engeller. Bu, bekleme sunucusunun tekrar çevrimiçi olduğunda eksik WAL dosyaları nedeniyle replikasyonun bozulmasını önler. Replikasyon slotları, özellikle ağ kesintileri veya bekleme sunucusu bakımları sırasında veri kaybı riskini önemli ölçüde azaltır.
* standby.signal: PostgreSQL 12 ve sonraki sürümlerde, recovery.conf dosyasının yerini alan sinyal dosyasıdır. Veri dizininde bu dosyanın varlığı, PostgreSQL sunucusunun bekleme modunda başlaması gerektiğini belirtir. Replikasyon ayarları ise postgresql.conf dosyasına taşınmıştır.
* PITR (Point-in-Time Recovery): Belirli bir zamana geri dönerek veritabanını kurtarma yeteneğidir. Fiziksel akış replikasyonu, PITR için de temel oluşturur çünkü WAL dosyaları bu kurtarma işlemi için gereklidir.

Kurulum Adımları

Şimdi adım adım fiziksel akış replikasyonunu kurmaya başlayalım.

1. PostgreSQL Kurulumu

Her iki sunucuda da PostgreSQL 12’nin kurulu olduğundan emin olun. Eğer kurulu değilse aşağıdaki komutları kullanarak kurabilirsiniz:

sudo apt update
sudo apt install postgresql-12

Kurulum tamamlandıktan sonra PostgreSQL servisi otomatik olarak başlayacaktır.

2. Ağ Yapılandırması ve Güvenlik Duvarı

İki sunucu arasındaki iletişimin sorunsuz olduğundan emin olmalıyız. Örnek IP adreslerimiz:
* Primary Sunucu: 192.168.1.10
* Standby Sunucu: 192.168.1.11

Her iki sunucuda da UFW (Uncomplicated Firewall) kullanıyorsanız, PostgreSQL’in varsayılan portu olan 5432’ye erişime izin vermelisiniz:

sudo ufw allow 5432/tcp
sudo ufw enable
sudo ufw status

ufw status çıktısında 5432 portunun izinli olduğunu görmelisiniz.

3. Primary Sunucu Ayarları (192.168.1.10)

Primary sunucuda PostgreSQL’in replikasyona izin verecek şekilde yapılandırılması gerekmektedir.

3.1. postgresql.conf Düzenlemeleri

PostgreSQL yapılandırma dosyası genellikle /etc/postgresql/12/main/postgresql.conf yolundadır. Bu dosyayı bir metin düzenleyici ile açın:

sudo nano /etc/postgresql/12/main/postgresql.conf

Aşağıdaki parametreleri bulun ve değerlerini ayarlayın (eğer yorum satırı halindeyse # işaretini kaldırın):

listen_addresses = '': PostgreSQL’in tüm ağ arayüzlerinden gelen bağlantıları dinlemesini sağlar. Yalnızca belirli bir IP adresinden bağlantıları kabul etmek isterseniz, o IP adresini de belirtebilirsiniz (örn: 'localhost,192.168.1.10').
* wal_level = replica: Replikasyon için gerekli minimum WAL bilgilerinin günlüğe kaydedilmesini sağlar. PostgreSQL 9.6’dan itibaren hot_standby yerine replica kullanılması önerilir.
* max_wal_senders = 10: Aynı anda kaç adet bekleme sunucusunun veya pg_basebackup işleminin birincil sunucudan WAL akışı alabileceğini belirler. En az bekleme sunucusu sayısı kadar olmalı, yedekli olması için biraz daha yüksek ayarlanması tavsiye edilir.
* wal_keep_segments = 64: Birincil sunucunun diskte kaç adet WAL segmentini saklayacağını belirler. Bekleme sunucusunun birincil sunucudan geride kalması durumunda, bu segmentler sayesinde replikasyonun devam etmesi sağlanır. Çok düşük bir değer, bekleme sunucusunun WAL dosyalarını kaçırmasına ve replikasyonun bozulmasına neden olabilir. Genellikle 32-128 arasında bir değer yeterlidir, ancak iş yükünüze ve ağ gecikmelerine göre ayarlanmalıdır. Replikasyon slotları kullanıldığında bu parametrenin önemi azalır, ancak yine de bir miktar tampon görevi görür.
* hot_standby = on: Bu parametre aslında bekleme sunucusu için geçerlidir, ancak pg_basebackup -R komutu primary’de de bu ayarı bulup kopyalayacağı için burada da belirtmekte fayda var.

Kaydedip dosyayı kapatın.

3.2. pg_hba.conf Düzenlemeleri

Bu dosya, PostgreSQL’e kimlerin ve nereden bağlanabileceğini kontrol eder. pg_hba.conf dosyası genellikle /etc/postgresql/12/main/pg_hba.conf yolundadır.

sudo nano /etc/postgresql/12/main/pg_hba.conf

Dosyanın sonuna aşağıdaki satırı ekleyin:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replicator      192.168.1.11/32         md5

* host: TCP/IP bağlantıları için.
* replication: Replikasyon bağlantıları için özel bir veritabanı adı.
* replicator: Replikasyon için kullanacağımız kullanıcı adı.
* 192.168.1.11/32: Bekleme sunucusunun IP adresi. /32 maskesi sadece bu IP’den gelen bağlantılara izin verir. Birden fazla bekleme sunucunuz varsa, her biri için ayrı bir satır ekleyebilir veya bir IP aralığı belirtebilirsiniz (örn: 192.168.1.0/24).
* md5: Bağlantı için parola tabanlı kimlik doğrulama kullanır. Daha güvenli bir yöntemdir. Test amaçlı trust kullanmaktan kaçının.

Kaydedip dosyayı kapatın.

3.3. Replikasyon Kullanıcısı Oluşturma

Primary sunucuda, bekleme sunucusunun bağlanmak için kullanacağı özel bir replikasyon kullanıcısı oluşturmalıyız. postgres kullanıcısına geçiş yapın ve psql konsolunu açın:

sudo -i -u postgres
psql

psql konsolunda aşağıdaki komutu çalıştırın:

CREATE USER replicator REPLICATION LOGIN CONNECTION LIMIT -1 ENCRYPTED PASSWORD 'your_secure_password';

* replicator: Kullanıcı adı.
* REPLICATION: Bu kullanıcının replikasyon bağlantıları kurabileceğini belirtir.
* LOGIN: Bu kullanıcının giriş yapabileceğini belirtir.
* CONNECTION LIMIT -1: Bağlantı sayısı üzerinde bir limit olmadığını belirtir.
* ENCRYPTED PASSWORD 'your_secure_password': Güvenli bir parola belirleyin. 'your_secure_password' kısmını kendi parolanızla değiştirin.

\q yazarak psql konsolundan çıkın ve exit yazarak postgres kullanıcısından çıkın.

3.4. PostgreSQL Servisini Yeniden Başlatma

Yaptığınız yapılandırma değişikliklerinin etkili olması için PostgreSQL servisini yeniden başlatın:

sudo systemctl restart postgresql@12-main

Servisin sorunsuz çalıştığını kontrol edin:

sudo systemctl status postgresql@12-main

3.5. Replikasyon Slotu Oluşturma (Önerilir)

Replikasyon slotları, bekleme sunucusu çevrimdışı olsa bile birincil sunucunun gerekli WAL segmentlerini saklamasını garanti eder. Bu, bekleme sunucusu tekrar çevrimiçi olduğunda replikasyonun kaldığı yerden devam etmesini sağlar ve WAL dosyalarının eksikliği nedeniyle replikasyonun bozulmasını önler.

postgres kullanıcısı olarak psql konsoluna girin ve slotu oluşturun:

sudo -i -u postgres
psql -c "SELECT * FROM pg_create_physical_replication_slot('standby_slot');"

Burada 'standby_slot' replikasyon slotunun adıdır. Bu adı bekleme sunucusu yapılandırmasında kullanacağız.
Slotun başarıyla oluşturulduğunu doğrulamak için:

SELECT slot_name, slot_type, active, restart_lsn, wal_status FROM pg_replication_slots;

Çıktıda standby_slot adında, physical tipinde ve active: f (şu anda aktif değil, çünkü standby bağlı değil) bir slot görmelisiniz.

4. Standby Sunucu Ayarları (192.168.1.11)

Şimdi bekleme sunucusunu primary sunucunun bir kopyası olacak şekilde yapılandıracağız.

4.1. Mevcut Veritabanını Durdurma ve Temizleme

Bekleme sunucusundaki PostgreSQL servisini durdurun ve mevcut veri dizinini temizleyin. Bu işlem, bekleme sunucusundaki tüm mevcut veriyi silecektir. Üretim ortamında bu adımı atmadan önce çok dikkatli olun ve yedek aldığınızdan emin olun.

sudo systemctl stop postgresql@12-main

Veri dizinini temizleyin:

sudo rm -rf /var/lib/postgresql/12/main/*

Bu komut, /var/lib/postgresql/12/main dizini altındaki tüm dosya ve dizinleri siler.

4.2. Veritabanı Kopyalama (Base Backup)

pg_basebackup aracı, birincil sunucudan bekleme sunucusuna veritabanının başlangıç kopyasını (base backup) almak için kullanılır. Bu, replikasyonun başlangıç noktasını oluşturur.

Bekleme sunucusunda, postgres kullanıcısı olarak aşağıdaki komutu çalıştırın:

sudo -i -u postgres
pg_basebackup -h 192.168.1.10 -D /var/lib/postgresql/12/main -U replicator -P -v -R -X stream -S standby_slot

Bu komutun parametreleri şunlardır:
* -h 192.168.1.10: Birincil sunucunun IP adresi.
* -D /var/lib/postgresql/12/main: Bekleme sunucusunda veritabanı dosyalarının kopyalanacağı dizin. Bu, PostgreSQL’in varsayılan veri dizinidir.
* -U replicator: Birincil sunucuda oluşturduğumuz replikasyon kullanıcısı.
* -P: İlerleme göstergesini etkinleştirir.
* -v: Ayrıntılı (verbose) çıktı sağlar.
* -R: Bu çok önemli bir parametredir. PostgreSQL 12 ve sonraki sürümler için, bekleme sunucusunun veri dizininde standby.signal dosyasını oluşturur ve postgresql.conf içine primary_conninfo ayarını ekler. Bu ayarlar, bekleme sunucusunun birincil sunucuya nasıl bağlanacağını ve replikasyonu nasıl başlatacağını belirtir.
* -X stream: WAL (Write-Ahead Log) dosyalarını temel yedekleme ile birlikte akış olarak alır. Bu, yedekleme tamamlandıktan sonra hemen replikasyonun başlamasını sağlar.
* -S standby_slot: Birincil sunucuda oluşturduğumuz replikasyon slotunun adını belirtir. Bu, WAL dosyalarının kaybolmamasını garanti eder.

Komutu çalıştırdıktan sonra, replicator kullanıcısının parolasını girmeniz istenecektir.

4.3. standby.signal ve postgresql.conf Kontrolü/Düzenlemesi

pg_basebackup -R komutu, gerekli ayarları otomatik olarak yapar. Ancak yine de kontrol etmek ve gerekirse düzenlemek önemlidir.

* standby.signal dosyası: /var/lib/postgresql/12/main/ dizininde standby.signal adında boş bir dosya bulunmalıdır. Bu dosyanın varlığı, PostgreSQL’in bekleme modunda başlamasını sağlar.
* postgresql.conf içindeki primary_conninfo: pg_basebackup komutu, /var/lib/postgresql/12/main/postgresql.conf dosyasının sonuna primary_conninfo ayarını eklemiş olmalıdır. Bu ayarı kontrol edin ve gerekirse düzenleyin:

sudo nano /var/lib/postgresql/12/main/postgresql.conf

Aşağıdaki satırı görmelisiniz (veya benzerini):

primary_conninfo = 'host=192.168.1.10 port=5432 user=replicator password=your_secure_password application_name=standby1'

* host: Birincil sunucunun IP adresi.
* port: Birincil sunucunun PostgreSQL portu.
* user: Replikasyon kullanıcısı.
* password: Replikasyon kullanıcısının parolası. Bu parolanın buraya yazılması güvenlik açısından ideal değildir. Daha güvenli bir yöntem için .pgpass dosyasını kullanmak veya sslmode gibi ayarları yapılandırmak önerilir. Ancak basit bir kurulum için bu yöntem kullanılabilir.
* application_name: Bu, birincil sunucudaki pg_stat_replication görünümünde bekleme sunucusunu tanımlamak için kullanılan bir isimdir.

Ayrıca, bekleme sunucusunun okuma sorgularına izin vermesi için hot_standby = on ayarını da kontrol edin ve etkinleştirin (eğer otomatik olarak eklenmediyse):

hot_standby = on

Kaydedip dosyayı kapatın.

4.4. Veri Dizini İzinlerini Ayarlama

pg_basebackup komutu genellikle doğru izinlerle dosyaları kopyalar, ancak yine de emin olmak için veri dizininin sahibi ve izinlerini kontrol edin:

sudo chown -R postgres:postgres /var/lib/postgresql/12/main
sudo chmod -R 0700 /var/lib/postgresql/12/main

Bu komutlar, veri dizininin sahibini postgres kullanıcısı ve grubuna ayarlar ve yalnızca sahibin okuma, yazma ve çalıştırma izinlerine sahip olmasını sağlar.

4.5. PostgreSQL Servisini Başlatma

Artık bekleme sunucusundaki PostgreSQL servisini başlatabilirsiniz:

sudo systemctl start postgresql@12-main

Servisin sorunsuz çalıştığını kontrol edin:

sudo systemctl status postgresql@12-main

Servis in recovery durumunda başlamalı ve birincil sunucuya bağlanarak WAL kayıtlarını almaya başlamalıdır.

5. Replikasyon Durumunu Kontrol Etme

Replikasyonun doğru şekilde çalışıp çalışmadığını doğrulamak için her iki sunucuda da bazı kontroller yapmalıyız.

5.1. Primary Sunucuda Kontrol

Primary sunucuda postgres kullanıcısı olarak psql konsoluna girin:

sudo -i -u postgres
psql

Replikasyon durumunu kontrol etmek için aşağıdaki sorguyu çalıştırın:

SELECT client_addr, state, sync_state, sync_priority, application_name FROM pg_stat_replication;

Çıktıda bekleme sunucusunun IP adresi (client_addr), bağlantı durumu (state – streaming olmalı), senkronizasyon durumu (sync_state – async veya sync olabilir, varsayılan olarak async), senkronizasyon önceliği ve application_name (standby1 olarak ayarlamıştık) görünmelidir. state sütunu streaming ise, replikasyon başarıyla çalışıyor demektir.

Replikasyon slotunun durumunu kontrol etmek için:

SELECT slot_name, slot_type, active, restart_lsn, confirmed_flush_lsn FROM pg_replication_slots;

Bu sorgunun çıktısında standby_slot‘un active: t (true) olduğunu görmelisiniz. restart_lsn ve confirmed_flush_lsn değerleri de artıyor olmalıdır.

5.2. Standby Sunucuda Kontrol

Standby sunucuda postgres kullanıcısı olarak psql konsoluna girin:

sudo -i -u postgres
psql

Sunucunun kurtarma modunda olup olmadığını kontrol edin:

SELECT pg_is_in_recovery();

Bu sorgu t (true) döndürmelidir, bu da sunucunun bekleme modunda çalıştığı anlamına gelir.

WAL kayıtlarının alındığı ve uygulandığı son konumları kontrol edin:

SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();

Bu iki LSN (Log Sequence Number) değeri yakın olmalı veya aynı olmalıdır. pg_last_wal_receive_lsn() alınan son WAL konumunu, pg_last_wal_replay_lsn() ise uygulanan son WAL konumunu gösterir. Eğer pg_last_wal_receive_lsn() sürekli olarak pg_last_wal_replay_lsn()‘den yüksekse, bu replikasyon gecikmesi (lag) olduğunu gösterir.

5.3. Veri Ekleme ve Sorgulama Testi

Replikasyonun gerçekten çalıştığını doğrulamak için primary sunucuda bir veri ekleyin ve ardından hemen standby sunucuda bu veriyi sorgulayın.

Primary Sunucuda:

sudo -i -u postgres
psql

CREATE DATABASE test_db;
\c test_db;
CREATE TABLE my_table (id SERIAL PRIMARY KEY, name VARCHAR(100), created_at TIMESTAMP DEFAULT NOW());
INSERT INTO my_table (name) VALUES ('Test Verisi 1');
INSERT INTO my_table (name) VALUES ('Test Verisi 2');
SELECT * FROM my_table;

\q ile çıkın.

Standby Sunucuda:

sudo -i -u postgres
psql

\c test_db;
SELECT * FROM my_table;

Standby sunucuda my_table içindeki verileri görmelisiniz. Eğer görüyorsanız, fiziksel akış replikasyonu başarıyla kurulmuş demektir! \q ile çıkın.

Yüksek Erişilebilirlik ve Failover

Fiziksel akış replikasyonu, yüksek erişilebilirliğin temelini oluşturur. Ancak, birincil sunucunun çökmesi durumunda bekleme sunucusunun otomatik olarak birincil sunucuya terfi etmesi (failover) için ek araçlara ihtiyaç vardır.

Manuel Failover Süreci

Birincil sunucu tamamen erişilemez hale geldiğinde, bekleme sunucusunu manuel olarak birincil sunucuya terfi ettirebilirsiniz. Bu, dikkatli bir süreç gerektirir:

1. Birincil Sunucunun Erişilemez Olduğunu Doğrulayın: Öncelikle primary sunucunun gerçekten çöktüğünden ve geri gelemeyeceğinden emin olun. Yanlış bir terfi, “split-brain” senaryosuna yol açabilir (iki primary sunucu aynı anda çalışır ve veri tutarsızlığına neden olur).
2. Bekleme Sunucusunu Terfi Ettirin: Bekleme sunucusunda postgres kullanıcısı olarak aşağıdaki komutu çalıştırın:

sudo -i -u postgres
    pg_ctlcluster 12 main promote

Alternatif olarak, veri dizininde promote sinyal dosyası oluşturabilirsiniz:

touch /var/lib/postgresql/12/main/promote

Bu komut veya dosya, bekleme sunucusunun kurtarma modundan çıkıp birincil sunucu rolünü üstlenmesini sağlar.
3. Uygulamaları Yeni Primary’ye Yönlendirin: Uygulamalarınızın veritabanı bağlantı dizelerini (connection strings) yeni primary sunucunun IP adresine veya ana bilgisayar adına güncelleyin.
4. Eski Primary’yi Kapatın (Gerekirse): Eğer eski primary sunucu hala çalışıyorsa veya tekrar çevrimiçi olursa, split-brain’i önlemek için onu kapatmalısınız.
5. Yeni Standby Kurulumu: Eğer eski primary sunucuyu onarıp tekrar kullanmak isterseniz, onu yeni primary sunucunun bir beklemesi olarak yeniden yapılandırmanız gerekecektir. Bu, yukarıda anlatılan pg_basebackup ve diğer adımların tekrar uygulanmasını gerektirir.

Manuel failover, hızlı bir müdahale gerektiren ve insan hatasına açık bir süreçtir.

Otomatik Failover Araçları

Üretim ortamlarında, otomatik failover ve yönetim için özel araçlar kullanılması şiddetle tavsiye edilir. Bu araçlar, birincil sunucunun durumunu izler, arıza durumunda bekleme sunucusunu otomatik olarak terfi ettirir ve yeni bir topoloji oluşturur. Popüler araçlardan bazıları şunlardır:

* Patroni: Gelişmiş bir HA çözümü olup, dağıtılmış yapılandırma depolama (etcd, Consul, ZooKeeper) kullanarak otomatik failover, anahtarlama (switchover) ve küme yönetimi sağlar.
* pg_auto_failover: Microsoft tarafından geliştirilen ve PostgreSQL’e entegre edilmiş, kullanımı kolay bir otomatik failover çözümüdür.
* repmgr: Replikasyon yönetimi ve failover için güçlü bir araçtır.

Bu araçların kurulumu ve yapılandırması bu makalenin kapsamı dışındadır, ancak yüksek erişilebilir bir sistem kurarken göz önünde bulundurulmaları önemlidir.

Performans ve Optimizasyon İpuçları

Replikasyonun verimli çalışması için bazı optimizasyonlar ve dikkat edilmesi gereken noktalar vardır:

* wal_level: replica seviyesi, replikasyon için gereken tüm bilgileri sağlar. Daha yüksek seviyeler (örn: logical) daha fazla disk alanı ve I/O kullanabilir.
* max_wal_senders: Yeterli sayıda WAL gönderici sürecinin olduğundan emin olun. Bekleme sunucusu sayınızdan fazla olmalı, böylece pg_basebackup gibi diğer işlemler de WAL akışı alabilir.
* wal_keep_segments: Replikasyon slotları kullanılıyorsa bu parametrenin önemi azalır, ancak bir tampon olarak hala değerlidir. Ağ gecikmeleri veya bekleme sunucusu kesintileri sırasında WAL dosyalarının silinmesini önlemeye yardımcı olur.
* Replikasyon Slotları: Kesinlikle kullanın! WAL dosyalarının kaybolmasını ve replikasyonun bozulmasını engellerler.
* Ağ Bant Genişliği: Primary ve standby sunucuları arasındaki ağ bağlantısının yeterli bant genişliğine sahip olduğundan emin olun. Yoğun yazma iş yükleri, yüksek WAL üretimi anlamına gelir ve bu da daha fazla ağ trafiği demektir.
* Disk I/O Performansı: Hem primary hem de standby sunuculardaki disklerin yüksek I/O performansına sahip olması önemlidir. Özellikle standby sunucuda WAL’ların hızlı bir şekilde uygulanması gerekir. SSD’ler veya NVMe sürücüler tercih edilmelidir.
* Senkron Replikasyon: Varsayılan olarak replikasyon asenkrondur (async). Bu, primary sunucunun bir işlemi tamamlamadan önce WAL kayıtlarının standby’a ulaşmasını beklemediği anlamına gelir. Daha yüksek veri güvenliği için senkron replikasyon (synchronous_commit = on ve synchronous_standby_names) yapılandırılabilir, ancak bu primary sunucunun yazma performansını olumsuz etkileyebilir.

Yaygın Sorunlar ve Çözümleri

Replikasyon kurulumu sırasında veya sonrasında karşılaşılabilecek bazı yaygın sorunlar ve çözümleri:

* Bağlantı Sorunları:
* Belirti: pg_basebackup başarısız oluyor veya standby sunucusu primary’ye bağlanamıyor.
* Çözüm:
* pg_hba.conf dosyasını primary sunucuda doğru yapılandırdığınızdan emin olun.
* Güvenlik duvarında (UFW, iptables) 5432 portunun açık olduğundan emin olun.
* listen_addresses ayarını primary sunucuda kontrol edin.
* replicator kullanıcısının parolasının doğru olduğundan emin olun.
* netcat veya telnet gibi araçlarla iki sunucu arasında 5432 portuna erişimin olup olmadığını test edin.
* WAL Dosyası Eksikliği / Replikasyon Bozulması:
* Belirti: Standby sunucusu birincil sunucudan WAL dosyalarını alamıyor, hata mesajları WAL segment has been removed veya WAL file not found.
* Çözüm:
* Replikasyon slotları kullanılıyorsa, slotun aktif olduğundan ve primary’de silinmediğinden emin olun.
* wal_keep_segments değerini primary sunucuda artırın (eğer replikasyon slotu kullanmıyorsanız veya geçici bir sorun varsa).
* Eğer sorun devam ediyorsa, standby sunucusunun veri dizinini temizleyip pg_basebackup ile yeniden bir temel yedekleme almanız gerekebilir.
* İzin Sorunları:
* Belirti: PostgreSQL servisi başlamıyor, loglarda permission denied hataları var.
* Çözüm: Bekleme sunucusundaki veri dizininin (/var/lib/postgresql/12/main) sahibi postgres kullanıcısı ve grubuna ait olduğundan ve 0700 izinlerine sahip olduğundan emin olun.

sudo chown -R postgres:postgres /var/lib/postgresql/12/main
        sudo chmod -R 0700 /var/lib/postgresql/12/main

* Replikasyon Gecikmesi (Replication Lag):
* Belirti: pg_last_wal_receive_lsn() ve pg_last_wal_replay_lsn() arasındaki fark sürekli artıyor veya pg_stat_replication çıktısında write_lag, flush_lag, replay_lag değerleri yüksek.
* Çözüm:
* Ağ bağlantısını kontrol edin, bant genişliği yetersiz olabilir.
* Standby sunucusunun disk I/O performansını kontrol edin, WAL kayıtlarını uygulamakta zorlanıyor olabilir.
* Standby sunucusunun donanım kaynaklarını (CPU, RAM) kontrol edin.
* Primary sunucudaki WAL üretimi çok yoğun olabilir, iş yükünü optimize etmeyi düşünün.
* standby.signal veya primary_conninfo Hatası:
* Belirti: Standby sunucusu başlamıyor veya recovery moduna geçmiyor.
* Çözüm: /var/lib/postgresql/12/main/ dizininde standby.signal dosyasının var olduğundan ve postgresql.conf içindeki primary_conninfo satırının doğru ve eksiksiz olduğundan emin olun. Özellikle password kısmını doğru yazdığınızdan emin olun.

Sonuç

PostgreSQL 12 ile Ubuntu 20.04 üzerinde fiziksel akış replikasyonu kurmak, veritabanı altyapınız için yüksek erişilebilirlik ve veri güvenliği sağlamanın temel adımlarından biridir. Bu makalede, iki sunucu arasında WAL tabanlı replikasyonu adım adım nasıl kuracağınızı, gerekli yapılandırma dosyalarını nasıl düzenleyeceğinizi, replikasyon kullanıcısını nasıl oluşturacağınızı ve pg_basebackup ile başlangıç yedeklemesini nasıl alacağınızı ayrıntılı olarak ele aldık.

Replikasyonun başarılı bir şekilde kurulması, sisteminizin felaketlere karşı direncini artırır ve hizmet kesintisi riskini azaltır. Ayrıca, bekleme sunucularını okuma amaçlı sorgular için kullanarak birincil sunucunun yükünü hafifletebilir ve genel performansı artırabilirsiniz.

Unutmayın ki manuel failover, insan müdahalesi gerektiren ve potansiyel riskler taşıyan bir yöntemdir. Üretim ortamlarında, Patroni, pg_auto_failover veya repmgr gibi otomatik failover araçlarını kullanarak daha sağlam ve hataya dayanıklı bir çözüm oluşturmanız şiddetle tavsiye edilir. Replikasyonun sürekli izlenmesi ve performans optimizasyonları, sisteminizin sorunsuz çalışmasını sağlamak için kritik öneme sahiptir. Bu kurulum rehberi, PostgreSQL replikasyon dünyasına ilk adımınızı atmanız için sağlam bir temel sunmaktadır.