dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #52
mongodb
PerformanceSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minsclusterAdmin / dbAdminAnyDatabase / root

MongoDB Yavaş Sorgu ve COLLSCAN: İndeks Eksikliğini Teşhis Etme

Taranan/dönen doküman oranını, profiler ve explain çıktısını birleştirerek pahalı sorguyu bulur; uygun indeksi düşük riskle devreye alır.

İlişkili Metrik:M55
İlişkili Script:S92S85S83
#COLLSCAN#explain#index#slow-query

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

M55 baz çizginin üzerine çıkar, sorgu gecikmesi artar; profiler veya `explain` içinde `COLLSCAN` görülür. Küçük koleksiyonlarda COLLSCAN normal olabileceğinden metrik tek başına hata değildir.

2. Etki / Impact

CPU/disk taraması ve cache churn artar; aynı anda başka sorgular da yavaşlar.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. Profiler açıksa (S92, S85) pahalı sorguları okuyun:
javascript
db.getSiblingDB('uygulama').system.profile.find(
  { planSummary: 'COLLSCAN' },
  { ts: 1, ns: 1, millis: 1, docsExamined: 1, nreturned: 1, command: 1 }
).sort({ ts: -1 }).limit(20);

Profiler kapalıysa üretimde varsayılan olarak açmayın; önce uygulama APM'i, slow query loglarını ve `currentOp` verisini kullanın. Profiler'ın etkinleştirilmesi performans ve depolama maliyeti doğurur; süreli onayla açın.

🟢 Salt Okunur2. Gerçek filtre ve sıralamayı alıp **parametreler kontrol edilerek** planı karşılaştırın:
javascript
db.getSiblingDB('uygulama').orders
  .find({ customerId: '<ornek-id>', status: 'OPEN' })
  .sort({ createdAt: -1 }).limit(20)
  .explain('executionStats');
🟢 Salt Okunur3. `winningPlan`, `totalDocsExamined`, `totalKeysExamined`, `nReturned`; filtre, sıralama ve indeks sırasını değerlendirin. `explain` planı bazı sürümlerde plan cache davranışından farklı olabilir. Kullanılmayan indeksleri (S83) kontrol ederek yeni indeksle tekrar yaratmayın.

4. Müdahale / Response

🟡 Geri Alınabilir1. Önce sorguyu daraltın: uygun filtre, projection, limit; gereksiz geniş regex ve tüm koleksiyon taramasını kaldırın.
🟡 Geri Alınabilir2. Test ortamında filtre eşitliği ve sıralamaya göre bileşik indeks tasarlayın, disk/RAM ve yazma maliyetini hesaplayın. Örnek **yalnızca örnek iş yükü için**:
javascript
db.getSiblingDB('uygulama').orders.createIndex(
  { customerId: 1, status: 1, createdAt: -1 },
  { name: 'customer_status_createdAt' }
);

İndeks oluşturma üretimde kaynak tüketir; bakım penceresi ve replica sağlığını kontrol edin. 4.4/5.0/6.0/7.0 sürümlerinde davranış ve index-build ayrıntıları için kendi sürüm dokümanını doğrulayın.

🔴 YÜKSEK RİSK / GERİ ALINAMAZ3. Geniş indeksi yük altında körlemesine yaratmayın veya mevcut indeksleri sadece `$indexStats` sıfır diye silmeyin; istatistikler restart sonrası sıfırlanır ve secondary'ler ayrı izlenir.

5. Doğrulama / Verification

`IXSCAN` veya hedefe uygun plan, `totalDocsExamined/nReturned` ve p95 gecikmesi iyileşiyor; M55 baz çizgiye iniyor, yazma ve replica gecikmeleri artmıyor.

6. Geri Alma / Rollback

Yeni indeks regresyon yaratırsa uygulama sorgusunu/indeksi önceki sürüme çevirin; `dropIndex('customer_status_createdAt')` yeniden oluşturma süresi ve olası plan değişimi nedeniyle kontrollü yapılmalıdır. Yapılan index build otomatik geri alınmaz.

Diğer MONGODB Runbook'ları