Mengurangi ukuran file database MongoDB

Saya punya database MongoDB yang dulunya besar (> 3GB). Sejak itu, dokumen telah dihapus dan saya mengharapkan ukuran file database berkurang.

Tapi karena MongoDB terus mengalokasikan ruang, file-nya masih besar.

Saya membaca di sini dan di sana bahwa perintah admin mongod --repairdigunakan untuk membebaskan ruang yang tidak digunakan, tetapi saya tidak memiliki cukup ruang pada disk untuk menjalankan perintah ini.

Apakah Anda tahu cara saya bisa membebaskan ruang yang tidak digunakan?

UPDATE: dengan compactperintah dan WiredTiger sepertinya ruang disk tambahan benar-benar akan dirilis ke OS .

UPDATE: pada v1.9 + ada compactperintah.

Perintah ini akan melakukan pemadatan "in-line". Masih membutuhkan ruang ekstra, tetapi tidak sebanyak itu.

MongoDB mengkompres file dengan:

• menyalin file ke lokasi baru
• mengulangi dokumen dan memesan ulang / memecahkannya
• mengganti file asli dengan file baru

Anda dapat melakukan ini "kompresi" dengan menjalankan mongod --repairatau dengan menghubungkan langsung dan berjalan db.repairDatabase().

Dalam kedua kasus Anda membutuhkan ruang di suatu tempat untuk menyalin file. Sekarang saya tidak tahu mengapa Anda tidak memiliki cukup ruang untuk melakukan kompres, namun, Anda memiliki beberapa opsi jika Anda memiliki komputer lain dengan lebih banyak ruang.

1. Ekspor database ke komputer lain dengan Mongo diinstal (menggunakan mongoexport) dan kemudian Anda dapat mengimpor database yang sama (menggunakan mongoimport). Ini akan menghasilkan database baru yang lebih terkompresi. Sekarang Anda dapat menghentikan mongodpenggantian yang asli dengan file database baru dan Anda siap melakukannya.
2. Hentikan mongod saat ini dan salin file database ke komputer yang lebih besar dan jalankan perbaikan di komputer itu. Anda kemudian dapat memindahkan file database baru kembali ke komputer asli.

Saat ini tidak ada cara yang baik untuk "kompak di tempat" menggunakan Mongo. Dan Mongo pasti bisa menyedot banyak ruang.

Strategi terbaik saat ini untuk pemadatan adalah dengan menjalankan pengaturan Master-Slave. Anda kemudian dapat memadatkan Slave, membiarkannya mengejar dan mengubahnya. Saya tahu masih sedikit berbulu. Mungkin tim Mongo akan tampil dengan pemadatan yang lebih baik, tapi saya pikir itu bukan yang terbaik dalam daftar mereka. Ruang drive saat ini dianggap murah (dan biasanya demikian).

Saya memiliki masalah yang sama, dan diselesaikan dengan hanya melakukan ini di baris perintah:

mongodump -d databasename
echo 'db.dropDatabase()' | mongo databasename
mongorestore dump/databasename

Sepertinya Mongo v1.9 + memiliki dukungan untuk compact di tempatnya!

> db.runCommand( { compact : 'mycollectionname' } )

Lihat dokumen di sini: http://docs.mongodb.org/manual/reference/command/compact/

"Tidak seperti repair Database, perintah kompak tidak memerlukan ruang disk ganda untuk melakukan tugasnya. Perintah ini membutuhkan sejumlah kecil ruang tambahan saat bekerja. Selain itu, compact lebih cepat."

Kompak semua koleksi dalam database saat ini

db.getCollectionNames().forEach(function (collectionName) {
    print('Compacting: ' + collectionName);
    db.runCommand({ compact: collectionName });
});

Jika Anda perlu menjalankan perbaikan penuh, gunakan repairpathopsi. Arahkan ke disk dengan lebih banyak ruang yang tersedia.

Misalnya, pada Mac saya, saya telah menggunakan:

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair

Pembaruan: Per MongoDB Core Server Ticket 4266 , Anda mungkin perlu menambahkan --nojournaluntuk menghindari kesalahan:

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair --nojournal

Mulai dengan versi 2.8 Mongo, Anda dapat menggunakan kompresi . Anda akan memiliki 3 level kompresi dengan mesin WiredTiger, mmap (yang defaultnya di 2.6 tidak memberikan kompresi):

• Tidak ada
• tajam (secara default)
• zlib

Berikut adalah contoh seberapa banyak ruang yang dapat Anda hemat untuk data 16 GB:

data diambil dari artikel ini .

Kita perlu memecahkan 2 cara, berdasarkan StorageEngine.

1. mesin MMAP ():

perintah: db.repairDatabase ()

CATATAN: repairDatabase membutuhkan ruang disk kosong sama dengan ukuran kumpulan data Anda saat ini ditambah 2 gigabyte. Jika volume yang menahan dbpath tidak memiliki ruang yang cukup, Anda dapat memasang volume terpisah dan menggunakannya untuk perbaikan. Saat memasang volume terpisah untuk repairDatabase Anda harus menjalankan repairDatabase dari baris perintah dan menggunakan --repairpath untuk menentukan folder tempat menyimpan file perbaikan sementara. misal: Imagine DB size artinya 120 GB, (120 * 2) +2 = 242 GB ruang Hard Disk diperlukan.

cara lain Anda melakukan pengumpulan bijaksana, perintah: db.runCommand ({compact: 'collectionName'})

2. WiredTiger: Secara otomatis diselesaikan sendiri.

Ada beberapa kebingungan yang cukup besar tentang reklamasi ruang di MongoDB, dan beberapa praktik yang disarankan benar-benar berbahaya untuk dilakukan dalam jenis penyebaran tertentu. Lebih detail di bawah ini:

TL; DR repairDatabase berupaya untuk menyelamatkan data dari penyebaran MongoDB mandiri yang mencoba untuk pulih dari kerusakan disk. Jika ruang pulih, itu murni efek samping . Memulihkan ruang seharusnya tidak menjadi pertimbangan utama untuk berlari repairDatabase.

Memulihkan ruang dalam node mandiri

WiredTiger: Untuk node mandiri dengan WiredTiger, menjalankan compactakan melepaskan ruang ke OS, dengan satu peringatan: compactPerintah pada WiredTiger di MongoDB 3.0.x dipengaruhi oleh bug ini: SERVER-21833 yang diperbaiki di MongoDB 3.2.3. Sebelum versi ini, compactpada WiredTiger bisa gagal secara diam-diam.

MMAPv1: Karena cara kerja MMAPv1, tidak ada metode yang aman dan didukung untuk memulihkan ruang menggunakan mesin penyimpanan MMAPv1. compactdi MMAPv1 akan mendefrag file data, berpotensi membuat lebih banyak ruang tersedia untuk dokumen baru, tetapi tidak akan melepaskan ruang kembali ke OS.

Anda mungkin dapat menjalankannya repairDatabasejika Anda sepenuhnya memahami konsekuensi dari perintah yang berpotensi berbahaya ini (lihat di bawah), karena repairDatabasepada dasarnya menulis ulang seluruh database dengan membuang dokumen yang rusak. Sebagai efek samping, ini akan membuat file data MMAPv1 baru tanpa ada fragmentasi dan melepaskan ruang kembali ke OS.

Untuk metode yang tidak terlalu berani, menjalankan mongodumpdan mongorestoredimungkinkan juga dalam penerapan MMAPv1, tergantung pada ukuran penerapan Anda.

Memulihkan ruang dalam set replika

Untuk konfigurasi set replika, metode terbaik dan teraman untuk memulihkan ruang adalah dengan melakukan sinkronisasi awal , untuk WiredTiger dan MMAPv1.

Jika Anda perlu memulihkan ruang dari semua node di set, Anda dapat melakukan sinkronisasi awal bergulir. Yaitu, lakukan sinkronisasi awal pada masing-masing sekunder, sebelum akhirnya mundur primer dan lakukan sinkronisasi awal di atasnya. Menggulir metode sinkronisasi awal adalah metode paling aman untuk melakukan pemeliharaan set replika, dan juga tidak melibatkan downtime sebagai bonus.

Harap dicatat bahwa kelayakan melakukan sinkronisasi awal bergulir juga tergantung pada ukuran penempatan Anda. Untuk penyebaran yang sangat besar, mungkin tidak layak untuk melakukan sinkronisasi awal, dan karenanya opsi Anda agak lebih terbatas. Jika WiredTiger digunakan, Anda mungkin dapat mengambil satu sekunder dari set, mulai sebagai standalone, jalankan compactdi atasnya, dan bergabung kembali ke set.

Mengenai repairDatabase

Tolong jangan dijalankan repairDatabasepada set node replika . Ini sangat berbahaya, seperti yang disebutkan dalam halaman database Repair dan dijelaskan lebih detail di bawah ini.

Namanya repairDatabaseagak menyesatkan, karena perintah tidak berusaha memperbaiki apa pun. Perintah itu dimaksudkan untuk digunakan ketika ada kerusakan disk pada node mandiri , yang dapat menyebabkan dokumen rusak.

The repairDatabaseperintah bisa lebih tepat disebut sebagai "basis data penyelamatan". Yaitu, ini membuat ulang basis data dengan membuang dokumen yang rusak dalam upaya untuk membuat basis data ke dalam keadaan di mana Anda dapat memulainya dan menyelamatkan dokumen yang utuh darinya.

Dalam penyebaran MMAPv1, pembangunan kembali file database melepaskan ruang ke OS sebagai efek samping . Melepaskan ruang ke OS tidak pernah tujuannya.

Konsekuensi repairDatabasepada set replika

Dalam set replika, MongoDB mengharapkan semua node di set untuk berisi data yang identik. Jika Anda menjalankan repairDatabasesimpul set replika, ada kemungkinan simpul tersebut berisi korupsi yang tidak terdeteksi, dan dengan repairDatabasepatuh akan menghapus dokumen yang rusak untuk Anda.

Bisa ditebak, ini membuat simpul yang berisi dataset berbeda dari sisa set. Jika pembaruan terjadi untuk mencapai satu dokumen itu, seluruh rangkaian dapat macet.

Untuk memperburuk keadaan, sangat mungkin bahwa situasi ini bisa tetap tidak aktif untuk waktu yang lama, hanya untuk menyerang tiba-tiba tanpa alasan yang jelas.

Jika sebagian besar data dihapus dari koleksi dan koleksi tidak pernah menggunakan ruang yang dihapus untuk dokumen baru, ruang ini perlu dikembalikan ke sistem operasi sehingga dapat digunakan oleh database atau koleksi lain. Anda perlu menjalankan operasi kompak atau perbaikan untuk mendefrag ruang disk dan mendapatkan kembali ruang kosong yang dapat digunakan.

Perilaku proses pemadatan tergantung pada mesin MongoDB sebagai berikut

db.runCommand({compact: collection-name })

MMAPv1

Operasi pemadatan defragment file data & indeks. Namun, itu tidak melepaskan ruang ke sistem operasi. Operasi ini masih berguna untuk mendefrag dan menciptakan ruang yang lebih berdekatan untuk digunakan kembali oleh MongoDB. Namun, tidak ada gunanya ketika ruang disk kosong sangat rendah.

Diperlukan ruang disk tambahan hingga 2GB selama operasi pemadatan.

Kunci tingkat basis data ditahan selama operasi pemadatan.

WiredTiger

Mesin WiredTiger menyediakan kompresi secara default yang menghabiskan lebih sedikit ruang disk daripada MMAPv1.

Proses ringkas melepaskan ruang kosong ke sistem operasi. Ruang disk minimal diperlukan untuk menjalankan operasi ringkas. WiredTiger juga memblokir semua operasi pada basis data karena memerlukan kunci tingkat basis data.

Untuk mesin MMAPv1 , compact doest tidak mengembalikan ruang ke sistem operasi. Anda harus menjalankan operasi perbaikan untuk melepaskan ruang yang tidak digunakan.

db.runCommand({repairDatabase: 1})

Mongodb 3.0 dan lebih tinggi memiliki mesin penyimpanan baru - WiredTiger. Dalam kasus saya beralih mesin mengurangi penggunaan disk dari 100 Gb menjadi 25Gb.

Ukuran file basis data tidak dapat dikurangi. Saat "memperbaiki" database, hanya dimungkinkan bagi server mongo untuk menghapus beberapa file-nya. Jika sejumlah besar data telah dihapus, server mongo akan "melepaskan" (menghapus), selama perbaikan, beberapa file yang ada.

Secara umum compact lebih baik daripada memperbaiki Database. Tetapi satu keuntungan dari perbaikan dibandingkan yang ringkas adalah Anda dapat mengeluarkan perbaikan ke seluruh kluster. kompak Anda harus masuk ke setiap beling, yang agak menjengkelkan.

Ketika saya memiliki masalah yang sama, saya menghentikan server mongo saya dan mulai lagi dengan perintah

mongod --repair

Sebelum menjalankan operasi perbaikan, Anda harus memeriksa apakah Anda memiliki cukup ruang kosong pada HDD Anda (min - adalah ukuran database Anda)

Untuk mode mandiri Anda dapat menggunakan compact atau perbaikan,

Untuk kumpulan sharded atau set replika, dalam pengalaman saya, setelah Anda menjalankan compact pada primer, diikuti oleh compact sekunder, ukuran basis data primer berkurang, tetapi bukan sekunder. Anda mungkin ingin melakukan resync member untuk mengurangi ukuran basis data sekunder. dan dengan melakukan ini, Anda mungkin menemukan bahwa ukuran database sekunder bahkan lebih berkurang daripada yang utama, saya kira perintah kompak tidak benar-benar memadatkan koleksi. Jadi, saya akhirnya beralih primer dan sekunder dari set replika dan melakukan resync anggota lagi.

kesimpulan saya adalah, cara terbaik untuk mengurangi ukuran set sharded / replika adalah dengan melakukan anggota sinkronisasi, beralih primer sekunder, dan menyinkronkan lagi.

mongoDB -perbaikan tidak disarankan dalam kasus cluster yang diarsir.

Jika menggunakan cluster sharded set replika, gunakan perintah kompak, itu akan menulis ulang dan mendefrag semua file data dan indeks semua koleksi. sintaksis:

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

bila digunakan dengan paksa: true, compact dijalankan berdasarkan set replika utama. misalnya db.runCommand ( { command : "collection_name", force : true } )

Poin lain yang perlu dipertimbangkan: -Memblokir operasi. sangat disarankan untuk dieksekusi di jendela maintenance. -Jika set replika berjalan pada server yang berbeda, perlu dieksekusi pada setiap anggota secara terpisah - Dalam kasus sharded cluster, kompak perlu dijalankan pada setiap anggota beling secara terpisah. Tidak dapat mengeksekusi terhadap instance mongo.

Hanya satu cara yang bisa saya lakukan. Tidak ada jaminan keamanan data Anda saat ini. Coba dengan risiko Anda sendiri.

Hapus file data secara langsung dan mulai ulang mongod.

Misalnya, dengan ubuntu (jalur default ke data: / var / lib / mongodb), saya memiliki beberapa file dengan nama seperti: koleksi. #. Saya menyimpan koleksi.0 dan menghapus yang lainnya.

Tampaknya cara yang lebih mudah jika Anda tidak memiliki data serius dalam database.