Runbook #5

postgresql

ReplicationSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minssuperuser / postgres / rds_superuser

PostgreSQL Replikasyon Gecikmesi Müdahalesi

WAL üretimi, aktarımı, yazılması ve replay aşamalarını ayrı ayrı ölçerek gecikmenin ağ, disk veya sorgu kaynaklı nedenini bulur.

İlişkili Metrik:M3

İlişkili Script:S6 S13

#streaming-replication#wal#replay-lag#rpo

Operasyonel Güvenlik ve Risk Uyarısı

Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- M3 (replay gecikmesi) yükselir; standby eski veri döner veya RPO hedefi aşıldı uyarısı gelir.

- `pg_stat_replication` satırı kaybolur ya da `state` streaming değildir.

2. Etki / Impact

Standby okuması bayatlar; asenkron failover veri kaybına, senkron yapılandırmada standby erişimsizliği commit beklemesine yol açabilir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. Primary üzerinde WAL'ın nerede takıldığını S6 ile görün (PG 10+):

sql

SELECT application_name, client_addr, state, sync_state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS unsent_bytes,
       pg_wal_lsn_diff(sent_lsn, write_lsn) AS transport_bytes,
       pg_wal_lsn_diff(write_lsn, flush_lsn) AS flush_bytes,
       pg_wal_lsn_diff(flush_lsn, replay_lsn) AS replay_bytes,
       write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

🟢 Salt Okunur2. Standby üzerinde yeniden oynatma durumu ve zamanı:

sql

SELECT pg_is_in_recovery() AS is_standby,
       pg_last_wal_receive_lsn() AS received_lsn,
       pg_last_wal_replay_lsn() AS replayed_lsn,
       pg_is_wal_replay_paused() AS replay_paused,
       now() - pg_last_xact_replay_timestamp() AS time_since_last_commit;

🟢 Salt Okunur3. **Boşta primary uyarısı:** `now() - pg_last_xact_replay_timestamp()` son commit'ten beri geçen süreyi ölçer; trafik yoksa gecikme olmadan da büyür. Primary/standby LSN farkı ve gerçek RPO'yu birlikte değerlendirin. `write_lag` vb. değerler her zaman güncel backlog değildir.

🟢 Salt Okunur4. S13 ile slotların biriktirdiği WAL'ı inceleyin; standby'da `pg_stat_activity` ve sunucu loglarından uzun sorgu, `recovery_min_apply_delay`, disk I/O ve ağ sorunlarını doğrulayın. `hot_standby_feedback` ayarı ve standby sorgu çakışmalarını değerlendirin.

4. Müdahale / Response

🟡 Geri Alınabilir1. Replay duraklatılmışsa operasyon sahibinden onay alıp devam ettirin:

sql

SELECT pg_wal_replay_resume(); -- yalnızca standby; kullanıcı kontrollü pause'u sona erdirir

🟡 Geri Alınabilir2. Ağ/standby hizmeti durduysa bağlantıyı, `primary_conninfo`, logları ve WAL receiver'ı denetleyip bağlantıyı geri kurun. Standby'daki ağır raporları hafifletin; canlı işi kesmeden önce sahibiyle görüşün.

🟡 Geri Alınabilir3. Primary'ye gelen toplu yazmaları kontrollü yavaşlatın. Standby disk IOPS yetersizse altyapı kapasitesini artırın; mümkünse ağır okuma yükünü başka üyeye kaydırın.

🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. Standby gerekli WAL segmentlerini kaybetmişse `pg_rewind` veya yeni base backup ile yeniden kurulum gerekebilir. Körlemesine `pg_resetwal` çalıştırmayın; kurtarma zincirini ve veri tutarlılığını tehlikeye atar. Failover'dan önce RPO'yu iş sahibiyle teyit edin.

5. Doğrulama / Verification

- `pg_stat_replication.state = 'streaming'`; byte backlog azalıyor, standby receive/replay LSN'leri primary'yi yakalıyor.

- M3 ve uygulama okuma gecikmesi RPO hedefi altında 15 dakika sabit.

6. Geri Alma / Rollback

- `pg_wal_replay_resume()` geri alma için yeniden `pg_wal_replay_pause()` çağrılabilir, ancak pause RPO riskini yeniden artırır.

- Yük kısma ayarlarını önceki değerlere çevirin; standby yeniden kurulumuna başlamadan önce geçerli yedeği ve geri dönüş planını doğrulayın.

Operasyonel Güvenlik ve Risk Uyarısı

1. Belirti / Symptom

2. Etki / Impact

3. Teşhis / Diagnosis

4. Müdahale / Response

5. Doğrulama / Verification

6. Geri Alma / Rollback

Diğer POSTGRESQL Runbook'ları

PostgreSQL 'too many connections' Hatası: Teşhis ve Acil Müdahale

PostgreSQL Transaction ID Wraparound Acil Durumu: Dondurma (Freeze) Planı

PostgreSQL Kilit Zinciri ve Bloklama: Kök Bloklayıcıyı Bulma ve Çözme

PostgreSQL Yavaşlama ve Yüksek Disk Okuma Triyajı