MongoDB Oplog Penceresi Kısa: Secondary Resync Riskini Önleme
Oplog süresini en gerideki secondary'nin gecikmesiyle karşılaştırır, ani yazma yükünü ve disk sınırını kontrol eder, oplog kapasitesini güvenle büyütme adımlarını verir.
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.
1. Belirti / Symptom
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. Etki / 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. Teşhis / Diagnosis
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. Müdahale / Response
// Ö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. Doğrulama / Verification
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. Geri Alma / Rollback
Ö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.