ApsaraDB for MongoDB:MongoDB örneklerinde yüksek disk alanı kullanımı

Çoğaltma kümesi mimarisi

ApsaraDB for MongoDB örneğiniz çoğaltma kümesi mimarisi kullanıyorsa ApsaraDB for MongoDB konsolu üzerinde oturum açın ve alan kullanımını kontrol etmek için aşağıdaki yöntemleri kullanın:

• Genel bakış

  Basic Information sayfasında Specification Information bölümüne giderek örneğin Disk space ve Usage değerlerini görüntüleyin.

• İzleme grafiği analizi

  Sol gezinme bölmesinde Monitoring Information seçeneğini tıklayın. Hedef düğümü seçerek Disk Usage (Bytes) ve Disk Usage (%) değerlerini görüntüleyin.

  Bir ApsaraDB for MongoDB çoğaltma kümesi örneği; okuma ve yazma işlemleri için bir birincil düğüm, yüksek kullanılabilirlik için bir veya daha fazla ikincil düğüm, gizli bir düğüm ve isteğe bağlı salt okunur düğümlerden oluşur. Her düğümün alan kullanımı data_size ve log_size bileşenlerinden oluşur; burada ins_size = data_size + log_size şeklindedir:

  • data_size: local veritabanı hariç, veriler tarafından kullanılan disk alanı. Bu; veri dosyalarını (collection önekli), dizin dosyalarını (index önekli) ve WiredTiger.wt gibi meta veri dosyalarını içerir.

  • log_size: local veritabanının fiziksel boyutu, MongoDB çalışma zamanı günlüklerinin boyutu ve bazı denetim günlüklerinin boyutu.

• Ayrıntılı analiz

  Alan kullanımını ayrıntılı olarak analiz etmek için aşağıdaki yöntemleri kullanın:

  • MongoDB'nin yerel komutlarını db.stats() ve db.$collection_name.stats() kullanın.

    Bu komutlar hakkında daha fazla bilgi için aşağıdaki MongoDB belgelerine bakın:

    • db.stats()

    • db.collection.stats()

    • db.collection.storageSize()

    • db.collection.totalIndexSize()

    • db.collection.totalSize()

  • CloudDBA > Storage Analysis sayfasını kullanın.

    CloudDBA > Storage Analysis sayfasında aşağıdaki bilgileri görüntüleyebilirsiniz:

    • Veritabanları ve koleksiyonlar için alan kullanımına genel bakış, ortalama günlük artış ve depolama alanının dolmasına kadar tahmini gün sayısı.

    • Anormal veritabanlarının ve tabloların alan kullanımı.

    • İş koleksiyonları için ayrıntılı alan kullanımı; dizin dosyası boyutu, veri dosyası boyutu, sıkıştırma oranı analizi ve ortalama belge boyutu dahil.

Parçalanmış küme mimarisi

ApsaraDB for MongoDB örneğiniz parçalanmış küme mimarisi kullanıyorsa ApsaraDB for MongoDB konsolu üzerinde oturum açın ve alan kullanımını kontrol etmek için aşağıdaki yöntemleri kullanın:

• İzleme grafiği analizi

  Monitoring Information sayfasında hedef düğümü seçerek Disk Usage (Bytes) ve Disk Usage (%) değerlerini görüntüleyin.

• Ayrıntılı analiz

  MongoDB'nin yerel komutlarını db.stats() ve db.$collection_name.stats() kullanarak her düğümün alan kullanımını sırayla analiz edin.

Sıkıştırma sırasında örnek üzerindeki etki

compact işlemi süresi koleksiyon boyutuyla doğru orantılı olduğundan uzun sürebilir. Okuma ve yazma işlemlerini etkilememek için compact işlemini yoğun saatler dışında çalıştırın.

Compact yöntemi

İşiniz üzerindeki etkiyi en aza indirmek için önce ikincil bir düğümde db.runCommand({compact:"collectionName"}) komutunu çalıştırın ve ardından birincil/ikincil anahtarlama işlemi yapın. collectionName yerine koleksiyonunuzun adını yazın.

compact komutunun kullanımı hakkında daha fazla bilgi için bkz. Disk kullanımını iyileştirmek için diskleri parça defragmentasyonu yapın.

Büyük journal günlüklerinden kaynaklanan alan farkı

4,0 sürümünden önceki ApsaraDB for MongoDB sürümlerinde, ana makinedeki açık dosya sayısı sınıra ulaştığında dahili günlük sunucusu temizleme iş parçacığı kesintiye uğrar ve journal günlüğü sonsuza kadar büyür. MongoDB çalışma zamanı günlüklerinde aşağıdakine benzer günlük girişleri görürseniz çekirdeği ApsaraDB for MongoDB 4,0 veya sonraki bir sürüme yükseltin. Geçici bir çözüm olarak mongod sürecini yeniden başlatın. Daha fazla ayrıntı için bkz. log-server thread exit quietly on error while the mongodb process still running.

2019-08-25T09:45:16.867+0800 I NETWORK [thread1] Listener: accept() returns -1 Too many open files in system 
2019-08-25T09:45:17.000+0800 I - [ftdc] Assertion: 13538:couldn't open [/proc/55692/stat] Too many open files in system src/mongo/util/processinfo_linux.cpp 74
2019-08-25T09:45:17.002+0800 W FTDC [ftdc] Uncaught exception in 'Location13538: couldn't open [/proc/55692/stat] Too many open files in system' in full-time diagnostic data capture subsystem. Shutting down the full-time diagnostic data capture subsystem.

Çoğaltma gecikmesi ve yedeklemelerden kaynaklanan günlük büyümesi

Bir ApsaraDB for MongoDB örneğinde çoğaltma gecikmesi yaşandığında oplog'un kullanılabilir boyutu artık yapılandırma dosyasında tanımlanan sabit boyutlu koleksiyonla sınırlı değildir. Teorik olarak sağlanan disk kapasitesinin %20'sine kadar büyüyebilir. Gecikme çözüldükten sonra oplog tarafından kaplanan ekstra alan otomatik olarak geri kazanılmaz.

Fiziksel bir yedekleme sırasında gizli bir düğümdeki ApsaraDB for MongoDB örneği çok sayıda kontrol noktası oluşturarak daha fazla veri ve günlük alanı tüketir.

db.grantRolesToUser("root", [{db: "local", role: "dbAdmin"}])
use local
db.runCommand({ compact: "oplog.rs", force: true })

Uygunsuz parça anahtarı türü

Parçalanmış bir kümede parça anahtarı türünün seçimi kritiktir. İki ana tür karma parçalama ve aralıklı parçalamadır. Disk dengesi açısından karma parçalama, aralıklı parçalamadan genellikle daha iyi bir stratejidir çünkü ApsaraDB for MongoDB verileri anahtar değerlerine göre parçalar arasında eşit şekilde dağıtmak için dahili bir karma işlevi kullanır. Buna karşılık aralıklı parçalama verileri anahtar değeri aralıklarına göre dağıtır; bu durum yeni verilerin "sıcak" bir yığın halinde yoğunlaşmasına, ilgili parçada yüksek disk G/Ç yüküne ve kısa vadeli veri dengesizliğine neden olabilir.

Uygunsuz parça anahtarı alanı

Her parçadaki yığın sayısı benzer olsa da verilerin çoğu birkaç yığında yoğunlaşır. Sonuç olarak bu "sıcak" yığınları içeren parçalar diğerlerinden önemli ölçüde daha fazla veri depolar. sh.status() komutunu çalıştırdığınızda ve ApsaraDB for MongoDB çalışma zamanı günlüklerini kontrol ettiğinizde aşağıdakine benzer uyarı mesajları görebilirsiniz:

2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260000" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260200" } 
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260230" }

Mongos dengeleyicisi verilerin dengeli olup olmadığını belirlemek için öncelikli olarak her parçadaki yığın sayısını dikkate alır. Bu durum yığın sayılarının dengeli olduğu ancak gerçek veri dağılımının büyük ölçüde eğrildiği bir senaryoya yol açabilir. Bunun nedeni bir yığın içindeki parça anahtarı değerlerinin neredeyse aynı olmasıdır. Yığın 64 MB bölme eşiğine ulaştığında MongoDB onu böler ve boş bir yığın oluşturur. Zamanla yığın sayıları artsa ve taşıma işlemleri gerçekleşse de taşınan yığınlar genellikle boştur; bu da dengeli yığın sayılarına ancak dengesiz verilere neden olur. Bunu düzeltmek için parça anahtarı olarak yüksek kardinaliteli bir alan kullanacak şekilde parçalama stratejinizi yeniden tasarlayın.

Parçalanmış kümedeki parçalanmamış veritabanları

ApsaraDB for MongoDB parçalanmış küme örneği hem parçalanmış hem de parçalanmamış veritabanlarını destekler. Parçalanmamış bir veritabanından gelen tüm veriler tek bir birincil parçada bulunur; bu nedenle bu veritabanı büyükse birincil parçası diğer parçalardan önemli ölçüde daha fazla veri depolayabilir.

Bu sorun verileri bir kaynak mongos kümesinden yeni bir kümeye aktarırken ancak aktarmadan önce hedef kümede parçalamayı yapılandırmayı ihmal ettiğinizde de ortaya çıkabilir.

Bu sorunları gidermek için aşağıdakileri öneririz:

• Bir aktarma ile hedef kümeyi başlatıyorsanız parçalamayı başlamadan önce tasarlayın ve etkinleştirin.

• Yaklaşık olarak eşit boyutta çok sayıda parçalanmamış veritabanınız varsa belirli veritabanlarını farklı parçalara taşımak için movePrimary komutunu kullanın.

• Çok büyük bir parçalanmamış veritabanı varsa bunu parçalamanızı veya bağımsız bir çoğaltma kümesi örneğine geçirmenizi öneririz.

• Bu durum oluşursa ve yeterli disk alanınız varsa sorunu yok saymayı seçebilirsiniz.

moveChunk işlemlerinden kaynaklanan eşit olmayan disk kullanımı

Bir moveChunk işlemi verileri hedef parçaya yazar ve ardından bunları kaynak parçadan kaldırır. Varsayılan olarak kaldırma işlemi disk alanını serbest bırakmaz. WiredTiger altyapısında her koleksiyonun ayrı veri ve dizin dosyaları vardır ve bu dosyalar silinmediği sürece toplam disk alanı küçülmez. Bu sorun en sık bir süre parçalama tasarımı olmadan çalışan bir kümede parçalama etkinleştirildiğinde ortaya çıkar.

Bu nedenle çok sayıda moveChunk veya belge kaldırma işleminden sonra parçalanmış alanı geri kazanmak için etkilenen parçada bir compact işlemi çalıştırın.