dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #49
mongodb
AvailabilitySEV1 · KRİTİK KESİNTİ15-30 dakika / 15-30 minsclusterAdmin / dbAdminAnyDatabase / root

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

Bağlantı sınırına yaklaşan MongoDB sunucusunda istemci ve uygulama bazında oturumları belirler; havuz kaçağını ve bağlantı fırtınasını ayırıp güvenli müdahale önerir.

İlişkili Metrik:M49
İlişkili Script:S88S87S81
#connections#maxIncomingConnections#connection-pool#incident

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

`db.serverStatus().connections.current` hızla artar, `available` düşer (M49); istemcide connection timeout, server selection timeout veya connection refused görülür. `mongos` kullanılan kümelerde yönlendirici ve `mongod` bağlantılarını ayrı değerlendirin.

2. Etki / Impact

Yeni bağlantılar açılamaz, havuz beklemeleri ve API hataları artar. Mevcut oturumlar çalışsa da kısa süre sonra uygulama kullanılmaz hale gelebilir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. Yönetim bağlantısı hâlâ kurulabiliyorsa ilgili `mongod` üzerinde ölçün (S87):
javascript
const c = db.serverStatus().connections;
({ current: c.current, available: c.available, totalCreated: c.totalCreated });
🟢 Salt Okunur2. Bağlanan uygulamaları ve kaynakları gruplayın (S88). Çok sayıda idle bağlantı için `idleConnections` gerekebilir:
javascript
db.getSiblingDB('admin').aggregate([
  { $currentOp: { allUsers: true, idleConnections: true } },
  { $match: { client: { $type: 'string' } } },
  { $group: { _id: { client: '$client', app: '$appName' }, count: { $sum: 1 } } },
  { $sort: { count: -1 } }, { $limit: 20 }
]);

`client` genellikle port içerir; aynı IP'nin farklı portlarını ayrıca gruplayın. `$currentOp` için uygun clusterMonitor/inprog yetkisi gerekir. Komut desteklenmiyorsa uygulama havuzu telemetrisi ve bağlantı loglarını kullanın.

🟢 Salt Okunur3. Ani `totalCreated` artışı havuzun tekrar tekrar açılmasına, sürekli yüksek `current` büyük havuz/sızıntıya, ağır aktif operasyonlar (S81) ise sorgu birikmesine işaret edebilir.

4. Müdahale / Response

🟡 Geri Alınabilir1. Problemli uygulamada yeni bağlantı üretimini azaltın: deployment başına `maxPoolSize` ve uygulama replika sayısını birlikte hesaplayın, yeniden bağlanma/backoff fırtınasını sınırlayın. Uygulama owner'ıyla koordine edin.
🟡 Geri Alınabilir2. Sızdıran uygulama örneğini kontrollü yeniden başlatın; tüm örnekleri aynı anda yeniden başlatmayın, yeniden bağlanma fırtınası yaratır.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ3. Zorunluysa yalnızca belirlenmiş problemli oturumun **işlemini** `db.killOp(opid)` ile sonlandırın; bu bağlantı limitini kalıcı çözmez ve işlem kısmen uygulanmış olabilir. Toplu kill veya `mongod` restart yapmayın.
🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. `net.maxIncomingConnections` sınırını körlemesine artırmayın. İşletim sistemi açık dosya sınırını (`ulimit -n`), bellek rezervini ve `mongos` topolojisini kontrol edin; yapılandırma değişikliği için ilgili sürüm prosedürünü izleyin.

5. Doğrulama / Verification

M49 düşüyor, `available` payı toparlanıyor, `totalCreated` artışı olağan hızda; uygulamanın yeni bağlantıları ve sorguları başarılı. En az 15 dakika tekrarını izleyin.

6. Geri Alma / Rollback

Havuz ayarını eski değere ve eski deployment sürümüne döndürün. Sonlandırılan işlemler geri alınmaz; uygulamanın idempotent retry davranışını ve olası kısmi sonuçları kontrol edin.

Diğer MONGODB Runbook'ları