Runbook #47

mongodb

ReplicationSEV2 · DEGRADATION15-30 dakika / 15-30 minsclusterAdmin / dbAdminAnyDatabase / root

MongoDB Replica Set Replication Lag: Diagnosis and Fix

Finds why a secondary lags behind the primary (write load, disk, network, flow control), checks the oplog window and prevents a resync.

Related Metrics:M50M51

Related Scripts:S84 S93 S81

#replica-set#lag#oplog#flow-control

Operational Safety & Risk Notice

This runbook contains operational intervention steps; several are write-impacting (KILL, terminate, DROP, RESIZE). Verify in a staging environment first, and apply sequentially in production with verification.

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

1. Symptom & Signals

- Secondary'nin `optimeDate` değeri primary'nin gerisinde; M50 > 10-60 sn.

- Secondary'den okuyan uygulamalar eski veri görüyor.

- `w:majority` yazmaları yavaş veya zaman aşımına uğruyor.

2. Business & Technical Impact

Okuma tutarsızlığı, majority write gecikmesi, failover'da veri kaybı riski (rollback). Gecikme oplog penceresini aşarsa secondary **"too stale to catch up"** olur ve tam **initial sync** gerekir.

3. Diagnosis & Root-Cause Analysis

🟢 Read-Only1. Üye durumları ve gecikme (S84):

javascript

rs.status().members.map(m => ({ name: m.name, state: m.stateStr, lag_s: m.optimeDate ? (rs.status().date - m.optimeDate)/1000 : null, ping: m.pingMs }));
rs.printSecondaryReplicationInfo();

🟢 Read-Only2. **Oplog penceresi** (S93): Gecikme pencerenin yarısını geçtiyse acildir.

javascript

rs.printReplicationInfo();   // "log length start to end" saat cinsinden

🟢 Read-Only3. **Neden?** Secondary üzerinde (S81 ile işlemlere bakın):

- Disk I/O doygun mu? (`iostat -x 1`, yüksek `await`/`%util`).

- CPU veya ağ darboğazı var mı? Primary ile secondary arası bant genişliği/gecikme.

- Secondary'de **ağır okuma/raporlama sorguları** veya index build çalışıyor mu?

- Primary'de ani yazma patlaması mı (toplu import/update)?

🟢 Read-Only4. **Flow control** (4.2+): Primary, majority commit noktasını geride tutmamak için yazmaları yavaşlatıyor olabilir:

javascript

db.serverStatus().flowControl;   // isLagged, targetRateLimit

🟢 Read-Only5. Secondary'nin ve primary'nin log'larında (`/var/log/mongodb/mongod.log`) yavaş uygulama (`applied oplog`), bağlantı hataları arayın.

4. Remediation & Action Plan

🟡 Reversible1. Secondary'deki **ağır sorguları durdurun** veya okumaları başka bir secondary'ye yönlendirin. Uzun işlem sonlandırma:

javascript

db.killOp(<opid>);

🟡 Reversible2. Toplu yazma kaynaklıysa: iş yükünü yavaşlatın (batch boyutu/hızı), `w:majority` ile kontrollü yazın.

🟡 Reversible3. Secondary donanımını/diskini iyileştirin (daha hızlı disk, IOPS). Secondary'nin primary'den **zayıf** olması çok yaygın bir kök nedendir.

🟡 Reversible4. **Oplog'u büyütün** (pencere kısaysa, yeniden başlatmadan, üyede tek tek):

javascript

db.adminCommand({ replSetResizeOplog: 1, size: 32768 });   // MB

🔴 HIGH RISK / IRREVERSIBLE5. Secondary "too stale" duruma düştüyse: **Initial sync** gerekir. Veri dizinini silip yeniden senkronize edin (büyük veride uzun sürer, primary'ye yük bindirir) veya güncel bir snapshot'tan geri yükleyin. Bu sürede üyeyi küme kararlılığı için dikkatle planlayın (üç üyeli sette bir üye eksikken tek hata toleransı kalır).

6. **Kalıcı çözüm:** Oplog penceresini yoğun toplu işlemi kapsayacak şekilde boyutlandırın (en az 24-72 saat), secondary donanımını primary ile eşitleyin, raporlama için ayrı (hidden/analytics) bir üye kullanın.

5. Verification & Health Checks

- Tüm secondary'ler `SECONDARY` durumunda ve lag birkaç saniyenin altında (M50 normal).

- Oplog penceresi hedefin (>24 saat) üzerinde (M51).

- `w:majority` yazma gecikmesi normale döndü.

6. Rollback & Contingency Plan

- `killOp` geri alınamaz; işlem uygulama tarafında yeniden denenmelidir.

- `replSetResizeOplog` ile oplog küçültülebilir ancak pencereyi daraltır; yalnızca gerekirse yapın.

- Initial sync geri alınamaz; başlamadan önce yedek/snapshot doğrulayın.

Operational Safety & Risk Notice

1. Symptom & Signals

2. Business & Technical Impact

3. Diagnosis & Root-Cause Analysis

4. Remediation & Action Plan

5. Verification & Health Checks

6. Rollback & Contingency Plan

More MONGODB Runbooks

MongoDB WiredTiger Cache Pressure: Working Set Does Not Fit in RAM

MongoDB Connection Exhaustion: Find the Client Filling the Pool

MongoDB Short Oplog Window: Prevent Secondary Resync

MongoDB Lock Queue Growth: Diagnose Waiting Operations