MongoDB 9.0 Yenilikleri

Yama Sürümleri ve Güvenlik Düzeltmeleri

9.0 serisinde şu ana kadar yayımlanan yama sürümleri şöyle: 9.0.0, 9.0.1 ve 9.0.2 aynı gün, 28 Eylül 2026'da; 9.0.4 ise 13 Ekim 2026'da çıktı. 9.0.7 notlarda "upcoming" olarak, yani henüz yayımlanmamış biçimde listeleniyor. 9.0.1 bir CVE düzeltmesi (CVE-2026-89099), 9.0.4 ise beş CVE düzeltmesi içeriyor ve notlarda "önemli güvenlik ve güvenilirlik iyileştirmeleri" olarak tanımlanıyor. 9.0.4 aynı zamanda Ubuntu 26.04 desteğini ekliyor ve aşağıda anlatılan bir step-up kilitlenme sorununu düzeltiyor. Bu yüzden 9.0'a geçecekseniz en güncel yama sürümünü hedeflemek mantıklıdır.

Genel Değişiklikler

İşlem başına bellek sınırı

MongoDB 9.0 ile tek bir sorgu işleminin kullanabileceği toplam bellek sınırlandı. Varsayılan sınır 1 gigabayt ile sunucu sürecinin kullanabildiği belleğin yüzde 20'sinden büyük olanıdır. Önceki sürümlerde bir işlem sınırsız bellek kullanabiliyordu. Sınırı aşan işlemler ExceededMemoryLimit (146) veya QueryExceededMemoryLimitNoDiskUseAllowed (292) hatasıyla başarısız olur ve sunucu günlüğüne 12932700 kodlu "Query exceeded the memory limit" mesajı düşer. Aşama başına 100 megabaytlık sınır ve aşamaların diske taşma (spill) davranışı değişmedi.

Sınır iki parametreyle ayarlanır: internalQueryMaxMemoryUsageBytesPerOperation işlem başına toplam belleği (başlangıçta, çalışırken veya query settings ile), internalQueryMaxSingleExpressionMemoryUsageBytes ise tek bir ifade değerlendirmesinin belleğini (varsayılan 100 megabayt) sınırlar. Klasik sorgu motoru artık executionStats ve üzeri ayrıntı düzeyinde, aralarında $project, $match ve $lookup de bulunan bir dizi aşama için expressionEvaluationPeakMemoryBytes alanını raporluyor. Büyük aggregation'lar çalıştırıyorsanız bunlara dikkat edin; bkz. aggregation pipeline ve explain ve sorgu planı.

Eşzamanlı transaction sınırı

Sunucu artık dış istemcilerin aynı anda açık tutabileceği çok belgeli transaction sayısını sınırlar. Sınır maxConcurrentMultiDocumentTransactions parametresiyle belirlenir ve varsayılanı 10000'dir. Sınıra ulaşıldığında yeni transaction'lar TooManyOpenTransactions hatasıyla reddedilir. Uygulamanız transaction'ları açık bırakıyorsa bu değişiklik ilk fark edeceğiniz şey olabilir; bkz. MongoDB transaction kullanımı.

Sunucu tarafı JavaScript geri döndü

MongoDB 8.0'da kullanımdan kaldırılacağı duyurulan $accumulator, $function ve $where 9.0 ile artık kaldırılacak (deprecated) durumda değil. 9.0 bu işlevleri, önceki sürümlere göre daha güçlü yalıtım ve sandbox sağlayan WebAssembly (WASM) tabanlı bir JavaScript motoruyla yeniden etkinleştiriyor. Bu motor ppc64le mimarisinde bulunmuyor; o mimaride bu operatörler ve mapReduce başarısız olur ve bir ayar ile açılamaz.

Önemli bir davranış farkı da var: yeni motor yerel Date işlemlerini sunucunun saat diliminden bağımsız olarak UTC'de değerlendirir. Saklanan BSON tarih değeri ve getTime(), toISOString(), getUTC*() gibi UTC işlemleri değişmez; değişen, getHours() gibi yerel getter'lar, toString() ve tarihleri dizgiye çeviren karşılaştırıcısız Array.prototype.sort() gibi işlemlerdir. Sonuç hata vermediği için fark sessizce ortaya çıkar. Belgelerin önerisi, saat dilimine bağlı mantığı JavaScript yerine açık timezone argümanı alan aggregation tarih operatörleriyle yazmaktır:

// 9.0 öncesi ve sonrası farklı sonuç verebilir (sunucu saat dilimine bağlıydı)
db.girisler.find({ $expr: { $function: {
  body: function (t) { return t.getHours() < 9; },
  args: [ "$zaman" ], lang: "js" } } })

// Her sürümde aynı sonuç: saat dilimi açıkça verilir
db.girisler.find({ $expr: {
  $lt: [ { $hour: { date: "$zaman", timezone: "Europe/Istanbul" } }, 9 ]
} })

İzleme metrikleri

9.0, serverStatus çıktısına change stream imleçleri, işlem başına bellek ve sharding meta verisiyle ilgili çok sayıda yeni metrik ekliyor; örneğin metrics.query.operationsFailedDueToMemoryLimit ve metrics.changeStreams.cursor.open.total. İzleme araçlarınız metrik adına bağlıysa iki yeniden adlandırmaya dikkat edin: metrics.changeStreams.showExpandedEvents artık metrics.changeStreams.option.showExpandedEvents, 8.3'te eklenen shardingStatistics.databaseVersionUpdateCounters ise shardingStatistics.databaseShardingMetadataStatistics oldu ve alanları yenilendi. 9.0.1 ayrıca çok sayıda oturumda kilit çekişmesini azaltmak için sessionCatalogPartitions parametresini ekledi.

Sorgu Dili ve Query Settings

• Komut alanı olarak query settings: find, distinct ve aggregate komutlarına doğrudan bir querySettings belgesi verebilirsiniz. Bu ayarlar yalnızca o çalıştırmaya uygulanır ve kümede saklanmaz. Aynı sorgu şekli için setQuerySettings ile saklanmış ayar varsa ikisi birleştirilir; aynı alan iki yerde varsa saklanmış ayar önceliklidir.
• queryKnobs: Tek bir sorgu şekli için iç sunucu parametrelerini geçersiz kılmayı sağlar ve FCV 9.0 gerektirir.
• Sorgu şekli başına maxTimeMS: setQuerySettings ile tek bir sorgu şekline süre sınırı koyabilirsiniz; bu da FCV 9.0 gerektirir.
• $queryStats varsayılan açık: Okuma ve yazma işlemleri için istatistik varsayılan olarak toplanır, ancak tüm işlemler için değil, örneklem üzerinden. internalQueryStatsSampleRate ve internalQueryStatsWriteCmdSampleRate parametrelerinin varsayılanı 0.01, yani işlemlerin yüzde 1'idir. update, insert ve delete komutları da artık raporlanıyor ve çıktı metrics.cursor, metrics.queryExec, metrics.queryPlanner, metrics.writes belgeleri altında yeniden düzenlendi.

Veri Saklama ve Doğrulama

• BSON doğrulama: 9.0 sunucunun aldığı tüm BSON nesnelerini varsayılan olarak doğrular ve geçersiz BSON için hata döndürür. Bu nedenle net.wireObjectCheck ayarı ve --objcheck komut satırı seçeneği kullanımdan kaldırılacak (deprecated) olarak işaretlendi. Yapılandırma dosyanızı gözden geçirmek için mongod.conf rehberine bakın.
• constraint doğrulama seviyesi: Yeni validationLevel: "constraint", kuralları tüm eklemelere ve güncellemelere uygular ve koleksiyondaki her belgenin kurallara uyduğunu garanti eder. Ayrıntı için schema validation ve $jsonSchema yazısına bakın.
• Time series saklama: Time series koleksiyonları artık sıkıştırılmış bucket'ları içeren tek bir ad alanında tutuluyor ve yazılabilir, materyalize edilmemiş view olarak çalışmıyor. Tek veritabanında 5.000'den fazla time series koleksiyonu olan kümelerde yükseltme daha uzun sürebilir ve yazma gecikmesinde sıçramalar görülebilir; belgeler gereksiz koleksiyonları önceden silmeyi önerir. Ayrıca bu koleksiyonlarda find, aggregate ve listIndexes yanıtındaki cursor.ns artık iç ad alanı yerine sizin hedeflediğiniz adı döndürüyor. Bkz. time series koleksiyonları.

Güvenlik

Queryable Encryption ile şifrelenmiş dizgi alanlarında önek, sonek ve alt dizgi sorguları 9.0 ile genel kullanıma (GA) geçti. Bu GA özellik, 8.2'de yayımlanan önizleme (Public Preview) sürümüyle uyumlu değil; önizleme sorgu türleri (prefixPreview, suffixPreview, substringPreview) kullanımdan kaldırılacak olarak işaretlendi. Önizlemeyi kullananlar için belgeler iki yol veriyor: tercih edilen yol yeni bir şifreli koleksiyonla baştan başlamak, diğeri veriyi 9.0 uyumlu bir sürücüyle sorgulayıp çözerek yeni koleksiyona aktarmak. mongodump ve mongoexport şifreli koleksiyonu çözmez.

Diğer güvenlik değişiklikleri: mongocryptd kullanımdan kaldırılacak olarak işaretlendi ve yerine ayrı bir süreç gerektirmeyen paylaşımlı kütüphane öneriliyor; useInternalAuthzForX509 parametresi MONGODB-X509 ile doğrulanan istemcilerin LDAP yetkilendirmesi açıkken bile iç yetkilendirme kullanmasını sağlıyor; usersInfo komutuna authenticatedMechanism alanı geldi; denetim (audit) mesajlarına, PROXY protokol başlığından bağımsız olarak gerçek TCP eşini kaydeden directRemote alanı eklendi. Kullanıcı yönetimi için kullanıcı ve rol yönetimi yazısına bakın.

Replikasyon, Sharding ve Teşhis

• Replikasyon: Mantıksal ilk eşitleme sırasında replSetGetStatus artık initialSyncStatus.phase, totalAttempts ve bytesPerSecond alanlarını raporluyor. Bkz. replica set kurulumu.
• Sharding: checkMetadataConsistency komutuna dört yeni tutarsızlık türü ve performStrictChunkChecksIfBelowThreshold seçeneği eklendi; mongosh için sh.shardDrainingStatus() ve sh.getTransitionToDedicatedConfigServerStatus() yöntemleri geldi. Bkz. sharding ve shard key.
• Geo indeks hataları: 2dsphere indeksinde anahtar çıkarma hataları artık adlandırılmış 510 (GeoKeyExtractionFailed) ve 511 (GeoKeyExtractionFailedTimeseries) kodlarıyla dönüyor ve writeErrors[].errInfo içinde sorunlu yolu gösteriyor. Eski kodlar (16755, 16756 ve time series için 183934, 183493) ile eşleşen uygulamaları güncellemeniz gerekir. Bkz. geospatial ve 2dsphere sorguları.
• Change stream metrikleri: currentOp çıktısı change stream imlecinin oplog'daki konumunu (currentOp.cursor.changeStreams.optime) gösteriyor.

Uyumluluğu Bozan Değişiklikler

Veritabanları arası renameCollection değişikliği bir veri güvenliği düzeltmesidir: önceki sürümler kaynak koleksiyonun kilidini işlem bitmeden bırakıyordu ve bu aralıkta kaynağa yapılan bir yazma kaybolabiliyordu. Değişiklik yalnızca replica set'leri etkiler; sharded kümeler zaten iki koleksiyonu da kilitliyordu. Çoğu okuma kilitsiz okuma kullandığı için engellenmez.

Geriye dönük uyumsuz özellikler bölümünde tek bir madde var: 9.0'da $convert bir nesneyi binData türüne dönüştürebiliyor. Bu dönüşümü kullanan bir view oluşturursanız, daha eski bir sürüme geri döndüğünüzde o view üzerindeki sorgular hata verir. Geri dönüş (downgrade) öncesinde bu view'ları güncelleyin veya silin; view'lar hakkında bilgi için $out, $merge ve view yazısına bakın.

Bilinen Sorunlar

• SERVER-133518 (9.0.0 ile 9.0.2): Bir shard, önceki bir step-down sırasında yarıda kalan chunk işlemi nedeniyle step-up sırasında takılabilir ve primary olamaz. Secondary'ler okuma sunmaya devam eder. Kurtarmak için takılan düğümü yeniden başlatmak gerekir. 9.0.4'te düzeltildi.
• SERVER-136226 (açık): Sharded kümedeki düğümler her config sunucusuna en az ShardingTaskExecutorPoolMinSize kadar bağlantı açar; bu config sunucularını tüketebilir. Bu değer 1'den büyükse, ayrı config sunucusu kullanan kümelerde yükseltmeden önce ShardingTaskExecutorPoolMinSizeForConfigServers değerini 1 yapın.
• SERVER-89953 (açık): FCV 9.0'da listIndexes, basit collation kullanan indeksler için collation: { locale: "simple" } raporluyor. Bazı ODM araçları bunu indeks tanımında fark olarak yorumlayıp, uygulama her başladığında indeksleri silip yeniden oluşturabiliyor. Belgelerin önerisi indeks senkronizasyonunu uygulama açılışından çıkarıp açık bir dağıtım adımı olarak yapmak.
• SERVER-136961 (açık): Temiz olmayan bir kapanıştan sonra dosya kopyalama tabanlı ilk eşitleme yapan düğüm her açılışta çökebilir. Çözüm, düğümü initialSyncMethod: logical ile başlatmak veya storage.dbPath içeriğini silip eşitlemeyi baştan başlatmaktır.

9.0'a Yükseltme: Özet Yol Haritası

Resmî yükseltme sayfalarına göre 9.0'a yalnızca 8.3 veya 8.0 sürümünden geçebilirsiniz. Daha eski bir sürümdeyseniz önce sırasıyla ana sürümleri yükseltip 8.0 serisine ulaşmanız gerekir; örneğin 7.0 serisindeyseniz önce 8.0'a geçersiniz. Başlamadan önce sürücülerinizin MongoDB 9.0 ile uyumlu olduğunu doğrulayın, uyumluluk sayfasındaki maddeleri çözün ve yükseltmeyi üretimden önce bir test ortamında deneyin. Güncel bir yedeğiniz olmadan yükseltmeye başlamayın; bkz. mongodump ve mongorestore.

Kaynak sürümün featureCompatibilityVersion (FCV) değeri, kendi sürümüne eşit olmalıdır. Bunu her üyede şu komutla kontrol edersiniz:

db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

Replica set için belgelerdeki sıralı (rolling) yükseltme şöyledir: hiçbir üyenin ROLLBACK veya RECOVERING durumunda olmadığını replSetGetStatus ile doğrulayın; secondary'leri birer birer kapatıp ikili dosyalarını yeni sürümle değiştirerek yeniden başlatın; primary'ye bağlanıp rs.stepDown() ile seçimi zorlayın; eski primary secondary olduğunda onu da yükseltin. MongoDB'yi apt gibi bir paket yöneticisiyle kurduysanız yeni sürümün deposunu ekleyip paket yöneticisiyle yükseltmeniz gerekir; Ubuntu için MongoDB Ubuntu kurulumu yazısına bakın.

Son adım, geriye dönük uyumsuz 9.0 özelliklerini açmaktır. Belgeler bu adımdan önce bir süre bekleyip (burn-in) geri dönüş ihtimalinin düşük olduğundan emin olmayı önerir, çünkü FCV yükseltildikten sonra geri dönmek zorlaşır. Devam eden bir ilk eşitleme olmadığından emin olun; aksi halde eşitleme yeniden başlar. Komut primary üzerinde, admin veritabanında çalıştırılır ve tekrar çalıştırılması güvenlidir:

db.adminCommand({ setFeatureCompatibilityVersion: "9.0", confirm: true })

Sık Sorulan Sorular

8.0'dan doğrudan 9.0'a geçebilir miyim?

Evet. Resmî yükseltme yolu 8.3 veya 8.0 sürümünden 9.0'a geçişi destekler; 8.0 için ayrı bir yükseltme sayfası bulunur. 7.0 veya daha eski bir sürümdeyseniz önce 8.0'a yükseltmeniz gerekir.

$where ve $function kullanan kodum 9.0'da çalışır mı?

Evet; bu işlevler 9.0'da yeniden destekleniyor ve kaldırılacak olarak işaretli değil. İki istisna var: ppc64le mimarisinde çalışmazlar ve yerel tarih işlemleri artık UTC ile değerlendirildiği için saat dilimine bağlı mantık farklı sonuç verebilir.

Sorgularım ExceededMemoryLimit hatası vermeye başladı, ne yapmalıyım?

9.0 ile gelen işlem başına bellek sınırına takılıyorsunuz. İşlenen veri miktarını erken bir $match ve uygun indekslerle küçültmek ilk adımdır; sınırı değiştirmek için internalQueryMaxMemoryUsageBytesPerOperation parametresi kullanılabilir. Aşama başına 100 megabayt sınırı ve diske taşma davranışı değişmediği için bu iki sınırı ayrı düşünün.

FCV'yi 9.0 yapmadan 9.0 ikili dosyalarını çalıştırmak güvenli mi?

Belgelere göre ikili dosyaları yükselttikten sonra, 8.3 ile uyumsuz 9.0 özellikleri kapalıyken 9.0 ile çalışabilirsiniz. queryKnobs ve sorgu şekli başına maxTimeMS gibi bazı yenilikler ise FCV 9.0 gerektirir.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MongoDB öğrenme rehberi · Transaction kullanımı · Schema validation · Time series koleksiyonları · Replica set kurulumu · Aggregation pipeline