Runbook #56

mongodb

LockingSEV2 · CİDDİ BOZULMA15-30 dakika / 15-30 minsclusterAdmin / dbAdminAnyDatabase / root

MongoDB Write Conflict ve İptal Edilen Transaction'lar: Sıcak Doküman Teşhisi

Write conflict artışını gerçek işlem iptallerinden ayırır; aynı dokümanda çakışan yazmaları azaltmak ve güvenli transaction retry tasarlamak için yol gösterir.

İlişkili Metrik:M59

İlişkili Script:S97 S89

#writeConflict#transactions#hot-document#retry

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

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. Etki / 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. Teşhis / Diagnosis

🟢 Salt Okunur1. İ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.

🟢 Salt Okunur2. `currentOp` ile uzun transaction ve bekleyen işlemleri (S89) bulun; uygulama APM'inde namespace, komut ve tekrar deneme sayılarını eşleştirin.

🟢 Salt Okunur3. 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.

🟢 Salt Okunur4. Replica lag, cache dirty ve disk gecikmesini ayırın; M54/M53 artışı varsa sadece retry sayısını yükseltmeyin.

4. Müdahale / Response

🟡 Geri Alınabilir1. 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.

🟡 Geri Alınabilir2. İ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.

🟡 Geri Alınabilir3. 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.

🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. 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. Doğrulama / Verification

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

6. Geri Alma / Rollback

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.

Operasyonel Güvenlik ve Risk Uyarısı

1. Belirti / Symptom

2. Etki / Impact

3. Teşhis / Diagnosis

4. Müdahale / Response

5. Doğrulama / Verification

6. Geri Alma / Rollback

Diğer MONGODB Runbook'ları

MongoDB Replica Set Replikasyon Gecikmesi: Teşhis ve Çözüm

MongoDB WiredTiger Cache Baskısı: Çalışma Seti RAM'e Sığmıyor

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

MongoDB Oplog Penceresi Kısa: Secondary Resync Riskini Önleme