MongoDB günlük işletim ve arıza senaryoları (replica set ve sharded cluster)

Kurulum değil: kurulu bir MongoDB replica set'ini ve sharded cluster'ını günlük olarak yönetmek ve bozulduğunda kurtarmak için senaryo bazlı runbook. Sağlık kontrolü, üye ekleme/çıkarma, priority/hidden/delayed üye, arbiter'ı veri üyesiyle değiştirme, geride kalan üyeyi yeniden eşitleme, çoğunluk kaybında force reconfig, planlı stepDown, oplog boyutu, FCV; shard ekleme/çıkarma, balancer, jumbo chunk ve reshardCollection. Ne yapacağınızı bilmiyorsanız sağlık kontrolüyle başlayın; yedekten geri dönüş, güvenlik ayarları ve ana sürüm yükseltme ayrı MongoDB rehberlerindedir.

Yapı: Replica set (3+ üye) ya da sharded cluster (config server + shard replica set'leri + mongos)

Senaryolar

• Sağlık kontrolü: üyeler, gecikme, oplog penceresi (sharded'da shard'lar ve balancer) — Salt-okur: üye durumları, replikasyon gecikmesi, oplog penceresi, yapılandırma; sharded cluster'da shard listesi, balancer ve chunk dağılımı. Ne yapacağınızdan emin değilseniz buradan başlayın.
• Replica set'e yeni üye ekle (initial sync) — Yeni sunucu kuruldu (aynı sürüm, keyfile, replSetName); priority 0 / votes 0 ile eklenir, initial sync bitip SECONDARY olunca oy ve priority verilir. Kesinti yok.
• Üyeyi replica set'ten çıkar — Sunucu emekliye ayrılıyor ya da kalıcı olarak kayıp: üye yapılandırmadan çıkarılır, kalan oy sayısının çoğunluğu koruduğu doğrulanır. Primary ise önce stepDown.
• Üye rolünü değiştir: priority, hidden, delayed (gecikmeli) üye — Bir üyenin primary olma önceliğini değiştirmek, raporlama/yedek için gizli (hidden) ya da yanlış silmelere karşı gecikmeli (delayed) üye yapmak veya normale döndürmek.
• Arbiter'ı veri taşıyan üyeyle değiştir (PSA → PSS) — Replica set primary + secondary + arbiter: bir veri üyesi düşünce majority yazmalar ve cache baskısı sorun olur. Yeni veri üyesi eklenir, arbiter çıkarılır.
• Geride kalmış ya da bozuk üyeyi yeniden eşitle (resync) — Üye RECOVERING'de takılı ve 'too stale to catch up' diyor, ya da veri dosyaları bozuk: üyenin veri dizini boşaltılır, initial sync ile sıfırdan eşitlenir. Diğer üyeler çalışmaya devam eder.
• Çoğunluk kaybı: kalan üyelerle zorla yeniden yapılandır (force reconfig) — Üyelerin çoğu kalıcı olarak kayıp (site/sunucu kaybı), kalanlar primary seçemiyor: kalan üyelerle rs.reconfig(cfg, {force: true}). Son çare; yanlış kullanımda veri kaybı ve split brain riski.
• Planlı primary değişimi (rs.stepDown, belirli üyeyi primary yapma) — Primary sunucuda bakım/patch yapılacak: primary geri çekilir, yetişmiş bir secondary primary olur. Uygulama birkaç saniye yazma hatası alabilir.
• Oplog boyutunu değiştir (replSetResizeOplog) — Oplog penceresi kısa: secondary'ler bakım sonrası 'too stale' oluyor, yedek oplog'u yakalayamıyor ya da zamana dönüş için yetmiyor. Her üyede kesintisiz büyütülür.
• Feature Compatibility Version (FCV) kontrol et ve tamamla — Upgrade sonrası FCV eski sürümde kaldı ya da üyeler arasında sürüm farkı var: tüm üyelerin binary sürümü ve FCV kontrol edilir, FCV yeni sürüme çekilir.
• Cluster'a shard ekle (sh.addShard) — Kapasite yetmiyor: yeni bir shard replica set'i (shardsvr) kuruldu, cluster'a eklenir; balancer chunk'ları kademeli olarak taşır.
• Shard çıkar (removeShard: drain ve movePrimary) — Bir shard emekliye ayrılıyor: chunk'ları diğer shard'lara boşaltılır (drain), primary shard olduğu veritabanları taşınır (movePrimary), sonra cluster'dan çıkarılır.
• Balancer: zaman penceresi, durdur / başlat, collection bazında kapat — Chunk taşımaları yoğun saatte yük yaratıyor, bakım/yedek için taşımaların durması gerekiyor ya da tek bir collection'ın dengelenmesi istenmiyor.
• Dağılım dengesiz ya da jumbo chunk var (teşhis ve çözüm) — Bir shard diğerlerinden çok dolu, balancer taşımıyor, 'jumbo' işaretli chunk'lar var ya da moveChunk hata veriyor: dağılım, jumbo chunk'lar ve balancer hataları incelenir.
• Shard key'i değiştir (reshardCollection) — Mevcut shard key sıcak shard, jumbo chunk ya da scatter-gather sorgular üretiyor: collection çevrimiçi olarak yeni shard key ile yeniden dağıtılır (5.0+). Sonda yazmalar ~2 sn bekler.

Başlamadan önce

• Yönetim sunucusunda mongosh kurulu ve …mongos'a (…)…tüm üyelere (…)… ad çözümlemesi ve port erişimi var. Bağlantıdaki adlar rs.conf() içindeki üye adlarıyla aynı olmalı.
• … kullanıcısının parolası elinizde; rolü root ya da en az clusterAdmin + readAnyDatabase.… Shard ya da config server replica set'ine doğrudan bağlanırken shard-local yönetici kullanıcı (mongo-sharded rehberinde oluşturulan) gerekir.…
• Değişiklik kaydı / bakım penceresi açıldı, uygulama ekibi bilgilendirildi. Reconfig, stepDown ve shard işlemleri birkaç saniyelik seçim (election) ya da yönlendirme gecikmesi yaratabilir.
• Yeni üye … replica set kurulum rehberindeki işletim sistemi, kurulum, keyfile ve yapılandırma aşamalarıyla hazırlandı: aynı MongoDB sürümü (…), aynı keyfile, replication.replSetName: …, mongod çalışıyor ama rs.initiate YAPILMADI. Diğer üyelerle iki yönlü ad çözümleme ve port erişimi var; veri diski en az mevcut veri kadar boş.
• Initial sync süresince üyenin diskinde tüm veri yeniden yazılır…; eski dizin kenara alındığı için veri boyutunun iki katı boş alan gerekir…. Kalan üyeler çoğunluğu koruyor ve kaynak üyenin oplog penceresi, initial sync'in süreceği zamandan uzun.

Rehberin aşamaları

• Durum: üyeler, gecikme ve oplog (salt-okur) — Üyelerin durumunu ve gecikmesini göster · Yapılandırmayı göster (priority, votes, hidden, delay) · Sonucu yorumla ve doğru senaryoyu seç
• Durum: shard'lar, balancer ve chunk dağılımı (salt-okur) — Cluster özetini göster · Chunk dağılımı ve jumbo chunk'lar · Shard replica set'lerinin durumunu kontrol et
• 1. Teşhis: yeni üye hazır mı? — Yeni üyenin servis ve sürümünü kontrol et · Mevcut set'in durumunu ve veri boyutunu gör · Yeni üyeye erişimi doğrula
• 2. Güvenlik ağı — Mevcut replica set yapılandırmasını kaydet
• 3. Uygulama: üyeyi ekle ve eşitlenmesini bekle — Üyeyi priority 0 / votes 0 ile ekle · Initial sync'in bitmesini bekle · Üyeye oy ve priority ver
• 4. Doğrulama ve sonrası — Durumu doğrula · Uygulama bağlantı dizesini ve izlemeyi güncelle
• 1. Teşhis: çıkarılacak üye primary mi, çoğunluk korunur mu? — Üyenin rolünü ve kalan oy sayısını hesapla
• 2. Güvenlik ağı — Mevcut replica set yapılandırmasını kaydet
• 3. Uygulama: üyeyi çıkar — Üyeyi yapılandırmadan çıkar (rs.remove) · Çıkarılan sunucuda mongod'u durdur
• 4. Doğrulama ve sonrası — Durumu doğrula · Bağlantı dizelerini, izlemeyi ve firewall'u güncelle
• 1. Teşhis — Üyenin mevcut ayarlarını ve oplog penceresini gör
• 2. Güvenlik ağı — Mevcut replica set yapılandırmasını kaydet
• 3. Uygulama — Üye ayarını değiştir (rs.reconfig)
• 4. Doğrulama — Sonucu doğrula
• 1. Teşhis: arbiter ve yeni üye — Arbiter'ı ve write concern'ü gör · Yeni üyenin hazır olduğunu doğrula
• 2. Güvenlik ağı — Mevcut replica set yapılandırmasını kaydet
• 3. Uygulama: veri üyesini ekle, arbiter'ı çıkar — Yeni üyeyi priority 0 / votes 0 ile ekle · Initial sync'in bitmesini bekle · Yeni üyeye oy ve priority ver · Arbiter'ı çıkar · Arbiter sunucusunda mongod'u durdur
• 4. Doğrulama ve sonrası — Durumu ve write concern'ü doğrula
• 1. Teşhis: üye gerçekten yeniden eşitlenmeli mi? — Üyenin durumunu ve son mesajını gör · Üyenin logundaki hatayı gör
• 2. Güvenlik ağı — Mevcut replica set yapılandırmasını kaydet
• 3. Uygulama: veri dizinini boşalt ve initial sync — mongod'u durdur · Veri dizinini …kenara al…boşalt… · mongod'u başlat (initial sync başlar) · Initial sync'in bitmesini bekle
• 4. Doğrulama ve sonrası — Durumu doğrula · Eski veri dizinini sil
• 1. Teşhis: çoğunluk gerçekten kalıcı olarak kayıp mı? — Kalan üyeden durumu ve optime'ları gör · Kayıp üyelerin kapalı olduğunu doğrula
• 2. Güvenlik ağı — Ayakta kalan üyenin yapılandırmasını kaydet
• 3. Uygulama: force reconfig — Yalnız kalan üyelerle zorla yeniden yapılandır · Primary seçildiğini doğrula
• 4. Doğrulama ve sonrası — Majority yazmayı dene · Kayıp üyeleri yeniden ekle ve kök nedeni gider
• 1. Teşhis: secondary'ler yetişmiş mi? — Primary'yi ve gecikmeleri gör
• 2. Uygulama — Diğer secondary'leri dondur (hedef üye seçilsin) · Primary'yi geri çek (rs.stepDown)
• 3. Doğrulama — Yeni durumu doğrula
• 1. Teşhis: mevcut oplog boyutu ve penceresi — Her üyede oplog boyutu ve penceresi