Уменьшение размера файла базы данных MongoDB - PullRequest
161 голосов
/ 03 июня 2010

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

Но поскольку MongoDB сохраняет выделенное пространство, файлы все еще остаются большими.

Я тут и там читал, что команда администратора mongod --repair используется для освобождения неиспользуемого пространства, но на диске недостаточно места для выполнения этой команды.

Вы знаете, как я могу освободить неиспользуемое пространство?

Ответы [ 16 ]

144 голосов
/ 04 июня 2010

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


ОБНОВЛЕНИЕ: с v1.9 + есть команда compact.

Эта команда выполнит сжатие "in-line". Потребуется дополнительное пространство, но не так много.


MongoDB сжимает файлы:

  • копирование файлов в новое место
  • просмотр документов и их повторный заказ / повторное решение
  • замена исходных файлов новыми файлами

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

В любом случае вам нужно где-то место для копирования файлов. Теперь я не знаю, почему у вас недостаточно места для сжатия, однако у вас есть несколько вариантов, если у вас есть другой компьютер с большим количеством места.

  1. Экспортируйте базу данных на другой компьютер с установленным Mongo (используя mongoexport), а затем вы можете импортировать эту же базу данных (используя mongoimport). Это приведет к новой базе данных, которая будет более сжатой. Теперь вы можете остановить оригинальную mongod замену новыми файлами базы данных, и все готово.
  2. Остановите текущий mongod и скопируйте файлы базы данных на больший компьютер и запустите восстановление на этом компьютере. Затем вы можете переместить новые файлы базы данных обратно на исходный компьютер.

В настоящее время не существует хорошего способа "компактирования на месте" с использованием Mongo. И Монго определенно может высосать много места.

Лучшая стратегия для уплотнения сейчас - запустить установку Master-Slave. Затем вы можете сжать Ведомого, позволить ему догнать и переключить их. Я знаю еще немного волосатым. Может быть, команда Монго придумает лучшее уплотнение на месте, но я не думаю, что это занимает первое место в их списке. Дисковое пространство в настоящее время считается дешевым (и обычно это так).

37 голосов
/ 04 апреля 2013

У меня была та же проблема, и я решил ее, просто выполнив это в командной строке:

mongodump -d databasename
echo 'db.dropDatabase()' | mongo databasename
mongorestore dump/databasename
31 голосов
/ 17 августа 2011

Похоже, что Mongo v1.9 + имеет поддержку компакта на месте!

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

См. Документы здесь: http://docs.mongodb.org/manual/reference/command/compact/

"В отличие от repairDatabase, команда compact делаетне требует двойного дискового пространства для своей работы. Во время работы требуется небольшое дополнительное пространство. Кроме того, компактность быстрее. "

14 голосов
/ 13 июля 2014

Сжать все коллекции в текущей базе данных

db.getCollectionNames().forEach(function (collectionName) {
    print('Compacting: ' + collectionName);
    db.runCommand({ compact: collectionName });
});
13 голосов
/ 27 августа 2012

Если вам нужно выполнить полное восстановление, используйте опцию repairpath. Укажите его на диск с большим количеством свободного места.

Например, на моем Mac я использовал:

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

Обновление: за MongoDB Core Server Ticket 4266 , вам может потребоваться добавить --nojournal, чтобы избежать ошибки:

mongod --config /usr/local/etc/mongod.conf --repair --repairpath /Volumes/X/mongo_repair --nojournal
11 голосов
/ 23 сентября 2015

Начиная с 2.8 версии Mongo, вы можете использовать сжатие . У вас будет 3 уровня сжатия с движком WiredTiger, mmap (по умолчанию в 2.6 не обеспечивает сжатие):

Вот пример того, сколько места вы сможете сэкономить для 16 ГБ данных:

enter image description here

данные взяты из этой статьи.

7 голосов
/ 09 января 2016

Нам нужно решить 2 способа, основываясь на StorageEngine.

1. MMAP () двигатель:

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

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

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

2. WiredTiger: Он автоматически разрешается самостоятельно.

4 голосов
/ 10 августа 2017

В 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 покорно удалит поврежденные документы за вас.

Как и ожидалось, этот узел содержит набор данных, отличный от остальной части набора. Если обновление попадет в этот единственный документ, весь набор может потерпеть крах.

Что еще хуже, вполне возможно, что эта ситуация может оставаться в состоянии покоя в течение длительного времени, только чтобы нанести внезапный удар без видимой причины.

4 голосов
/ 25 июля 2017

В случае, если большая часть данных удаляется из коллекции, и коллекция никогда не использует удаленное пространство для новых документов, это пространство необходимо вернуть операционной системе, чтобы его могли использовать другие базы данных или коллекции. Вам нужно будет выполнить операцию сжатия или восстановления, чтобы дефрагментировать дисковое пространство и восстановить используемое свободное пространство.

Поведение процесса уплотнения зависит от механизма MongoDB следующим образом

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

MMAPv1

Операция сжатия дефрагментирует файлы данных и индексы. Тем не менее, он не освобождает место для операционной системы. Эта операция по-прежнему полезна для дефрагментации и создания более непрерывного пространства для повторного использования MongoDB. Однако это бесполезно, когда свободное место на диске очень мало.

Для операции сжатия требуется дополнительное дисковое пространство до 2 ГБ.

Блокировка уровня базы данных удерживается во время операции сжатия.

WiredTiger

Движок WiredTiger по умолчанию обеспечивает сжатие, которое потребляет меньше дискового пространства, чем MMAPv1.

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

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

db.runCommand({repairDatabase: 1})
3 голосов
/ 30 июня 2016

Mongodb 3.0 и выше имеет новый механизм хранения - WiredTiger. В моем случае коммутатор уменьшил использование диска со 100 до 25 Гб.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...