MongoDB Short Oplog Window: Prevent Secondary Resync
Compares oplog coverage with the slowest secondary, inspects write bursts and disk limits, and explains safe oplog resizing to avoid resync.
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.
1. Symptom & Signals
M51 belirlenen minimuma iner; replika gecikmesi oplog penceresinin büyük bölümüne ulaşır. Secondary loglarında oplog'dan yakalama başarısızlığı veya `RECOVERING` görülebilir.
2. Business & Technical Impact
Geri kalan oplog girdileri silinirse secondary mevcut geçmişle yetişemez, initial sync veya güncel snapshot'tan kurtarma gerekir. Quorum/donanım hata toleransı düşer.
3. Diagnosis & Root-Cause Analysis
rs.printReplicationInfo();
rs.printSecondaryReplicationInfo();
rs.status().members.map(m => ({ name: m.name, state: m.stateStr, optimeDate: m.optimeDate }));const o = db.getSiblingDB('local').oplog.rs.stats();
({ capped: o.capped, maxSizeMB: +(o.maxSize / 1048576).toFixed(0), usedMB: +(o.size / 1048576).toFixed(0) });4. Remediation & Action Plan
// Örnek: 32 GiB, boyut MB cinsinden; hedefi kapasite hesabıyla belirleyin.
db.getSiblingDB('admin').runCommand({ replSetResizeOplog: 1, size: Double(32768) });`replSetResizeOplog` MongoDB 4.0+ için geçerlidir; `minRetentionHours` seçeneği 4.4+ sürümlerde vardır. Bu seçenek disk kullanımı garantisi değildir, büyüme planını ayrıca yapın. Yönetilen bulut servislerinde komut desteklenmeyebilir.
5. Verification & Health Checks
Yeni maksimum oplog boyutu her üyede görünüyor; M51 hedefin üzerinde, replika gecikmesi pencerenin güvenli bir bölümünde ve azalıyor; disk rezervi yeterli.
6. Rollback & Contingency Plan
Önceki MB değerini kaydedip aynı komutla geri dönülebilir, fakat küçültme geçmiş girdileri atıp geri kalan secondary'yi senkron dışı bırakabilir. Pencere toparlanmadan küçültmeyin.