Уменьшение размера файла базы данных MongoDB

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

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

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

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

UPDATE: с compact командой и WiredTiger похоже, что дополнительное пространство на диске будет фактически выпущено в ОС .


UPDATE: с v1.9 + есть compact команда.

Эта команда выполнит сжатие «в строке». Ему все равно потребуется дополнительное пространство, но не так много.


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

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

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

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

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

В настоящее время нет хорошего способа «сжать на месте» с помощью Mongo. И Mongo может определенно сосать много места.

Лучшей страtagsей сейчас для уплотнения является запуск настройки Master-Slave. Затем вы можете сжать 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, компактная команда не требует двойного дискового пространства для выполнения своей работы, она требует небольшого количества дополнительного пространства во время работы. Кроме того, компактность быстрее».

Если вам нужно выполнить полный ремонт, используйте опцию 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 

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

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

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

  • Никто
  • мгновенно (по умолчанию)
  • Zlib

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

введите описание изображения здесь

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

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

1. MMAP ():

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

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

другой способ сбора мудрых команд: db.runCommand ({compact: ‘collectionName’})

2. WiredTiger: его автоматически разрешено.

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

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

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

MMAPv1

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

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

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

WiredTiger

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

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

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

 db.runCommand({repairDatabase: 1}) 

Здесь вы можете найти подробную информацию о компактной работе

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

В MongoDB наблюдается некоторая значительная путаница в вопросе о мелиорации, и некоторые рекомендуемые практики совершенно опасны для определенных типов развертывания. Подробнее см. Ниже:

TL; DR repairDatabase пытается 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 будет деfragmentировать файлы данных, потенциально делая больше свободного места для новых документов, но он не освободит место обратно в ОС.

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

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

Восстановление места в наборе реплик

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

Если вам нужно восстановить пространство со всех узлов в наборе, вы можете выполнить скользящую начальную синхронизацию. То есть, выполнить начальную синхронизацию для каждого из вторичных, прежде чем, наконец, отступить от основного и выполнить начальную синхронизацию. Роллинг-метод начальной синхронизации – самый безопасный способ выполнения обслуживания набора реплик, а также не требует простоев в качестве бонуса.

Обратите внимание, что возможность выполнения начальной синхронизации также зависит от размера развертывания. Для чрезвычайно больших развертываний может быть невозможно выполнить начальную синхронизацию, и, таким образом, ваши параметры несколько более ограничены. Если WiredTiger используется, вы можете взять один дополнительный из набора, запустить его как автономный, запустить compact на нем и снова подключиться к набору.

Что касается repairDatabase

Пожалуйста, не запускайте repairDatabase на узлах набора реплик . Это очень опасно, как указано на странице repairDatabase и более подробно описано ниже.

Имя repairDatabase немного вводит в заблуждение, так как команда не пытается ничего исправить. Команда предназначалась для использования при повреждении диска на автономном узле , что может привести к повреждению документов.

Команда repairDatabase может быть более точно описана как «firebase database спасения». То есть, он воссоздает базы данных, отбрасывая поврежденные документы, пытаясь заставить базу данных войти в состояние, в котором вы можете запустить ее и спасти от нее неповрежденный документ.

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

Последствия repairDatabase на наборе реплик

В наборе реплик MongoDB ожидает, что все узлы в наборе будут содержать одинаковые данные. Если вы запустили repairDatabase на узле набора реплик, есть вероятность, что узел содержит необнаруженное повреждение, а repairDatabase будет repairDatabase удалять поврежденные документы для вас.

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

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

Файлы базы данных не могут быть уменьшены по размеру. В то время как «восстанавливая» базу данных, только сервер mongo может удалить некоторые из своих файлов. Если большой объем данных был удален, сервер mongo «освободит» (удалить), во время ремонта, некоторые из его существующих файлов.

В общем случае компактность предпочтительнее repairDatabase. Но одно преимущество ремонта по сравнению с компактным – вы можете выполнить ремонт всего кластера. компактный, вы должны войти в каждый осколок, что довольно раздражает.

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

 mongod --repair 

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

Только один способ, которым я смог это сделать. Нет гарантии безопасности ваших существующих данных. Попробуйте свой собственный риск.

Немедленно удалите файлы данных и перезапустите mongod.

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

Это проще, если у вас нет серьезных данных в базе данных.

  • значения группы mongodb по нескольким полям
  • Как обновить несколько элементов массива в mongodb
  • Как вставить элемент в внутренний список MongoDB?
  • Заseleniumие Mongoose vs вложенность объекта
  • Удалить внедренный документ во вложенном массиве документов
  • Mongodb обновляет глубоко вложенный поддокумент
  • Как защитить поле пароля в Mongoose / MongoDB, чтобы он не возвращался в запрос при заполнении коллекций?
  • Индексирование Mongoose в производственном коде
  • запрос на основе даты
  • Автоматическое увеличение в MongoDB для сохранения последовательности уникального идентификатора пользователя
  • Model.find (). ToArray () утверждает, что не имеет метода .toArray ()
  • Давайте будем гением компьютера.