Replikasyon gecikmesi / durdu

Standby/replika primary'nin gerisinde kalıyor ya da replikasyon tamamen durdu. Bu ağaç, gecikmenin türünü (artıyor mu, sabit mi, durdu mu) adım adım daraltarak apply hatası, tek-thread darboğazı, recovery çakışması veya bozulma gibi kök nedene götürür.

Gecikme nasıl davranıyor?

Önce durumu ölç. Replika akışını ve gecikme metriğini gör: lag zamanla artıyor mu, sabit bir seviyede mi takılı, yoksa uygulama (apply) tamamen durmuş mu? Bu, aramayı üç ana kola ayırır.

SELECT client_addr, state, write_lag, flush_lag, replay_lag,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS bytes_behind
FROM pg_stat_replication;

• Apply tamamen durdu / hata var
• Lag sürekli artıyor (yetişemiyor)
• Lag sabit ama uzun sorgu şüphesi var
• Çok geride / tutarsız görünüyor

Apply hatası ne diyor?

Replikasyon durduysa genelde uygulanan bir olayda hata vardır. Hata mesajına bak: hedefte olmayan bir satır/tablo mu, primary key çakışması mı, yoksa bağlantı/ağ kopması mı?

SHOW REPLICA STATUS\G  -- Last_Error, Last_SQL_Error, Replica_IO_Running, Replica_SQL_Running

• Çakışan/eksik satır ya da tablo hatası
• Ağ/bağlantı koptu, IO thread durdu

Neden yetişemiyor?

Lag sürekli büyüyorsa replika, primary'nin yazma hızına yetişemiyor demektir. Tek-thread apply mı darboğaz, yoksa replikanın diski/IO'su mu yavaş? Apply worker durumuna ve IO beklemesine bak.

SHOW REPLICA STATUS\G  -- Seconds_Behind_Source ve apply thread durumu
SELECT * FROM performance_schema.replication_applier_status_by_worker;

• Tek-thread apply + ağır yazma yükü
• Replikanın diski/IO'su yavaş

Standby'da uzun bir sorgu mu var?

Salt-okunur standby üzerinde çalışan uzun bir sorgu, apply'ı (recovery) bloklayabilir. PostgreSQL'de recovery conflict bu şekilde ortaya çıkar. Standby'daki aktif sorgulara ve çakışma sayaçlarına bak.

SELECT now()-query_start AS dur, pid, state, query
FROM pg_stat_activity WHERE state='active' ORDER BY query_start;
SELECT confl_snapshot, confl_lock, confl_bufferpin FROM pg_stat_database_conflicts WHERE datname=current_database();

• Evet, uzun sorgu apply'ı blokluyor
• Hayır, sorgu yok — yine de geride

Kök neden: Apply hatası (veri çakışması)

Replika, uygulayamadığı bir olayda takıldı: hedefte olmayan satır, primary key çakışması veya eksik tablo. Kör atlama yerine tutarsızlığın nedenini gider.

Kök neden: Bağlantı / ağ kopması

Alıcı (IO/receiver) thread primary'ye bağlanamıyor. Ağ, kimlik doğrulama veya biriken/temizlenen log segmentleri sorunlu olabilir.

Kök neden: Tek-thread apply darboğazı

Primary paralel yazarken replika değişiklikleri tek sırada uyguluyor ve yetişemiyor. Uygulamayı paralelleştir.

Kök neden: Replika IO darboğazı

Apply thread'i CPU değil diski bekliyor. Replikanın depolaması primary'nin yazma hızını karşılayamıyor.

Kök neden: Standby recovery çakışması

Standby'daki uzun salt-okunur sorgu, primary'den gelen değişikliğin uygulanmasını blokluyor (vacuum/lock çakışması). PostgreSQL bunu gecikme veya sorgu iptaliyle çözer.

Kök neden: Replika çok geride / bozuk — yeniden kur

Replika kurtarılamayacak kadar geride, gerekli log'lar silinmiş veya veri tutarsız. En güvenli yol taze yedekten yeniden kurmak.