dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
PostgreSQL / Backup & Recovery / Runbooks
Teknik Uygulama Rehbericritical15 dk
postgresql (14–18)
mysql (14–18)
sqlserver (14–18)
oracle (14–18)

Replikasyon Gecikmesi (Replication Lag) & Desenkronizasyon Runbook'u

Replica sunucuların master arkasında kalması durumunda WAL/Binlog birikmesi, ağ doygunluğu ve kilit analiz adımları.

Gerekli Ön Koşullar & Güvenlik İlkeleri:
Master ve Replica sunuculara DBA erişimiAğ gecikmesi (ping/iperf) ölçüm yetkisi
1

Gecikme Miktarını ve Durumu Tespit Etme

Gecikmenin ağ transferinde mi (network transfer) yoksa replica disk/CPU I/O yetersizliğinde mi (replay lag) olduğunu belirleyin.

-- PostgreSQL:
SELECT client_addr, state, sync_state, pg_wal_lsn_diff(pg_current_wal_lsn(), write_lsn) AS write_lag_bytes, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes FROM pg_stat_replication;

-- MySQL:
SHOW REPLICA STATUS\G
2

Replica Üzerinde Engelleyici Uzun Sorguları Kontrol Etme

Replica üzerinde çalışan uzun analitik sorgular, master'dan gelen WAL satırlarının uygulanmasını (recovery conflict) durduruyor olabilir.

SELECT pid, now() - query_start AS duration, query FROM pg_stat_activity WHERE state != 'idle' AND (now() - query_start) > interval '2 minutes';
3

Master Disk Dolmasını Önleme (Slot Kontrolü)

Eğer bir replica yanıt vermiyorsa replication slot master diskinde WAL biriktirerek master'ı çökertebilir. Gerekirse geçersiz slotu düşürün.

SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal FROM pg_stat_replication_slots;
Topluluk Katkısı & Benchmark

Restore Tatbikatı Deneyiminizi veya Sonuçlarınızı Paylaşın

Altyapınızdaki gerçek RTO/RPO sürelerini, PostgreSQL sürümünüzü, tercih ettiğiniz yaklaşımı ve karşılaştığınız engelleri anonim veya isimli olarak paylaşın. Sektör benchmark'ına katkıda bulunun.

İlgili Karar Matrisleri ve Ekip Kılavuzları