ApsaraDB for MongoDB:Disk alanını boşaltmak için disk parçalarını geri kazanın

Hangi durumla karşılaşıyorsunuz?

Durumunuzu hızlıca belirlemek ve ilgili bölüme gitmek için aşağıdaki tabloyu kullanın:

Tetikleme koşulları ve kurallar

Sistem, aşağıdaki koşulları aynı anda karşılayan koleksiyonlardan parçaları otomatik olarak geri alır:

• Dizin alanı ve veri alanının toplam boyutu 1 GB'yi aşar.

• Parçalanma oranı %20'nin üzerindedir.

Ek kurallar:

• Tek bir geri alma turu için üst sınır 100 GB'dir. Fazlası sonraki turlarda geri alınır.

• Yalnızca Gizli düğümler geri alınır. Gizli düğümler iş trafiğine hizmet etmez; bu nedenle geri alma birincil veya ikincil düğümleri etkilemez.

• Yukarıdaki eşikler sisteme dahildir ve özelleştirilemez.

Yapılandırma giriş noktası

1. MongoDB konsolu üzerinde oturum açın ve hedef örneğe gidin.

2. Sol gezinme bölmesinde CloudDBA > Storage Analysis seçeneğini belirleyin.

3. Data Space listesinde Fragmentation Rate sütununu bulun ve Recycle bağlantısına tıklayın.

4. Açılan Fragment Recycling Plan iletişim kutusunda Create Plan öğesine tıklayın ve onaylayın.

Prosedür

1. Hedef örneğe gidin. Sol gezinme bölmesinde CloudDBA > Storage Analysis seçeneğini belirleyin.

2. Data Space listesinde her koleksiyon için parçalanma oranını ve geri alınabilir alanı görüntüleyin.

   Önemli

   Konsol depolama analizindeki geri alma işlemleri ve sayfada görüntülenen parçalanma oranı ile geri alınabilir alan varsayılan olarak Gizli düğümleri hedefler.

3. Geri almak istediğiniz yüksek parçalanma oranına sahip koleksiyonlar için ilgili Recycle düğmesine tıklayarak çalıştırın.

Geri alma başarısını doğrulayın

Geri alma tamamlandıktan sonra depolama analizini tekrar çalıştırın ve hedef koleksiyonun parçalanma oranının azalıp azalmadığını kontrol edin. Geri almanın yapıldığı aynı düğümü görüntülediğinizden emin olun (bkz. SSS ve sorun giderme).

İzin gereksinimleri

Compact çalıştırmak için hesabın dbAdmin veya hostManager (sürüm > 8.0) izinlerine sahip olması gerekir. Aksi takdirde bir izin hatası bildirilir:

not authorized on <database> to execute command { compact: ... }

Compact'ın iş yüklerine etkisi

• Okuma/yazma engelleme ve performans etkisi

  • MongoDB 4.4 öncesi: compact komutu koleksiyonu içeren veritabanını kilitler ve bu veritabanındaki tüm okuma ve yazma işlemlerini engeller. Parçalanma şiddetli olduğunda compact tamamlanması uzun sürebilir ve bu da Gizli düğümlerde çoğaltma gecikmesine neden olabilir. Yoğun olmayan saatlerde çalıştırmanızı, yazma iş yükünüze göre oplog boyutunu artırmanızı veya parçaları geri almadan önce MongoDB 4.4 veya sonraki bir sürüme Veritabanı ana sürümünü yükseltin yükseltmenizi öneririz.

  • MongoDB 4.4 ve sonrası: compact komutu artık okuma ve yazma işlemlerini engellemez ancak yürütme sırasında performansı etkileyebilir. Yoğun olmayan saatlerde çalıştırmanızı öneririz.

• Düğüm yeniden oluşturma

  • MongoDB 3.4 (tüm sürümler), MongoDB 4.0 (tüm sürümler), MongoDB 4.2 erken alt sürümleri (4.0.22 veya öncesi) ve MongoDB 4.4 erken alt sürümleri (5.0.6 veya öncesi): compact çalıştıran düğüm RECOVERING durumuna girer. Bu durum çok uzun sürerse sağlık denetimi bileşeni düğümü sağlıksız olarak işaretleyebilir ve otomatik yeniden oluşturmaya neden olabilir. MongoDB sürüm bilgileri için bkz. MongoDB alt sürümleri.

  • Daha sonraki sürümleri çalıştıran örnekler için: compact yürüten düğüm SECONDARY durumunda kalır ve yeniden oluşturma tetiklemez.

• Sürümden bağımsız olarak birincil düğümü etkilememek için her zaman parçaları öncelikle Gizli veya İkincil düğümlerden geri almayı tercih edin. Disk parçalarını geri almadan önce veritabanınızı yedeklemenizi öneririz.

compact yürütme süresi

Yürütme süresi veri hacmine, sistem yüküne ve diğer faktörlere bağlıdır ve kesin olarak tahmin edilemez. Daha fazla parçalanmaya sahip daha büyük koleksiyonlar daha uzun sürer. Çok büyük koleksiyonlar (yüzlerce GB) önemli ölçüde daha uzun sürebilir. Önce geri alınabilir alanı tahmin etmek için dryRun: true kullanmanızı ve işlemi yoğun olmayan saatlerde çalıştırmanızı öneririz.

Aşağıdaki veriler yalnızca referans amaçlıdır:

Gerçek dünya testi (MongoDB 4.4): Yaklaşık %50 parçalanmaya sahip 2,5 GB'lık bir koleksiyonda compact çalıştırmak yaklaşık 5 saniye sürdü ve yaklaşık 1,9 GB alan boşalttı.

Compact'ın etkili olmadığı senaryolar

Aşağıdaki senaryolar compact komutunun etkisiz kalmasına neden olabilir:

• Fiziksel koleksiyon boyutu 1 MB'tan küçüktür.

• Parçalanma oranı %20'nin altındadır.

• Dosyanın ilk %80'inde %20'den az boş alan varsa veya dosyanın ilk %90'ında %10'dan az boş alan varsa.

Daha fazla bilgi için bkz. block_compact.

Çoğaltma kümesi örnekleri

Bir İkincil düğüme bağlanın ve aşağıdaki komutları çalıştırın:

use <database>

// Before reclamation: check database space usage for comparison
db.stats()

// Dry run: estimate reclaimable space without actually reclaiming
db.runCommand({ compact: "<collection>", dryRun: true })

// Actual reclamation
db.runCommand({ compact: "<collection>" })

// After reclamation: check again to compare space
db.stats()

dryRun: true parametresi herhangi bir dosyayı değiştirmeden yalnızca estimatedBytesFreed (boşaltılabilecek tahmini bayt sayısı) değerini döndüren kuru çalıştırma modunu etkinleştirir. Kuru çalıştırma sonuçlarını inceledikten sonra bu parametreyi kaldırın ve gerçek geri almayı çalıştırın. Veritabanı alanı kullanımını karşılaştırmak ve sonucu onaylamak için geri almadan önce ve sonra db.stats() çalıştırın.

will not run compact on an active replica set primary as this will slow down
other running operations. use force:true to force

Parçalı küme örnekleri

Parçalı kümeler için yalnızca Shard bileşenindeki karşılık gelen düğümlerden parçaları geri almanız gerekir. Mongos ve ConfigServer bileşenleri kullanıcı verisi depolamaz ve geri alma gerektirmez.

Parçalı kümelerdeki salt okunur düğümler compact komutunu desteklemez; bu nedenle salt okunur (ReadOnly) düğümlerden parçaları geri alamazsınız.

İkincil düğüm parçalarını geri alma: runCommandOnShard çalıştırırken okuma tercihini Secondary olarak ayarlamanız gerekir. Sözdizimi istemciye göre değişir. İstemciniz için uygun yöntemi seçin:

db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>"}},{readPreference: "secondary"})

db.getMongo().setReadPref('secondary')
db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>"}})

db.runCommand({runCommandOnShard:"<Shard ID>","command":{compact:"<collection_name>"},$queryOptions: {$readPreference: {mode: 'secondary'}}})

Birincil düğüm parçalarını geri alma (önerilmez):

db.adminCommand({
  runCommandOnShard: "<shardId>",
  dbName: "<database>",
  command: { compact: "<collection>", force: true }
})

Geri alma çalıştırıldı ancak görünür etki yok

Aşağıdakileri sırayla kontrol edin:

1. İşlem ve doğrulama arasında düğüm uyumsuzluğu (en yaygın neden): Konsol depolama analizi Gizli düğümlerden parçaları geri alır ve sayfa varsayılan olarak Gizli düğümler için parçalanma oranını görüntüler. Komut satırı compact bağlandığınız düğümü etkiler. Birincil veya ikincil düğümde compact çalıştırdıysanız ancak konsol depolama analizinde parçalanma oranını kontrol ettiyseniz sayılar değişmez. Doğru yaklaşım: Monitoring Information sayfasına gidin ve disk alanı kullanımını görüntülemek için işlemi gerçekten gerçekleştirdiğiniz düğüme geçin.

2. Dahili dosya parçalanması: compact yalnızca bir dosyanın sonundaki bitişik boş alanı kısaltabilir. Dosya içindeki yeniden kullanılabilir alan geri alınamaz. Parçalar dosya içinde dağılmışsa compact sonrasında disk alanı neredeyse değişmeden kalabilir. Bu WiredTiger depolama altyapısının beklenen davranışıdır bir arıza değildir. Geri alınabilir alanı tahmin etmek için db.<collection>.stats() çalıştırın ve freeStorageSize ile storageSize oranını kontrol edin.

3. Geri alma eşiğinin altında: Parçalanma oranı %20'nin altındaysa fiziksel koleksiyon boyutu 1 MB'tan küçükse veya koleksiyon küçükse mutlak geri alınabilir alan çok küçüktür ve geri almanın görünür bir etkisi olmayabilir.

4. Birincil düğüm koruması işlemi engelledi: use force:true to force görürseniz bu compact'ın birincil düğümde çalıştırıldığını belirten koruma mekanizmasıdır. Force kullanmayın. Bunun yerine compact'ı Gizli veya İkincil düğümde çalıştırın veya Gizli düğümleri geri almak için konsol depolama analizini kullanın.

Parçalanma oranı neden %0'a düşmüyor?

Bu beklenen bir davranıştır. compact yalnızca bir dosyanın sonundaki bitişik boş alanı geri alır. Dosya içindeki yeniden kullanılabilir alan gelecekteki yazmalar için korunur. Bu nedenle parçalanma oranı tipik olarak %0'a düşemez. Bu WiredTiger depolama altyapısının bir tasarım tercihidir.

Hata: not authorized / Yetkisiz

Compact çalıştırmak için dbAdmin veya hostManager (sürüm > 8.0) izinleri gerekir. Aksi takdirde bir izin hatası bildirilir. Bkz. İzin gereksinimleri.

Hata: Interrupted ... cache eviction pressure

Neden: Compact yürütme sırasında WiredTiger depolama altyapısı önbellek tahliye baskısı yaşar. Eski sürümler ve küçük teknik özelliklere sahip örneklerin bellek kaynakları sınırlıdır. Önbellek baskısı çok yüksek hale geldiğinde ve altyapı sayfaları zamanında tahliye edemediğinde compact kesintiye uğrar ve erken çıkar.

Çözüm: Yoğun olmayan saatlerde yeniden deneyin, bir birincil/ikincil yük devretme tetikleyip tekrar deneyin veya geri almadan önce örnek teknik özelliklerini yükseltin.

Disk doluluğu nedeniyle örnek kilitlendiğinde compact çalıştırabilir miyim?

Evet. Disk dolduğunda örnek kilitli duruma geçer. Yazma (insert) ve silme (delete) işlemleri cloud instance error, disk locked... hatasıyla reddedilir ancak find, compact ve drop işlemleri hala çalıştırılabilir.

En hızlı kurtarma kararı

Konsol kullanımı uyarılarla eşleşmiyor (örneğin, konsol %60 gösteriyor ancak uyarı %90'da tetikleniyor)

Bu bir veri hatası değil farklı görüntüleme boyutlarından kaynaklanır:

• Uyarılar "en yüksek tek düğüm" üzerinde tetiklenir: Bir çoğaltma kümesinde Birincil, İkincil ve Gizli düğümlerin disk kullanımı farklı olabilir (oplog, geri alma zamanlaması, geçici dosyalar ve diğer nedenlerle İkincil/Gizli düğümler genellikle Birincil'den daha yüksektir). Herhangi bir tek düğüm eşiği aştığında bir uyarı tetiklenir.

• Konsol varsayılan olarak "en yüksek düğümü" göstermez: Örnek Basic Information sayfası toplu bir değer gösterir ve Storage Analysis sayfası varsayılan olarak Gizli düğümü gösterir. Her ikisi de uyarıyı tetikleyen düğümden daha düşük olabilir.

Her düğümün gerçek kullanımını nasıl görüntülersiniz: Örnek Monitoring Information sayfasına gidin görüntüleme modunu Sub-node independent olarak değiştirin ve uyarıyı tetikleyen yüksek kullanıma sahip düğümü bulmak için her Birincil / İkincil düğümün disk alanı kullanımını ayrı ayrı görüntüleyebilirsiniz.

Birincil ve ikincil düğüm disk kullanımının neden farklı olduğu ve bunun nasıl ele alınacağı hakkında daha fazla bilgi için bkz. ApsaraDB for MongoDB örneklerinin yüksek disk alanı kullanımı.

Para tasarrufu yapmak için diski küçültebilir miyim?

Küçültme desteklenmez. ApsaraDB for MongoDB hiçbir sürüm için satın alınan disk alanının azaltılmasını desteklemez. Büyük miktarda veriyi temizleyip parçaları geri alsanız bile disk teknik özelliklerini yalnızca koruyabilir veya artırabilirsiniz. Doğrudan azaltamazsınız.

Daha küçük bir disk teknik özelliğine ihtiyacınız varsa tek seçenek daha küçük bir teknik özelliğe sahip yeni bir örnek oluşturmak verilerinizi DTS kullanarak geçirmek ve ardından orijinal örneği serbest bırakmaktır. Devam etmeden önce geçiş maliyetini ve kesinti süresi penceresini değerlendirin.

Yapılandırma değişikliği ve teknik özellik sınırları için bkz. Çoğaltma kümesi örneği yapılandırmasını değiştirin.

Disk parçaları neden oluşur?

delete komutu veya TTL süresi dolması kullanılarak veriler silindiğinde yalnızca silindi olarak işaretlenir. Kapladığı alan hemen işletim sistemine iade edilmez. Bunun yerine gelecekteki yazmalar için ücretsiz bloklar olarak saklanır. Silmeler yazmalardan daha hızlı olduğunda bu ücretsiz bloklar uzun süre kullanılmadan kalır ve parçalar oluşturur. Bu nedenle veri hacmi azalsa bile disk kullanımı yüksek kalır.

Disk parçaları ne zaman geri alınmalı

Aşağıdaki durumlarda disk parçalarını geri almayı düşünün:

• Büyük hacimli veri silindikten sonra: Çok sayıda belge sildiğinizde boşaltılan alan işletim sistemine iade edilmez gelecekteki yazmalar için ayrılır ve diskte önemli miktarda parçalanmış alan bırakır.

  Önemli

  Manuel silme (delete) ve TTL süresi dolması disk parçalarını otomatik olarak geri almaz. Manuel geri alma gerekir.

• Uzun süreli yüksek yazma iş yüklerinden sonra: Sürekli yüksek yazma iş yükleri (sık inserts, updates ve deletes) diskte yavaş yavaş parçalanmış alan biriktirir.

• Disk alanı düşük ve parçalanma %20'yi aştığında: Disk kullanımı %85 ila %90 veya daha yüksek seviyelere ulaştığında parçaları geri almak alanı boşaltabilir ve depolama baskısını azaltabilir.

Geri alınabilir alanı görüntüleme ve tahmin etme

Örneğe bağlanın (çoğaltma kümesi örnekleri için hizmet etkisini en aza indirmek amacıyla bir İkincil düğüme bağlanın) ve bir koleksiyonun depolama durumunu görüntülemek için db.runCommand({collStats: "<collection>"}) çalıştırın. Aşağıdaki alanlara dikkat edin:

• size: Koleksiyonun mantıksal depolama boyutu.

• storageSize: Koleksiyonun fiziksel depolama boyutu.

• freeStorageSize: Koleksiyon içindeki geri alınabilir boş alan (MongoDB 4.4 ve sonraki sürümlerde mevcuttur).

remove komutuyla belgeleri sildikten sonra size azalır ancak storageSize değişmeyebilir. freeStorageSize ile storageSize oranının daha yüksek olması daha yüksek bir parçalanma oranını gösterir.

Ayrıca bir koleksiyonun geri alınabilir parça alanını tahmin etmek için aşağıdaki komutu çalıştırabilirsiniz (yeniden kullanılabilir bayt sayısını döndürür):

db.<collection>.stats().wiredTiger["block-manager"]["file bytes available for reuse"]