dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbooks Library/mongodb/#56
Runbook #56
mongodb
LockingSEV2 · DEGRADATION15-30 dakika / 15-30 minsclusterAdmin / dbAdminAnyDatabase / root

MongoDB Write Conflicts and Aborted Transactions: Hot Document Triage

Separates write conflict growth from transaction aborts, reduces writes to hot documents, and guides safe transaction retries.

Related Metrics:M59
Related Scripts:S97S89
#writeConflict#transactions#hot-document#retry

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.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Symptom & Signals

M59 write conflict hızında artış; uygulamada `WriteConflict`, `TransientTransactionError`, transaction abort veya p95 yazma gecikmesi görülür. Tüm write conflict'ler kullanıcı hatasına dönüşmez; sürücü bazılarını otomatik tekrar deneyebilir.

2. Business & Technical Impact

Transaction throughput düşer, otomatik retry yükü artar; yanlış retry tasarımı çift işleme veya beklenmedik tutarsızlık doğurabilir.

3. Diagnosis & Root-Cause Analysis

🟢 Read-Only1. İki örnek arasında artışı ölçün (S97); kümülatif sayıyı tek başına yorumlamayın:
javascript
const s = db.serverStatus();
({ transactions: s.transactions,
   writeConflicts: s.metrics?.operation?.writeConflicts,
   queues: s.globalLock?.currentQueue });

Bazı sürümlerde alt alanlar farklı/eksik olabilir; dönen nesneyi inceleyin.

🟢 Read-Only2. `currentOp` ile uzun transaction ve bekleyen işlemleri (S89) bulun; uygulama APM'inde namespace, komut ve tekrar deneme sayılarını eşleştirin.
🟢 Read-Only3. Tek dokümanda yoğun `$inc`, sıra numarası, tekil sayaç veya stok güncellemesi var mı? Çok sayıda thread'in aynı belgede yazması sıcak doküman problemidir. Aynı işlemin içinde uzun okuma veya dış servis çağrısı varsa transaction süresini ölçün.
🟢 Read-Only4. Replica lag, cache dirty ve disk gecikmesini ayırın; M54/M53 artışı varsa sadece retry sayısını yükseltmeyin.

4. Remediation & Action Plan

🟡 Reversible1. Uygulamada transaction'ı kısa tutun; ağ/dış servis çağrısını transaction dışına alın; bağımsız yazmaları mümkünse küçük birimlere ayırın.
🟡 Reversible2. İstemci tarafında yalnızca **geçici** hatalara yönelik bounded exponential backoff + jitter ve idempotent operasyon kullanın. MongoDB sürücüsünün `withTransaction()` gibi resmi retry akışını ve hata etiketlerini kullanın, dış yan etkilerin (ödeme/e-posta) tekrarını engelleyin.
🟡 Reversible3. Tek sıcak sayacı shard'lı/bucket'lı sayaçlara bölmeyi veya iş akışını kuyruklamayı değerlendirin. Şema değişikliğini test edin.
🔴 HIGH RISK / IRREVERSIBLE4. Açık transaction'ları topluca `killOp` ile sonlandırmayın, `writeConcern`/dayanıklılık ayarlarını sırf sayaç düşsün diye gevşetmeyin.

5. Verification & Health Checks

M59 rate düşüyor; abort ve retry oranları baz çizgiye yakın, uygulama sonucunda yinelenen yan etki yok, p95/p99 yazma gecikmesi normal.

6. Rollback & Contingency Plan

Uygulama throttling ve retry sürümünü önceki kararlı sürüme alın. Transaction sırasında yapılmış dış yan etkiler otomatik rollback olmaz; idempotency kayıtlarıyla uzlaştırın.

More MONGODB Runbooks