Streaming replication lag'i ölçmenin doğru yolu

Read replica'ya yönlendirdiğin sorgular eski veri dönüyorsa, ilk ölçmen gereken şey replication lag'dir. Ama "kaç byte geride" sorusu çoğu zaman yanlış sorudur; asıl önemli olan "kaç saniye geride" ve bunu nereden okuduğundur.

Primary'den bakmak: byte cinsinden

Primary üzerinde her replica'nın durumu pg_stat_replication'da görünür:

SELECT
  application_name,
  state,
  pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn)   AS gonderilmeyen,
  pg_wal_lsn_diff(sent_lsn, replay_lsn)             AS uygulanmayan,
  pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS toplam_byte
FROM pg_stat_replication;

Bu üç sütun lag'i aşamalara ayırır: primary'nin ürettiği ama henüz gönderilmemiş WAL, replica'ya ulaşmış ama henüz uygulanmamış WAL, ve ikisinin toplamı. Sorun ağda mı yoksa replica'nın uygulama hızında mı — bu ayrım söyler.

Replica'dan bakmak: saniye cinsinden

Asıl anlamlı ölçüm replica üzerindedir ve zaman cinsindendir:

SELECT
  CASE
    WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn()
    THEN 0
    ELSE EXTRACT(EPOCH FROM now() - pg_last_xact_replay_timestamp())
  END AS lag_saniye;

Buradaki CASE kritik ve en sık atlanan detaydır. pg_last_xact_replay_timestamp() son uygulanan işlemin zamanını verir. Eğer primary'de bir süredir hiç yazma olmadıysa bu değer eskir ve replica tamamen güncel olmasına rağmen sana "lag var" der. Receive ve replay LSN'leri eşitse lag sıfırdır — CASE bunu yakalar.

Üç yaygın hata

1. Sadece byte izlemek. Grafana'da pg_wal_lsn_diff byte grafiği güzel görünür ama operasyonel kararı saniye verir. İkisini birlikte göster.

2. pg_last_xact_replay_timestamp()'i çıplak kullanmak. Yukarıdaki CASE olmadan, sessiz sistemde sürekli yalancı lag üretir.

3. Senkron replikasyonu lag ile karıştırmak. synchronous_commit = on ve senkron replica varsa, primary'deki commit replica onaylayana kadar bekler. Burada "lag" primary'nin yazma latency'sine döner; pg_stat_replication'ın sync_state sütununu kontrol et:

SELECT application_name, sync_state, replay_lag
FROM pg_stat_replication;

replay_lag sütunu (PG 10+) doğrudan interval döndürür — hesaplamayla uğraşmadan hızlı bir okuma için idealdir, ama kaynağı primary olduğu için sessiz sistemde yine dikkatli yorumla.

Alarm nasıl kurulur

Pratik eşik: saniye cinsinden lag + yön. 30 saniyeyi geçen ve artmaya devam eden lag uyarı; 5 dakikayı geçen kritik. Sabit 10 saniyelik lag yüksek yazma yükünde normal olabilir; artan trend ise sorunun habercisidir. Alarmı mutlak değere değil, eğime de bak.

Özet

Byte primary'de, saniye replica'da ölçülür. Replica'da pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn() kontrolünü atlamak en sık hatadır. Lag'i hem değer hem trend olarak izle; senkron replikasyon varsa sync_state'i ayrı düşün.