dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
dbaguide.com
Home/Hata Teşhis Kütüphanesi/mongodb-not-writable-primary
Hatalara Dön
MongoDB
MongoDB 8.0 / 7.0 / 6.0 / 5.0Replikasyon & HA
8 dk okuma
MongoServerError: not primary and secondaryOk=false (NotWritablePrimary, code 10107) / not master

MongoDB "not master" — Failover Sonrası Uygulama Neden Yazamıyor?

Failover sonrası "not master" hatasının nedeni, replicaSet içermeyen bağlantı dizesi, retryWrites ve election fırtınası teşhisi.

İnceleyen:Senior NoSQL Reliability Architect
Test Edilen Sürümler: MongoDB 8.0 & 7.0 (NotWritablePrimary code 10107) | MongoDB 4.4 ("not master")

Operasyonel Doğrulama & Güvenilirlik Standardı

Son Teknik İnceleme: 29 Ekim 2026
Test Edilen SürümlerMongoDB 8.0 & 7.0 (code 10107) | Tarihsel: MongoDB 4.4, 5.0, 6.0
Gerekli YetkiReplica set durumunu izleme (clusterMonitor veya readAnyDatabase) ve bağlantı dizesi düzenleme
Risk Seviyesi
HighTek düğümlü bağlantı dizesi kullanan uygulamalar failover sonrasında tamamen yazamaz hale gelir
Beklenen ÇıktıreplicaSet parametreli bağlantı dizesi ve retryWrites ile kesintisiz failover yönlendirmesi
Geri Dönüş (Rollback) Planı:Bağlantı havuzunu yeniden başlatma veya primary düğümü manuel rs.stepDown() ile seçme
MongoDB Manual: Replica Set Status & Failover
İlk 60 Saniye Teşhis Protokolü:

Hata mesajı semptomdur, kök neden değildir. Sunucuyu yeniden başlatmadan veya rastgele ayar değiştirmeden önce aşağıdaki "Nedeni ayırt eden tek sorgu"yu çalıştırarak gerçek senaryoyu netleştirin.

▸Belirti

plaintext
MongoServerError: not primary and secondaryOk=false - consider using readPreference=primary. (NotWritablePrimary, code 10107)

Sürüme göre iki farklı metin gözlemlenir:

  • •MongoDB 5.0 Öncesi: not master
  • •MongoDB 5.0 ve Sonrası: NotWritablePrimary (Hata Kodu 10107)

Aynı hata ailesinden gelen akraba kodlar:

KodHata AdıAnlamı
10107NotWritablePrimaryBağlanılan düğüm artık primary değil
13435NotPrimaryNoSecondaryOkSecondary düğüme okuma izni olmadan sorgu gönderildi
189PrimarySteppedDownPrimary düğüm kendini geri çekti (failover başladı)
11602InterruptedDueToReplStateChangeReplikasyon durumu değiştiği için işlem kesildi

▸Kök Neden: Yanlış Bağlantı Modeli

Replica set failover'ı bir arıza değil, tasarımın gerektirdiği normal bir olaydır. Hata, uygulamanın topoloji değişiminden habersiz olmasından kaynaklanır:

plaintext
-- YANLIŞ: Tek bir sunucuya doğrudan bağlanıyor mongodb://10.0.1.5:27017/app -- DOĞRU: Replica set topolojisini sürücüye teslim ediyor mongodb://h1:27017,h2:27017,h3:27017/app?replicaSet=rs0&readPreference=primary

İlk biçimde sürücü tek bir IP'ye bağlanır; o sunucu failover ile secondary olduğunda yazma reddedilir ve sürücünün yeni primary'yi keşfetme imkânı kalmaz. İkinci biçimde ise sürücü tüm küme üyelerini dinamik olarak keşfeder ve yazmaları otomatik olarak yeni primary'ye yönlendirir.

▸Adım Adım Teşhis

1. Küme Durumunu Sorgulayın

javascript
rs.status().members.map(m => ({ name: m.name, state: m.stateStr })); db.hello(); // isWritablePrimary, primary, me bilgilerini doğrular

2. Anlık Failover mı, Kronik Seçim (Election) Fırtınası mı?

javascript
rs.status().members.map(m => ({ name: m.name, state: m.stateStr, health: m.health, optimeDate: m.optimeDate, electionTimeout: m.electionTimeoutMillis })); rs.printReplicationInfo();
  • •health: 0 olan bir üye ağ izolasyonu yaşamaktadır.
  • •Secondary düğümlerin optimeDate değeri primary'den belirgin derecede gerideyse (replikasyon gecikmesi), seçilebilir primary adayı kalmadığı için failover süresi uzar.

3. Oplog Boyutunu ve Dayanıklılığını Denetleyin

javascript
db.getSiblingDB('local').oplog.rs.stats().maxSize; rs.printReplicationInfo(); -- "log length start to end" penceresi

Yetersiz oplog boyutu, geçici bir bakım sırasında geride kalan bir secondary'nin bir daha asla yetişememesine (stale) yol açar.

▸Çözüm Yolları

1. Bağlantı Dizesini Replica Set Parametresiyle Güncelleyin

Yukarıdaki ?replicaSet=rs0 biçimini uygulayın.

2. retryWrites Özelliğini Etkinleştirin

plaintext
mongodb://h1:27017,h2:27017,h3:27017/app?replicaSet=rs0&retryWrites=true&w=majority

MongoDB 4.2+ sürücülerinde varsayılan olarak açıktır; ağ kopmalarında tek seferlik yazmaları otomatik yineler.

3. Okuma Tercihini (readPreference) Bilinçli Seçin

Uygulamanız mutlaka en güncel veriyi istiyorsa readPreference=primary kullanın; secondaryPreferred seçilirse geçici veri gecikmelerinin kabul edildiği anlamına gelir.

4. Uygulama Katmanında Hata Kodlarını Sınıflandırın

Uygulamada yalnızca 10107, 189 ve 11602 kodları otomatik yeniden denenmeli (retry); 13435 ise yapılandırma hatası olduğu için retry edilmemelidir.

▸Bunu Bir Daha Yaşamamak İçin

Bakım pencerelerinde kontrollü olarak rs.stepDown() çalıştırarak uygulamanın kesintisiz devam edip etmediğini test edin (Failover Tatbikatı).