Зменшення розміру файлу бази даних MongoDB

У мене колись велика база даних MongoDB (> 3 ГБ). З того часу документи видалено, і я очікував, що розмір файлів бази даних зменшиться відповідно.

Але оскільки MongoDB зберігає виділений простір, файли залишаються великими.

Я тут і там читав, що команда admin mongod --repairвикористовується для звільнення невикористаного простору, але мені не вистачає місця на диску для запуску цієї команди.

Чи знаєте ви, як я можу звільнити невикористаний простір?

ОНОВЛЕННЯ: за допомогою compactкоманди та WiredTiger схоже, що додатковий простір на диску буде фактично звільнений в ОС .

ОНОВЛЕННЯ: станом на v1.9 + є compactкоманда.

Ця команда виконає ущільнення "в рядку". Ще буде потрібно трохи додаткового місця, але не стільки.

MongoDB стискає файли:

• копіювання файлів на нове місце
• прокручування документів та переупорядкування / повторне їх вирішення
• заміна оригінальних файлів на нові

Ви можете зробити це «стиснення», запустивши mongod --repairабо підключившись безпосередньо та запустившись db.repairDatabase().

В будь-якому випадку вам потрібно десь простір, щоб скопіювати файли. Зараз я не знаю, чому у вас недостатньо місця для компресії, проте у вас є деякі варіанти, якщо у вас інший комп'ютер з більшою кількістю місця.

1. Експортуйте базу даних на інший комп'ютер із встановленим (використовуючи mongoexport) Mongo, і тоді ви можете імпортувати цю ж базу даних (використовуючи mongoimport). Це призведе до стиснення нової бази даних, яка більше стискається. Тепер ви можете зупинити оригінальну mongodзаміну новими файлами бази даних, і ви готові йти.
2. Зупиніть поточний монгод і скопіюйте файли бази даних на більший комп'ютер та запустіть ремонт на цьому комп’ютері. Потім ви можете перемістити нові файли бази даних на початковий комп'ютер.

Наразі не існує хорошого способу "компактного місця", використовуючи Монго. І Монго напевно може висмоктати багато місця.

Найкраща стратегія для ущільнення - запустити налаштування Master-Slave. Ви можете потім ущільнити Раба, нехай він наздожене і переключить їх. Я знаю ще трохи волохатий. Можливо, команда Монго придумає кращі місця ущільнення, але я не думаю, що це високо в їхньому списку. Наразі простір приводу вважається дешевим (і це зазвичай є).

У мене була та сама проблема, і її вирішили, просто зробивши це в командному рядку:

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

Схоже, Mongo v1.9 + має підтримку компактних на місці!

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

Дивіться документи тут: http://docs.mongodb.org/manual/reference/command/compact/

"На відміну від repairDatabase, компактна команда не потребує подвійного дискового простору для виконання своєї роботи. Для роботи потрібна невелика кількість додаткового місця під час роботи. Крім того, компактність швидша."

Ущільнюйте всі колекції в поточній базі даних

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

Якщо вам потрібно запустити повний ремонт, скористайтеся repairpathопцією. Наведіть його на диск з більшою кількістю вільного місця.

Наприклад, на моєму Mac я використовував:

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

Оновлення: Білет на сервер MongoDB 4266 , можливо, вам потрібно буде додати, --nojournalщоб уникнути помилки:

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

Починаючи з 2.8 версії Mongo, можна використовувати стиснення . У вас буде три рівні стиснення за допомогою двигуна WiredTiger, mmap (який за замовчуванням у 2.6 не забезпечує стиснення):

• Жоден
• snappy (за замовчуванням)
• зліб

Ось приклад того, скільки місця ви зможете зекономити для 16 ГБ даних:

дані взяті з цієї статті.

Нам потрібно вирішити 2 способи, засновані на StorageEngine.

1. Двигун MMAP ():

команда: db.repairDatabase ()

ПРИМІТКА: repairDatabase вимагає вільного місця на диску, рівного розміру вашого поточного набору даних плюс 2 гігабайти. Якщо для гучності, яка містить dbpath, не вистачає місця, ви можете встановити окремий об'єм і використовувати його для ремонту. Під час монтажу окремого тома для RepairDatabase ви повинні запустити repairDatabase з командного рядка та скористатися перемикачем --repairpath, щоб вказати папку, в якій зберігатимуться тимчасові файли ремонту. наприклад: Уявіть, що розмір БД становить 120 ГБ, означає (120 * 2) +2 = 242 Гб місця на жорсткому диску.

інший спосіб робити колекцію мудро, команда: db.runCommand ({compact: 'collectionName'})

2. WiredTiger: Автоматично його вирішується.

У MongoDB спостерігається значна плутанина щодо рекультивації космосу, і деякі рекомендовані практики прямо небезпечні для певних типів розгортання. Детальніше нижче:

TL; DR repairDatabase намагається врятувати дані за допомогою самостійних розгортань MongoDB, які намагаються відновити після пошкодження диска. Якщо він відновлює простір, це суто побічний ефект . Відновлення простору ніколи не повинно бути основним фактором роботи repairDatabase.

Відновіть простір в автономному вузлі

WiredTiger: Для автономного вузла з WiredTiger біг compactзвільнить простір для ОС, з одним застереженням: compactКоманда на WiredTiger на MongoDB 3.0.x вплинула на цю помилку: SERVER-21833, яка була виправлена ​​в MongoDB 3.2.3. До цієї версії compactна WiredTiger можна було мовчки вийти з ладу.

MMAPv1: Завдяки тому, як MMAPv1 працює, не існує безпечного і підтримуваного методу відновлення місця за допомогою двигуна зберігання MMAPv1. compactв MMAPv1 дефрагментує файли даних, потенційно надаючи більше місця для нових документів, але він не звільнить простір назад в ОС.

Ви можете запустити, repairDatabaseякщо повністю зрозумієте наслідки цієї потенційно небезпечної команди (див. Нижче), оскільки repairDatabaseпо суті переписує всю базу даних, відкинувши пошкоджені документи. Як побічний ефект, це створить нові файли даних MMAPv1 без будь-якої фрагментації та звільнить простір назад в ОС.

Для менш пригодного методу, запуск mongodumpі mongorestoreможе бути можливим також і при розгортанні MMAPv1, залежно від розміру розгортання.

Відновити простір у наборі реплік

Для конфігурацій набору реплік найкращим і найбезпечнішим методом відновлення простору є виконання початкової синхронізації як для WiredTiger, так і для MMAPv1.

Якщо вам потрібно відновити простір з усіх вузлів у наборі, ви можете здійснити прокатну початкову синхронізацію. Тобто виконайте початкову синхронізацію на кожному з вторинних, перш ніж остаточно відмовитися від основного та виконати початкове синхронізацію на ньому. Метод початкового синхронізації є найбезпечнішим методом обслуговування технічного обслуговування набору реплік, а також не передбачає простоїв у якості бонусу.

Зауважте, що доцільність здійснення початкової синхронізації також залежить від розміру розгортання. Для надзвичайно великих розгортань може бути неможливо здійснити початкову синхронізацію, і тому ваші параметри дещо обмежені. Якщо використовується WiredTiger, можливо , ви зможете вийняти з набору один вторинний запуск, запустити його як окремий, запустити compactйого та знову приєднатись до набору.

Стосовно repairDatabase

Будь ласка, не запускайте repairDatabaseвузли набору реплік . Це дуже небезпечно, як згадується на сторінці repairDatabase та описано більш детально нижче.

Назва repairDatabaseтрохи вводить в оману, оскільки команда нічого не намагається відновити. Команда повинна була використовуватися, коли на автономному вузлі є пошкодження диска , що може призвести до пошкодження документів.

repairDatabaseКоманда може бути більш точно описана як «рятівної база даних». Тобто він відтворює бази даних, відкидаючи пошкоджені документи, намагаючись перевести базу даних у стан, коли ви можете її запустити, і вилучити з неї недоторканий документ.

У розгортаннях MMAPv1 ця перебудова файлів баз даних звільняє простір для ОС як побічний ефект . Звільнення місця в ОС ніколи не було метою.

Наслідки repairDatabaseна наборі реплік

У наборі реплік MongoDB очікує, що всі вузли в наборі містять однакові дані. Якщо ви працюєте repairDatabaseна вузлі набору реплік, є ймовірність, що вузол містить невиявлену пошкодження і repairDatabaseналежним чином видалить пошкоджені для вас документи.

Передбачувано це робить, що вузол містить інший набір даних від решти набору. Якщо оновлення потрапить на цей єдиний документ, весь набір може вийти з ладу.

Що ще гірше, цілком можливо, що ця ситуація може тривалий час перебувати в спокої, лише раптово завдаючи ударів без видимих ​​причин.

Якщо велика частина даних буде видалена з колекції, і колекція ніколи не використовує видалений простір для нових документів, цей простір потрібно повернути в операційну систему, щоб він міг використовуватися іншими базами даних або колекціями. Вам потрібно буде виконати компактну або ремонтну операцію для дефрагментації дискового простору та повернення корисного вільного місця.

Поведінка процесу ущільнення залежить від двигуна MongoDB наступним чином

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

MMAPv1

Операція ущільнення дефрагментує файли даних та індекси. Однак це не звільняє простір для операційної системи. Ця операція все ще корисна для дефрагментації та створення більш суміжного простору для повторного використання MongoDB. Однак це не приносить користі, хоча вільного місця на диску дуже мало.

Під час операції ущільнення потрібно додаткове місце на диску до 2 Гб.

Блокування рівня бази даних проводиться під час операції ущільнення.

Провідний тигр

Двигун WiredTiger за замовчуванням забезпечує стиснення, що споживає менше дискового простору, ніж MMAPv1.

Компактний процес звільняє вільний простір для операційної системи. Для виконання компактної операції потрібно мінімальний простір на диску. WiredTiger також блокує всі операції з базою даних, оскільки вона потребує блокування рівня бази даних.

Для двигуна MMAPv1 компактна конструкція не повертає простір операційній системі. Вам потрібно запустити операцію по ремонту, щоб звільнити невикористаний простір.

db.runCommand({repairDatabase: 1})

У Mongodb 3.0 і новіших версіях з'явився новий двигун зберігання даних - WiredTiger. У моєму випадку двигун комутації знизив використання диска з 100 Gb до 25Gb.

Файли бази даних не можуть бути зменшені. Під час "ремонту" бази даних, лише сервер mongo може видалити деякі файли. Якщо була видалена велика кількість даних, сервер mongo під час ремонту "випустить" (видалить) деякі існуючі файли.

Взагалі компактний є кращим для відновлення Бази даних. Але однією з переваг ремонту перед компактним є те, що ви можете видавати ремонт на весь кластер. Компактний ви повинні увійти в кожен шматок, що наче дратує.

Коли у мене була така ж проблема, я зупинив свій сервер mongo і запустив його знову командою

mongod --repair

Перед тим як запустити ремонт, слід перевірити, чи є у вас достатньо вільного місця на вашому жорсткому диску (хв - це розмір вашої бази даних)

Для автономного режиму ви можете використовувати компактний або ремонт,

Для моєго кластеризованого кластера чи репліки, на мій досвід, після запуску компактного на первинному, а потім компактного вторинного, розмір первинної бази даних зменшився, але не вторинного. Ви можете захотіти повторно синхронізувати член, щоб зменшити розмір вторинної бази даних. і зробивши це, ви можете виявити, що розмір вторинної бази даних ще більше зменшується, ніж первинний, я думаю, що компактна команда насправді не ущільнює колекцію. Отже, я закінчив перемикати первинний та вторинний набір реплік і робити повторно синхронізацію члена .

мій висновок полягає в тому, що найкращий спосіб зменшити розмір набору відтінків / реплік - це виконати повторний синхронізацію, переключити первинний вторинний і повторно синхронізувати.

mongoDB -repair не рекомендується у випадку, якщо він є осколковим кластером.

Якщо у використанні клаптичного кластера репліки встановити компактну команду, вона перепише та дефрагментує всі файли даних та покажчиків усіх колекцій. синтаксис:

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

при використанні із силою: справжній, компактний працює на основній множині реплік. напр db.runCommand ( { command : "collection_name", force : true } )

Інші моменти, які слід врахувати: -Блокує операції. тому рекомендується виконати у вікні технічного обслуговування. -Якщо набори реплік, що працюють на різних серверах, потрібно виконувати на кожному члені окремо. У разі шаруватих кластерів, компактні потреби виконуватимуться на кожному члені шару окремо. Неможливо виконати екземпляр mongos.

Просто один із способів, що я зміг це зробити. Ніякої гарантії щодо безпеки ваших існуючих даних. Спробуйте зі своїм ризиком.

Видаліть файли даних безпосередньо та перезапустіть mongod.

Наприклад, у ubuntu (шлях за замовчуванням до даних: / var / lib / mongodb) у мене було кілька файлів з назвою типу: collection. #. Я зберігаю колекцію.0 та видалив усі інші.

Здається, простіший спосіб, якщо у вас немає серйозних даних у базі даних.