Kompak koleksi untuk mereklaim ruang disk dari fragmentasi - ApsaraDB for MongoDB

Seiring waktu, operasi database seperti penyisipan, pembaruan, dan penghapusan data menyebabkan fragmentasi disk, sehingga mengurangi pemanfaatan disk secara efektif. Perintah compact berupaya melepaskan ruang disk yang tidak diperlukan kembali ke sistem operasi. Topik ini menjelaskan cara mereklaim ruang disk dan meningkatkan efisiensi penyimpanan.

Disarankan: Gunakan fitur Storage Analysis berbasis konsol untuk operasi yang lebih sederhana dan dampak bisnis yang lebih rendah.

Storage Analysis hanya mereklaim fragmentasi pada anggota Hidden. Untuk melakukan compact pada node Primary atau Secondary, lakukan terlebih dahulu failover agar mengubahnya menjadi anggota Hidden.

Storage Analysis memerlukan MongoDB 4.2 (≥4.0.23), MongoDB 4.4 (≥5.0.7), atau MongoDB 5.0 ke atas.

Jika Anda memerlukan kendali manual atau compact langsung pada node Primary/Secondary, gunakan perintah compact seperti dijelaskan di bawah.

Sebelum memulai

Instans Anda harus menggunakan mesin penyimpanan WiredTiger.
Backup data Anda sebelum menjalankan compact.

Kapan harus menjalankan compact

Operasi database menyebabkan fragmentasi disk seiring waktu, sehingga mengurangi pemanfaatan yang efektif. Jalankan compact dalam skenario berikut:

Setelah penghapusan data massal

Saat Anda menghapus data dalam jumlah besar, ruang disk tetap dicadangkan untuk penulisan di masa depan. Hal ini menciptakan ruang terfragmentasi yang tidak terpakai.

Penting

Baik penghapusan manual maupun kedaluwarsa TTL otomatis tidak memicu compact. Anda harus mereklaim ruang disk secara manual.

Beban kerja write tinggi yang berjalan lama

Operasi insert, update, dan delete yang sering menyebabkan akumulasi ruang terfragmentasi seiring waktu.

Keterbatasan ruang disk dengan fragmentasi >20%

Saat pemanfaatan disk mencapai 85–90% dan fragmentasi melebihi 20%, menjalankan compact mengurangi penggunaan disk.

Panduan cepat: Compact sebuah collection

Bagian ini menyediakan cara tercepat untuk melepaskan ruang disk.

Penting

Untuk instans replica set dan sharded cluster, jalankan compact pada node Secondary untuk meminimalkan dampak bisnis. Untuk alur kerja lengkap, lihat Compact primary/secondary nodes.

Langkah 1: Hubungkan ke instans Anda

Hubungkan menggunakan Mongo Shell:

Standalone Instance
Replica Set Instance (hubungkan ke node Secondary untuk meminimalkan dampak)
Sharded Cluster Instance

Langkah 2: Beralih ke database target

use <database_name>

Jalankan show dbs untuk melihat daftar database.

Langkah 3: Jalankan perintah compact

Sebelum dan sesudah menjalankan compact, Anda dapat menjalankan db.runCommand({collStats: "<collection_name>"}) di database target untuk memvalidasi efek compact.

Replica set & Standalone

db.runCommand({compact:"<collection_name>"})

Jalankan show tables untuk melihat daftar collection.

Catatan

Untuk node Primary MongoDB 4.2 atau versi sebelumnya, tambahkan force:true:

db.runCommand({compact:"<collection_name>",force:true})

Eksekusi berhasil mengembalikan:

{ "ok" : 1 }

Sharded cluster

Contoh berikut menggunakan sintaksis mongo shell. Untuk sintaksis mongosh 1.x dan 2.x, lihat Compact primary/secondary nodes.

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

Parameter:

<Shard ID>: Lihat di Konsol MongoDB > Instans Basic Information > Shard List.
<collection_name>: Nama collection.
$readPreference: {mode: 'secondary'}: Mengarahkan operasi compact ke node Secondary untuk menghindari dampak pada node Primary.

Eksekusi berhasil mengembalikan:

{ "ok" : 1 }

Lihat ruang penyimpanan disk

Periksa ukuran penyimpanan dan laju fragmentasi

Untuk mengevaluasi apakah Anda perlu menjalankan compact dan memverifikasi efeknya, jalankan perintah berikut sebelum dan sesudah compact di database yang berisi collection tersebut:

db.runCommand({collStats: <collection_name>})

Bidang utama:

size: Ukuran total data tak terkompresi dalam collection.
storageSize: Total ruang disk yang dialokasikan untuk collection.
freeStorageSize: Jumlah ruang penyimpanan yang dapat direklaim (tersedia di MongoDB 4.4+).

Laju fragmentasi = freeStorageSize / storageSize

Rasio tinggi menunjukkan fragmentasi tinggi.

Catatan

Untuk detail lebih lanjut, lihat collStats Output.

Perkirakan ruang yang dapat direklaim

Beralih ke database yang berisi collection tersebut, lalu jalankan:

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

Contoh:

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

Contoh output:

207806464

Hal ini menunjukkan sekitar 207.806.464 byte (~198 MB) dapat direklaim.

Compact primary/secondary nodes

Replica set & Standalone

Instans standalone memiliki satu node Primary. Jalankan compact langsung pada node Primary selama jam sepi.

Instans replica set memiliki node Primary, Secondary, dan opsional ReadOnly. Anda harus menjalankan compact pada semua node Primary dan Secondary. Jika terdapat node ReadOnly, compact juga menggunakan perintah yang sama.

Untuk meminimalkan dampak bisnis, ikuti alur kerja maintenance rolling yang disarankan di bawah:

Alur kerja yang disarankan:

Compact node Secondary terlebih dahulu.
Lakukan failover untuk mengalihkan Primary ke Secondary.
Memadatkan Secondary yang baru (sebelumnya merupakan Primary).
Compact node ReadOnly jika ada.

Perintah ringkas:

db.runCommand({compact:"<collection_name>"})

Untuk node Primary MongoDB 4.2 atau versi sebelumnya dalam replica set: db.runCommand({compact:"<collection_name>",force:true})

Contoh:

db.runCommand({compact:"orders"})

Sharded cluster

Untuk kluster sharded, jalankan compact hanya pada node Shard, karena mongos dan config server tidak menyimpan data pengguna.

Node ReadOnly dalam kluster sharded tidak mendukung compact.

Untuk mengurangi dampak bisnis, ikuti alur kerja di bawah ini daripada melakukan compact langsung pada node Primary.

Alur kerja yang disarankan:

Compact node Secondary di setiap Shard terlebih dahulu.
Lakukan failover untuk setiap Shard.
Compact node Secondary baru (mantan Primary).

Compact node Secondary:

mongosh 2.x

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

mongosh 1.x

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

mongo shell

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

Parameter:

<Shard ID>: Lihat di MongoDB console > instans Basic Information > Shard List.
<collection_name>: Nama collection.
$readPreference: {mode: 'secondary'}: Mengarahkan operasi compact ke node Secondary untuk menghindari dampak pada node Primary.

Compact Primary Node (Tidak Direkomendasikan):

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

Catatan

Parameter force wajib digunakan untuk MongoDB 4.2 atau versi sebelumnya.

Pertimbangan penting

Dampak performa

Versi MongoDB sebelum 4.4

compact mengunci seluruh database.
Semua operasi baca dan tulis diblokir selama eksekusi.
Fragmentasi ekstensif dapat menyebabkan waktu eksekusi lama dan lag replikasi signifikan pada node Hidden.
Saran: Jalankan selama jam sepi, sesuaikan ukuran Oplog, atau upgrade ke MongoDB 4.4+.

MongoDB 4.4 dan versi setelahnya

compact tidak memblokir operasi baca/tulis.
Performa mungkin terpengaruh selama eksekusi.
Saran: Jalankan selama jam sepi.

Risiko rebuild node

Versi berikut ini dapat memicu rebuild node otomatis:

Versi	Risiko
MongoDB 3.4 (semua)	Node masuk ke status RECOVERING, dapat memicu rebuild jika durasi melebihi ambang batas pemeriksaan kesehatan.
MongoDB 4.0 (semua)	Sama seperti di atas.
MongoDB 4.2 (≤4.0.22)	Sama seperti di atas.
MongoDB 4.4 (≤5.0.6)	Sama seperti di atas.

Versi setelahnya: Node tetap dalam status SECONDARY dan tidak memicu rebuild.

Untuk detail versi, lihat catatan rilis versi minor MongoDB.

Kondisi saat compact tidak efektif

Perintah compact tidak berpengaruh ketika:

Ukuran fisik collection < 1 MB.
Laju fragmentasi < 20%.
80% pertama file: ruang tersedia < 20%.
90% pertama file: ruang tersedia < 10%.

Referensi: WiredTiger block_compact.c#L140.

Pertimbangan lainnya

Durasi eksekusi: Bergantung pada volume data dan beban kerja sistem.
Pelepasan ruang: Ruang yang dilepaskan mungkin kurang dari ruang yang tersedia. Pastikan compact sebelumnya telah selesai sebelum menjalankan yang berikutnya.
Skema disk penuh: compact dapat dieksekusi bahkan saat disk penuh dan instans terkunci.

Pemecahan masalah

Error: "Compaction interrupted due to cache eviction pressure"

Penyebab: Instans spesifikasi kecil pada versi lama dapat membatalkan compact karena tekanan cache.

Solusi: Jalankan operasi tersebut selama jam sepi saat beban sistem lebih rendah.

Dokumentasi terkait

Storage Analysis - Fitur compact berbasis konsol
Catatan rilis versi minor MongoDB
Konfigurasikan failover node untuk instans replica set
Konfigurasikan alih bencana primary/secondary untuk instans sharded cluster

Lampiran: Memahami fragmentasi disk

Cara terjadinya fragmentasi

Saat Anda menghapus data dari instans ApsaraDB for MongoDB, ruang penyimpanan yang digunakan oleh data tersebut ditandai sebagai tersedia untuk digunakan kembali. Data baru dapat:

Disimpan langsung di ruang yang tersedia
Disimpan di akhir file setelah memperluas ukuran file

Hal ini menghasilkan ruang tersedia yang tidak terpakai tersebar di seluruh file—ini adalah fragmentasi disk.

Dampak fragmentasi

Fragmentasi yang lebih tinggi mengurangi pemanfaatan disk secara efektif.

Contoh:

Ukuran disk: 100 GB
Ruang terfragmentasi: 20 GB
Data bisnis: 60 GB
Pemanfaatan disk yang dilaporkan: 80% (60 GB + 20 GB)
Pemanfaatan disk efektif: 60% (hanya data bisnis)

Ruang 20 GB yang terfragmentasi dihitung sebagai "terpakai" tetapi tidak berisi data.

Referensi perintah

Untuk dokumentasi lengkap perintah compact, lihat: