ApsaraDB for MongoDB:Reclaim disk fragments untuk membebaskan ruang disk

Situasi apa yang sedang Anda alami?

Gunakan tabel berikut untuk mengidentifikasi situasi Anda dengan cepat dan menuju ke bagian yang relevan:

Kondisi dan aturan pemicu

Sistem secara otomatis mereclaim fragment hanya dari koleksi yang secara bersamaan memenuhi kondisi berikut:

• Ukuran gabungan ruang indeks dan ruang data melebihi 1 GB.

• Tingkat fragmentasi melebihi 20%.

Aturan tambahan:

• Batas atas untuk satu putaran reclaim adalah 100 GB. Kelebihannya akan direclaim dalam putaran berikutnya.

• Hanya node Hidden yang direclaim. Node Hidden tidak melayani traffic bisnis, sehingga reclaim tidak memengaruhi node Primary atau Secondary.

• Ambang batas di atas sudah tertanam dalam sistem dan tidak dapat dikustomisasi.

Titik masuk konfigurasi

1. Login ke Konsol MongoDB dan navigasi ke instans target.

2. Di panel navigasi kiri, pilih CloudDBA > Storage Analysis.

3. Di daftar Data Space, temukan kolom Fragmentation Rate dan klik tautan Recycle.

4. Pada kotak dialog Fragment Recycling Plan yang muncul, klik Create Plan dan konfirmasi.

Prosedur

1. Navigasi ke instans target. Di panel navigasi kiri, pilih CloudDBA > Storage Analysis.

2. Di daftar Data Space, lihat tingkat fragmentasi dan ruang yang dapat direclaim untuk setiap koleksi.

   Penting

   Operasi reclaim di analisis penyimpanan konsol, serta tingkat fragmentasi dan ruang yang dapat direclaim yang ditampilkan di halaman, secara default menargetkan node Hidden.

3. Untuk koleksi dengan tingkat fragmentasi tinggi yang ingin Anda reclaim, klik tombol Recycle yang sesuai untuk mengeksekusi.

Verifikasi keberhasilan reclaim

Setelah reclaim selesai, jalankan analisis penyimpanan lagi dan periksa apakah tingkat fragmentasi koleksi target telah menurun. Pastikan Anda melihat node yang sama tempat reclaim dilakukan (lihat FAQ dan troubleshooting).

Persyaratan izin

Menjalankan compact memerlukan akun memiliki izin dbAdmin atau hostManager (versi > 8.0). Jika tidak, kesalahan izin akan dilaporkan:

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

Dampak compact pada beban kerja

• Pemblokiran read/write dan dampak performa

  • Sebelum MongoDB 4.4: Perintah compact mengunci database yang berisi koleksi tersebut, memblokir semua operasi read dan write pada database tersebut. Ketika fragmentasi parah, compact mungkin memerlukan waktu lama untuk diselesaikan, yang dapat menyebabkan lag replikasi pada node Hidden. Kami menyarankan menjalankannya selama jam sepi, meningkatkan ukuran oplog berdasarkan workload write Anda, atau Upgrade versi utama database meningkatkan ke MongoDB 4.4 atau lebih baru sebelum melakukan reclaim fragment.

  • MongoDB 4.4 dan lebih baru: Perintah compact tidak lagi memblokir operasi read dan write, tetapi mungkin memengaruhi performa selama eksekusi. Kami menyarankan menjalankannya selama jam sepi.

• Pembangunan ulang node

  • MongoDB 3.4 (semua versi), MongoDB 4.0 (semua versi), MongoDB 4.2 versi minor awal (4.0.22 atau lebih lama), dan MongoDB 4.4 versi minor awal (5.0.6 atau lebih lama): Node yang menjalankan compact memasuki status RECOVERING. Jika status ini berlangsung terlalu lama, komponen pemeriksaan kesehatan mungkin menandai node sebagai tidak sehat dan memicu pembangunan ulang otomatis. Untuk informasi versi MongoDB, lihat Versi minor MongoDB.

  • Untuk instans yang menjalankan versi lebih baru: Node yang mengeksekusi compact tetap dalam status SECONDARY dan tidak memicu pembangunan ulang.

• Terlepas dari versinya, selalu prioritaskan reclaim fragment dari node Hidden atau Secondary untuk menghindari dampak pada node primary. Sebelum reclaim disk fragments, kami menyarankan membuat backup database Anda.

Waktu eksekusi compact

Waktu eksekusi bergantung pada volume data, beban sistem, dan faktor lainnya, dan tidak dapat diperkirakan secara tepat. Koleksi yang lebih besar dengan fragmentasi lebih banyak memerlukan waktu lebih lama. Koleksi yang sangat besar (ratusan GB) mungkin memerlukan waktu jauh lebih lama. Kami menyarankan menggunakan dryRun: true untuk memperkirakan ruang yang dapat direclaim terlebih dahulu, dan menjalankan operasi selama jam sepi.

Data berikut hanya disediakan sebagai referensi:

Uji dunia nyata (MongoDB 4.4): Menjalankan compact pada koleksi sekitar 2,5 GB dengan fragmentasi 50% memakan waktu sekitar 5 detik dan membebaskan sekitar 1,9 GB ruang.

Skenario di mana compact tidak efektif

Skenario berikut mungkin menyebabkan perintah compact tidak berpengaruh:

• Ukuran koleksi fisik kurang dari 1 MB.

• Tingkat fragmentasi di bawah 20%.

• Kurang dari 20% ruang bebas ada di 80% pertama file, atau kurang dari 10% ruang bebas ada di 90% pertama file.

Untuk informasi lebih lanjut, lihat block_compact.

Instans replica set

Hubungkan ke node Secondary dan jalankan perintah berikut:

use <database>

// Sebelum reclaim: periksa penggunaan ruang database untuk perbandingan
db.stats()

// Dry run: perkirakan ruang yang dapat direclaim tanpa benar-benar reclaim
db.runCommand({ compact: "<koleksi>", dryRun: true })

// Reclaim aktual
db.runCommand({ compact: "<koleksi>" })

// Setelah reclaim: periksa lagi untuk membandingkan ruang
db.stats()

Parameter dryRun: true mengaktifkan mode dry run, yang hanya mengembalikan estimatedBytesFreed (perkiraan jumlah byte yang dapat dibebaskan) tanpa memodifikasi file apa pun. Setelah meninjau hasil dry run, hapus parameter ini dan jalankan reclaim aktual. Jalankan db.stats() sebelum dan sesudah reclaim untuk membandingkan penggunaan ruang database dan mengonfirmasi hasilnya.

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

Instans kluster sharded

Untuk kluster sharded, Anda hanya perlu reclaim fragment dari node yang sesuai dalam komponen Shard. Komponen Mongos dan ConfigServer tidak menyimpan data pengguna dan tidak memerlukan reclaim.

Node read-only dalam kluster sharded tidak mendukung perintah compact, sehingga Anda tidak dapat reclaim fragment dari node read-only (ReadOnly).

Reclaim fragment node Secondary: Saat menjalankan runCommandOnShard, Anda harus mengatur preferensi baca ke Secondary. Sintaksnya bervariasi tergantung klien. Pilih metode yang sesuai untuk klien Anda:

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

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

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

Mengambil kembali fragmen node utama (tidak disarankan):

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

Reclaim dijalankan tetapi tidak ada efek yang terlihat

Periksa hal berikut secara berurutan:

1. Ketidaksesuaian node antara operasi dan verifikasi (penyebab paling umum): Analisis penyimpanan konsol mereclaim fragment dari node Hidden, dan halaman menampilkan tingkat fragmentasi untuk node Hidden secara default. Compact melalui command line memengaruhi node tempat Anda terhubung. Jika Anda menjalankan compact pada node primary atau secondary tetapi memeriksa tingkat fragmentasi di analisis penyimpanan konsol, angkanya tidak akan berubah. Pendekatan yang benar: Buka halaman Monitoring Information dan beralih ke node tempat Anda benar-benar melakukan operasi untuk melihat utilisasi ruang disk.

2. Fragmentasi file internal: compact hanya dapat memotong ruang bebas kontigu di akhir file. Ruang yang dapat digunakan kembali di dalam file tidak dapat direclaim. Jika fragment tersebar di dalam file, ruang disk mungkin tetap hampir tidak berubah setelah compact. Ini adalah perilaku yang diharapkan dari mesin penyimpanan WiredTiger, bukan kegagalan. Jalankan db.<koleksi>.stats() dan periksa rasio freeStorageSize terhadap storageSize untuk memperkirakan ruang yang dapat direclaim.

3. Di bawah ambang batas reclaim: Jika tingkat fragmentasi di bawah 20%, ukuran koleksi fisik kurang dari 1 MB, atau koleksinya kecil, ruang absolut yang dapat direclaim sangat kecil dan reclaim mungkin tidak menunjukkan efek yang terlihat.

4. Proteksi node primary memblokir operasi: Jika Anda melihat use force:true to force, ini adalah mekanisme proteksi yang menunjukkan bahwa compact dijalankan pada node primary. Jangan gunakan force. Sebagai gantinya, jalankan compact pada node Hidden atau Secondary, atau gunakan analisis penyimpanan konsol untuk reclaim node Hidden.

Mengapa tingkat fragmentasi tidak turun ke 0%?

Ini adalah perilaku yang diharapkan. compact hanya mereclaim ruang bebas kontigu di akhir file. Ruang yang dapat digunakan kembali di dalam file dipertahankan untuk penulisan di masa depan. Oleh karena itu, tingkat fragmentasi biasanya tidak dapat turun ke 0%. Ini adalah pilihan desain dari mesin penyimpanan WiredTiger.

Kesalahan: Tidak Diotorisasi

Menjalankan compact memerlukan izin dbAdmin atau hostManager (versi > 8.0). Jika tidak, kesalahan izin akan dilaporkan. Lihat Persyaratan izin.

Kesalahan: Interrupted ... cache eviction pressure

Penyebab: Selama eksekusi compact, mesin penyimpanan WiredTiger mengalami tekanan eviksi cache. Versi lama dan instans spesifikasi kecil memiliki sumber daya memori terbatas. Ketika tekanan cache terlalu tinggi dan mesin tidak dapat mengevakuasi halaman tepat waktu, compact diinterupsi dan keluar lebih awal.

Resolusi: Coba lagi selama jam sepi, picu failover primary/secondary dan coba lagi, atau tingkatkan spesifikasi instans sebelum reclaim.

Dapatkah saya menjalankan compact saat instans terkunci karena disk penuh?

Ya. Ketika disk penuh, instans memasuki status terkunci. Operasi write (insert) dan delete (delete) ditolak dengan kesalahan cloud instance error, disk locked..., tetapi operasi find, compact, dan drop masih dapat dieksekusi.

Keputusan pemulihan tercepat

Utilisasi konsol tidak sesuai dengan alert (misalnya, konsol menunjukkan 60% tetapi alert dipicu pada 90%)

Ini disebabkan oleh dimensi tampilan yang berbeda, bukan kesalahan data:

• Alert dipicu berdasarkan "node tunggal tertinggi": Dalam replica set, utilisasi disk node Primary, Secondary, dan Hidden mungkin berbeda (node Secondary/Hidden sering lebih tinggi daripada Primary karena oplog, waktu reclaim, file sementara, dan alasan lainnya). Alert dipicu ketika node tunggal melebihi ambang batas.

• Konsol tidak menampilkan "node tertinggi" secara default: Halaman Basic Information instans menunjukkan nilai agregat, dan halaman Storage Analysis secara default menampilkan node Hidden. Keduanya mungkin lebih rendah daripada node yang memicu alert.

Cara melihat penggunaan aktual setiap node: Buka halaman Monitoring Information instans, ubah mode tampilan ke Sub-node independent, lalu Anda dapat melihat penggunaan ruang disk masing-masing node Primary dan Secondary secara individual untuk mengidentifikasi node dengan penggunaan tinggi yang memicu peringatan.

Untuk informasi lebih lanjut tentang mengapa utilisasi disk node primary dan secondary berbeda dan cara mengatasinya, lihat Utilisasi ruang disk tinggi pada instans ApsaraDB for MongoDB.

Dapatkah saya mengecilkan disk untuk menghemat uang?

Pengecilan tidak didukung. ApsaraDB for MongoDB tidak mendukung pengurangan ruang disk yang telah dibeli untuk versi apa pun. Bahkan jika Anda telah membersihkan sejumlah besar data dan mereclaim fragment, Anda hanya dapat mempertahankan atau meningkatkan spesifikasi disk. Anda tidak dapat langsung menguranginya.

Jika Anda memerlukan spesifikasi disk yang lebih kecil, satu-satunya pilihan adalah membuat instans baru dengan spesifikasi lebih kecil, migrasi data Anda menggunakan DTS, lalu lepaskan instans asli. Evaluasi biaya migrasi dan jendela downtime sebelum melanjutkan.

Untuk perubahan konfigurasi dan batasan spesifikasi, lihat Ubah konfigurasi instans replica set.

Mengapa disk fragments terjadi?

Ketika data dihapus menggunakan perintah delete atau kedaluwarsa TTL, data tersebut hanya ditandai sebagai dihapus. Ruang yang ditempatinya tidak segera dikembalikan ke sistem operasi. Sebaliknya, ruang tersebut dipertahankan sebagai blok bebas untuk penulisan di masa depan. Ketika penghapusan melebihi penulisan, blok bebas ini tetap tidak digunakan dalam periode panjang, membentuk fragment. Inilah mengapa utilisasi disk tetap tinggi meskipun volume data berkurang.

Kapan harus reclaim disk fragments

Pertimbangkan untuk mengambil kembali fragmen disk dalam situasi berikut:

• Setelah menghapus volume data besar: Ketika Anda menghapus sejumlah besar dokumen, ruang yang dibebaskan tidak dikembalikan ke sistem operasi tetapi disimpan untuk penulisan di masa depan, meninggalkan ruang fragmentasi signifikan pada disk.

  Penting

  Penghapusan manual (delete) dan kedaluwarsa TTL tidak secara otomatis reclaim disk fragments. Reclaim manual diperlukan.

• Setelah workload write tinggi berkepanjangan: Workload write tinggi berkelanjutan (sering melakukan insert, update, dan delete) secara bertahap mengakumulasi ruang fragmentasi pada disk.

• Ketika ruang disk rendah dan fragmentasi melebihi 20%: Ketika utilisasi disk mencapai 85% hingga 90% atau lebih tinggi, reclaim fragment dapat membebaskan ruang dan mengurangi tekanan penyimpanan.

Lihat dan perkirakan ruang yang dapat direclaim

Hubungkan ke instans (untuk instans replica set, hubungkan ke node Secondary untuk meminimalkan dampak layanan) dan jalankan db.runCommand({collStats: "<koleksi>"}) untuk melihat status penyimpanan koleksi. Perhatikan bidang berikut:

• size: Ukuran penyimpanan logis koleksi.

• storageSize: Ukuran penyimpanan fisik koleksi.

• freeStorageSize: Ruang bebas yang dapat direclaim dalam koleksi (tersedia di MongoDB 4.4 dan lebih baru).

Setelah menghapus dokumen dengan perintah remove, size berkurang, tetapi storageSize mungkin tidak berubah. Rasio freeStorageSize terhadap storageSize yang lebih tinggi menunjukkan tingkat fragmentasi lebih tinggi.

Anda juga dapat menjalankan perintah berikut untuk memperkirakan ruang fragment yang dapat direclaim dari koleksi (mengembalikan jumlah byte yang dapat digunakan kembali):

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