Runbook #47

mongodb

ReplicationSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minsclusterAdmin / dbAdminAnyDatabase / root

MongoDB Replica Set Replikasyon Gecikmesi: Teşhis ve Çözüm

Secondary'nin primary'nin gerisinde kalma nedenini (yazma yükü, disk, ağ, flow control) bulur, oplog penceresini kontrol eder ve resync riskini önler.

İlişkili Metrik:M50M51

İlişkili Script:S84 S93 S81

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

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

- 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. Etki / 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. Teşhis / Diagnosis

🟢 Salt Okunur1. Ü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();

🟢 Salt Okunur2. **Oplog penceresi** (S93): Gecikme pencerenin yarısını geçtiyse acildir.

javascript

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

🟢 Salt Okunur3. **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)?

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

javascript

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

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

4. Müdahale / Response

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

javascript

db.killOp(<opid>);

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

🟡 Geri Alınabilir3. 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.

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

javascript

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

🔴 YÜKSEK RİSK / GERİ ALINAMAZ5. 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. Doğrulama / Verification

- 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. Geri Alma / Rollback

- `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.

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 MONGODB Runbook'ları

MongoDB WiredTiger Cache Baskısı: Çalışma Seti RAM'e Sığmıyor

MongoDB Bağlantı Tükenmesi: Hangi İstemci Bağlantıları Dolduruyor?

MongoDB Oplog Penceresi Kısa: Secondary Resync Riskini Önleme

MongoDB Kilit Kuyruğu Büyüyor: Bekleyen Operasyonları Teşhis Etme