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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• None
• snappy (по умолчанию)
• zlib

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

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

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

1. MMAP():

: db.repairDatabase()

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

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

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

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

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

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

MMAPv1

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

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

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

WiredTiger

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

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

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

db.runCommand({repairDatabase: 1})

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

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

TL; DR repairDatabase пытается спасти данные из автономных развертываний MongoDB, которые пытаются восстановить повреждение диска. Если он восстанавливает пространство, это чисто побочный эффект. Восстановление пространства никогда не должно быть основным соображением при запуске repairDatabase.

Восстановить пространство в автономном режиме node

WiredTiger:. Для автономного node с 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.

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

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

Относительно repairDatabase

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

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

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

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

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

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

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

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

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

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

mongod --repair

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

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

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

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

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

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

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