Veri Taşıma Yöntemine Göre: Fiziksel Replikasyon (Streaming Replication)
- Gökhan Dedeoğlu
- 2 saat önce
- 4 dakikada okunur
PostgreSQL mimarisinde yüksek kullanılabilirlik (High Availability), veri güvenliği ve yük dengeleme (Read Scaling) çözümlerinin temelini Fiziksel Replikasyon (Physical Replication) oluşturur. Yaygın olarak Streaming Replication (Akış Replikasyonu) olarak adlandırılan bu yöntem, veri tabanındaki değişiklikleri bayt seviyesinde (low-level byte-by-byte) yedek sunuculara aktarır.
Bu teknik makalede; PostgreSQL'de Streaming Replication mekanizmasının arka planındaki mimariyi, WAL süreçlerini, bağlantı protokollerini, kurulum adımlarını ve yönetimsel en iyi pratikleri (best practices) detaylandıracağız.
1. Fiziksel Replikasyonun Temel Mimarisi
Fiziksel replikasyon, adından da anlaşılacağı üzere mantıksal (logical) SQL komutlarını değil, disk üzerindeki fiziksel veri bloklarının (pages) birebir kopyasını temel alır. Bu işlem tamamen Write-Ahead Logging (WAL) kayıtlarının aktarılması ve hedef sunucuda yeniden oynatılması (replay) mantığına dayanır.
Mimaride iki ana rol bulunur:
Primary (Master): Okuma ve yazma (Read/Write) işlemlerini kabul eden aktif veri tabanı sunucusu.
Standby (Replica): Sadece okuma (Read-Only) işlemlerini kabul edebilen (Hot Standby modunda ise) ve Primary'den gelen fiziksel değişiklikleri uygulayan yedek sunucu.
2. Arka Plan Süreçleri ve WAL Akışı (Deep Dive)
Streaming Replication, işletim sistemi seviyesinde ve PostgreSQL süreç hiyerarşisinde belirli aktörler tarafından yönetilir. Bu akışın arkasındaki teknik süreç şu şekildedir:
A. Primary Sunucu Tarafındaki Süreçler
WAL Writer: Paylaşılan bellek alanındaki (Shared Buffers) kirli sayfaların (dirty pages) WAL kayıtlarını diske (pg_wal dizinine) yazar.
WalSender: Standby sunucudan gelen her bağlantı talebi için Primary üzerinde bir walsender süreci (process) çatallanır (fork). Bu süreç, diske yeni yazılan veya bellekten doğrudan okunan WAL kayıtlarını ağ soketi üzerinden Standby'a akıtır.
B. Standby Sunucu Tarafındaki Süreçler
WalReceiver: Standby sunucu üzerinde çalışan tek bir süreçtir. Primary sunucudaki walsender ile TCP/IP protokolü üzerinden sürekli açık bir bağlantı kurar, gelen WAL akışını teslim alır ve yerel diskteki pg_wal dizinine yazar.
Startup Process (Recovery/Replay): Standby veri tabanı motoru başlatıldığında devreye giren bu süreç, wal_receiver tarafından diske yazılan WAL kayıtlarını okur ve veri bloklarına uygular (redo/apply). Bu süreç aktif olduğu sürece Standby sunucu "Continuous Recovery" (Kesintisiz Kurtarma) modundadır.
3. Akış Protokolü ve El Sıkışma (Handshake)
Streaming Replication, PostgreSQL'in standart istemci bağlantı protokolünü kullanır ancak özel bir Replication Mode ile bağlanır.
Standby, Primary'ye standart bir PostgreSQL TCP bağlantısı açar ancak bağlantı dizesinde replication=database veya replication=true parametrelerini iletir.
Primary, gelen bağlantıyı karşılamak için pg_hba.conf dosyasındaki replikasyon izinlerini (replication yetkisine sahip kullanıcıyı) doğrular.
Bağlantı kurulduğunda Standby, Primary'ye en son uyguladığı WAL konumunu LSN (Log Sequence Number) cinsinden bildirir (Örn: LSN: 0/30000D0).
Primary, bu LSN noktasından itibaren üretilmiş olan tüm WAL kayıtlarını sırasıyla akıtmaya (stream) başlar.
4. Adım Adım Fiziksel Streaming Replication Kurulumu
Aşağıda, PostgreSQL 12 ve sonraki sürümler için geçerli olan (klasik recovery.conf dosyasının yerine standby.signal dosyasının geldiği) standart bir fiziksel replikasyon kurulumu yer almaktadır.
Adım 1: Primary Sunucu Yapılandırması (postgresql.conf)
Primary sunucuda replikasyon parametreleri optimize edilir:
Ini, TOML
# postgresql.conf
listen_addresses = '*'
wal_level = replica # Fiziksel replikasyon için minimum seviye
max_wal_senders = 10 # İzin verilen maksimum replika bağlantısı
max_replication_slots = 10 # Kullanılacak replikasyon slot adeti
hot_standby = on # Yedeklerin okunabilir olmasını sağlarpg_hba.conf dosyasına replica kullanıcısının erişimi için kural eklenir:
Plaintext
# pg_hba.conf
# TYPE DATABASE USER ADDRESS METHOD
host replication replicator 192.168.1.100/32 scram-sha-256(192.168.1.100: Standby sunucunun IP adresidir.)
Adım 2: Standby Sunucusunda Temel Yedek Alımı (pg_basebackup)
Standby sunucusundaki veri dizini tamamen boşaltılır ve Primary sunucudan fiziksel bir kopya çekilir:
Bash
# Standby sunucusunda terminalde çalıştırın:
pg_basebackup -h 192.168.1.50 -U replicator -D /var/lib/postgresql/data -Fp -Xs -P -R-h: Primary IP adresi.
-D: Hedef veri dizini.
-Fp: Plain format (birebir dosya kopyası).
-Xs: WAL dosyalarını akış esnasında yedek içine dahil et.
-R: Replikasyon için gerekli bağlantı ayarlarını (primary_conninfo) otomatik olarak oluştur ve standby.signal dosyasını dizine ekle.
Adım 3: Standby Sunucusunu Başlatma
pg_basebackup işleminden sonra Standby veri dizininde otomatik olarak standby.signal adında boş bir dosya oluşacaktır. Bu dosya, PostgreSQL'e bu sunucunun bir yedek sunucu (Read-Only) olduğunu söyler.
Standby servisi başlatılır:
Bash
systemctl start postgresql5. Kritik Parametreler ve Replikasyon Slotları (Replication Slots)
Fiziksel replikasyonda karşılaşılan en büyük sorunlardan biri, Standby sunucunun geçici olarak kapanması durumunda Primary sunucunun eski WAL dosyalarını silmesidir.
Standby tekrar açıldığında ihtiyaç duyduğu WAL dosyalarını bulamazsa replikasyon kırılır (replication lag gap).
Bunu önlemek için iki yöntem kullanılır:
A. Replication Slots (Önerilen)
Replikasyon slotları, Primary üzerinde tanımlanan sanal işaretçilerdir. Primary sunucu, ilgili replikasyon slotuna bağlı olan Standby sunucunun en son hangi LSN'i okuduğunu bilir ve Standby o WAL kaydını alıp işlediğini onaylayana kadar o WAL dosyasını diskten asla silmez.
Slot Tanımlama:
Primary üzerinde slot oluşturulur:
SQL
SELECT pg_create_physical_replication_slot('standby_slot_1');Standby'daki postgresql.conf (veya primary_conninfo parametresi) bu slotu kullanacak şekilde güncellenir:
Ini, TOML
primary_conninfo = 'host=192.168.1.50 port=5432 user=replicator password=sifre primary_slot_name=standby_slot_1'Önemli Uyarı: Replikasyon slotu kullanıldığında Standby uzun süre kapalı kalırsa, Primary WAL dosyalarını silemeyeceği için Primary disk alanı tamamen dolabilir ve Primary servis dışı kalabilir. Bu durum max_slot_wal_keep_size parametresi ile sınırlandırılmalıdır.
6. Fiziksel Replikasyon İzleme ve Sağlık Kontrolleri (Monitoring)
Replikasyonun sağlıklı çalıştığını ve aradaki gecikmeyi (lag) ölçmek için aşağıdaki sistem görünümleri (system views) kullanılır.
Primary Sunucu Üzerinde Sorgulama:
pg_stat_replication görünümü, bağlı olan replikaların durumunu ve gecikme miktarını bayt cinsinden gösterir:
SQL
SELECT
application_name,
client_addr,
state,
sync_state,
pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS sent_lag_bytes,
pg_wal_lsn_diff(sent_lsn, write_lsn) AS write_lag_bytes,
pg_wal_lsn_diff(write_lsn, flush_lsn) AS flush_lag_bytes,
pg_wal_lsn_diff(flush_lsn, replay_lsn) AS replay_lag_bytes
FROM pg_stat_replication;Standby Sunucu Üzerinde Sorgulama:
Standby sunucunun aktif olarak recovery modunda olup olmadığını ve son uygulanan WAL zamanını doğrulamak için:
SQL
-- Sunucunun standby modunda olup olmadığını döner (True olmalıdır)
SELECT pg_is_in_recovery();
-- Son alınan ve son uygulanan WAL zaman damgaları arasındaki farkı ölçer
SELECT
pg_last_wal_receive_lsn() AS last_received_lsn,
pg_last_wal_replay_lsn() AS last_replayed_lsn,
pg_last_xact_replay_timestamp() AS last_replay_time;Sonuç
PostgreSQL Fiziksel Streaming Replication, veri güvenliğini fiziksel düzeyde garanti altına alan son derece performanslı ve kararlı bir mimaridir. Mantıksal replikasyona kıyasla çok daha düşük CPU maliyetine sahiptir ve DDL (şema değişiklikleri) işlemlerini de tamamen replike eder.
Doğru yapılandırılmış replikasyon slotları ve düzenli izleme (monitoring) mekanizmalarıyla, veri tabanı altyapınızın yüksek kullanılabilirliğini (High Availability) ve olası felaket anlarında en az kayıpla (Low RTO / RPO) kurtarılmasını sağlayabilirsiniz.
Yorumlar