База данных MongoDB становится больше после использования $ unset [duplicate]
Метод getContext () помогает использовать Контекст класса в активности фрагмента.
15 ответов
Когда у меня была та же проблема, я остановил свой сервер mongo и снова начал его с помощью команды
mongod --repair
Перед запуском операции восстановления вы должны проверить, достаточно ли свободного места на вашем жестком диске (мин - размер вашей базы данных)
Если вам нужно выполнить полный ремонт, используйте параметр 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
-
1Это отлично поработало. Мне не хватало места, необходимого для ремонта на месте, поэтому я смонтировал NAS. Только проблема, потребовалось 18 часов, но это действительно сработало. Не забудьте добавить флаг --nojoural. – zenocon 1 April 2016 в 15:04
Только один способ, которым я смог это сделать. Нет гарантии безопасности ваших существующих данных.
Немедленно удалите файлы данных и перезапустите mongod.
Например, с помощью ubuntu (путь по умолчанию к данным: / var / lib / mongodb) у меня было пару файлов с именем вроде: collection. #. Я сохраняю коллекцию.0 и удаляю все остальные.
Кажется более простым способом, если у вас нет серьезных данных в базе данных.
-
1файлы хранятся в виде & lt; database_name & gt;. & lt; number & gt; например mydb.3 - вы не можете сказать коллекцию. – bobmarksie 30 July 2015 в 10:01
UPDATE: с командой compact и WiredTiger похоже, что дополнительное пространство на диске будет фактически выпущено в OS .
UPDATE: с v1.9 + есть команда compact .
Эта команда выполняет уплотнение «в строке». Это все равно потребуется дополнительное пространство, но не так много.
MongoDB сжимает файлы:
- копирует файлы в новое место
- перебирать документы и переупорядочивать / переустанавливать их
- заменять исходные файлы новыми файлами
Вы можете сделать это «сжатие» на mongod --repair или путем прямого подключения и запуска db.repairDatabase().
В любом случае вам нужно место для копирования файлов. Теперь я не знаю, почему у вас недостаточно места для выполнения компрессии, однако у вас есть некоторые опции, если у вас есть другой компьютер с большим объемом.
- Экспорт базы данных в другую компьютер с установленным Mongo (используя
mongoexport), а затем вы можете импортировать ту же базу данных (используяmongoimport). Это приведет к сжатию новой базы данных. Теперь вы можете остановить замену оригиналаmongodновыми файлами базы данных, и вам хорошо идти. - Остановить текущий mongod и скопировать файлы базы данных на более крупный компьютер и запустить ремонт на этом компьютере , Затем вы можете переместить новые файлы базы данных на исходный компьютер.
В настоящее время нет хорошего способа «сжать на месте» с помощью Mongo. И Mongo может определенно сосать много места.
Лучшей стратегией сейчас для уплотнения является запуск настройки Master-Slave. Затем вы можете сжать Slave, позволить ему догнать и переключить их. Я знаю еще немного волосатого. Может быть, команда Монго придумает лучшее уплотнение на месте, но я не думаю, что это высоко в их списке. В настоящее время пространство на диске считается дешевым (и обычно оно).
-
1Спасибо, Гейтс В.П. за ваш ответ. Я думал о двух вариантах, которые вы упомянули. Но прежде чем делать такие вещи, я хотел знать, доступно ли компактное решение. Еще раз спасибо. – Meuble 4 June 2010 в 18:01
-
2На сегодняшний день (2010-11-18) Дуайт (выступая на мероприятии MongoDC в Вашингтоне, округ Колумбия) рекомендовал использовать репликацию / --repair / switch over, если вы хотите сжать, не отключая свою базу данных в автономном режиме. – David J. 18 November 2010 в 16:46
-
3Просто голова «не делай, как я», и беги - исправляйся как корень. chowns файлы db к root. DOH. – Totoro 1 April 2011 в 02:28
-
4В документации для «compact» говорится: «Эта операция не уменьшает объем дискового пространства, используемого в файловой системе». Я не понимаю, как это решение исходного вопроса. – Ed Norris 12 July 2012 в 18:28
-
5Если вы посмотрите на исходный вопрос, часть проблемы связана с наличием слишком большого количества данных для выполнения ремонта. Если вы заполнили 2/3 вашего диска одной БД, вы не смогли бы выполнить ремонт. Недавно выделенные файлы будут всасывать оставшееся пространство до того, как новая БД будет полностью «скопирована & amp; отремонтировать & Quot; и "переключатель" никогда не произойдет. С помощью
compactон может по крайней мере сохранить существующие файлы на месте. Я согласен, это не полное решение, но это постепенное улучшение. – Gates VP 12 July 2012 в 21:46
Mongodb 3.0 и выше имеет новый механизм хранения - WiredTiger. В моем случае при переключении двигателя уменьшено использование диска с 100 Гб до 25 ГБ.
Файлы базы данных не могут быть уменьшены по размеру. В то время как «восстанавливая» базу данных, только сервер mongo может удалить некоторые из своих файлов. Если большой объем данных был удален, сервер mongo «освободит» (удалить), во время ремонта, некоторые из его существующих файлов.
Нам нужно решить два способа, основанных на StorageEngine.
1. MMAP (): команда
: db.repairDatabase ()
ПРИМЕЧАНИЕ: repairDatabase требует свободного дискового пространства, равного размеру вашего текущего набора данных плюс 2 гигабайта. Если на томе, на котором хранится dbpath, недостаточно места, вы можете установить отдельный том и использовать его для ремонта. При установке отдельного тома для repairDatabase вы должны запустить repairDatabase из командной строки и использовать переключатель --repairpath, чтобы указать папку для хранения временных файлов восстановления. например: Представьте, что размер БД составляет 120 ГБ, (120 * 2) +2 = 242 ГБ. Требуется место на жестком диске.
другой способ, которым вы коллекционируете мудрый, команда: db.runCommand ({compact: 'collectionName '})
2. WiredTiger: он автоматически разрешил сам.
-
1
В MongoDB наблюдается некоторая значительная путаница в вопросе о мелиорации, и некоторые рекомендуемые практики совершенно опасны для определенных типов развертывания. Подробнее см. Ниже:
TL; DR repairDatabase пытается спасти данные из автономных развертываний MongoDB, которые пытаются восстановить повреждение диска. Если он восстанавливает пространство, это чисто побочный эффект.
Восстановить пространство в автономном узле
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 page и описано более подробно ниже.
Имя repairDatabase немного вводит в заблуждение, так как команда не пытается ремонт ничего. Команда была предназначена для использования при повреждении диска на автономном узле , что может привести к повреждению документов.
Команда repairDatabase может быть более точно описана как «спасение» база данных". То есть, он воссоздает базы данных, отбрасывая поврежденные документы, пытаясь получить базу данных в состояние, в котором вы можете запустить ее, и избавить от него неповрежденный документ.
В развертываниях MMAPv1 эта перестройка файлов базы данных освобождает место для ОС как побочный эффект. Освобождение пространства для ОС никогда не было целью.
Последствия repairDatabase для набора реплик
В наборе реплик MongoDB ожидает, что все узлы в наборе будут содержать одинаковые данные. Если вы запустили repairDatabase на узле набора реплик, есть вероятность, что узел содержит необнаруженное повреждение, а repairDatabase послушно удалит поврежденные документы для вас.
Как и ожидалось, это делает этот узел другой набор данных из остальной части набора. Если произойдет обновление, которое ударит по этому единственному документу, весь набор может сработать.
Чтобы ухудшить ситуацию, вполне возможно, что эта ситуация может оставаться бездействующей в течение длительного времени, только чтобы внезапно ударить без видимых причина.
Похоже, что Mongo v1.9 + имеет поддержку компактности на месте!
> db.runCommand( { compact : 'mycollectionname' } )
См. документы здесь: http://docs.mongodb.org/manual/reference / command / compact /
«В отличие от repairDatabase, компактная команда не требует двойного дискового пространства для выполнения своей работы. Для работы требуется небольшое количество дополнительного пространства. Кроме того, compact быстрее. "
-
1
-
2@AnujGupta "Команда repairDatabase объединяет все коллекции в базе данных. Он идентичен выполнению компактной команды для каждой коллекции отдельно. & Quot; [Д0] docs.mongodb.org/manual/reference/command/repairDatabase/… . Поэтому, если repairDatabase уменьшает размер, как компактный. Я собирал свои коллекции с большим количеством удаления и обновления каждую неделю. Мне нравится компактнее, чем repariDatabase, потому что сначала он предназначен для коллекций, которые вы хотите не всей базы данных. Во-вторых, просто нужно 2 ГБ свободного места вместо x2 вашего файла db (в моем случае 500 ГБ). – Maziyar 27 October 2013 в 01:48
-
3@Maziyar docs.mongodb.org/manual/reference/command/compact/#disk-space - «В отличие от repairDatabase компактность не освобождает место в файловой системе». – Anuj Gupta 24 April 2014 в 18:26
-
4@Maziyar OP хочет освободить неиспользуемое пространство , что достигается с помощью
repairDatabase, а неcompact.compactне освобождает место, он только дефрагментирует использованное пространство, которое не уменьшает его. – Anuj Gupta 25 April 2014 в 19:27 -
5Начиная с mongo 3.0,
compactбудет освобождать пространство при использовании механизма хранения WiredTiger. – Gary 3 December 2015 в 01:57
Компактность всех коллекций в текущей базе данных
db.getCollectionNames().forEach(function (collectionName) {
print('Compacting: ' + collectionName);
db.runCommand({ compact: collectionName });
});
Начиная с версии 2.8 Mongo, вы можете использовать сжатие . У вас будет 3 уровня сжатия с движком WiredTiger, mmap (который по умолчанию в 2.6 не обеспечивает сжатия):
Ниже приведен пример того, сколько места вы сможете сохранить для 16 ГБ данных:
[/g4]
данные взяты из этой статьи .
В общем случае компактность предпочтительнее repairDatabase. Но одно преимущество ремонта по сравнению с компактным - вы можете выполнить ремонт всего кластера. компактный, вам нужно входить в каждый осколок, что раздражает.
У меня была та же проблема, и я решил просто сделать это в командной строке:
mongodump -d databasename
echo 'db.dropDatabase()' | mongo databasename
mongorestore dump/databasename
-
1Утверждение: 15936 Сбой создания коллекции db.collection. Errmsg: exception: укажите размер: & lt; n & gt; когда закрыто верно – tweak2 10 December 2013 в 21:16
-
2: Похоже на регрессию ubuntu ... файл дампа имеет метаданные: «неопределенный»; в нем ... удаление этих проблем устраняет проблему импорта. – tweak2 10 December 2013 в 21:19
-
3Моя база данных забила почти весь диск. он был 120 ГБ (диск 160 ГБ). Компакт не уменьшает размер файла, а repairDatabase невозможен из-за нехватки места. После mongodump & amp; dropDatabase & amp; mongorestore of db У меня 40 GB размер базы данных. – Igor Benikov 2 October 2016 в 10:21
-
4Небольшая коррекция команды restore
mongorestore --db databasename dump/databasename– JERRY 6 March 2017 в 13:25
В случае удаления большого фрагмента данных из коллекции, и коллекция никогда не использует удаленное пространство для новых документов, это пространство должно быть возвращено в операционную систему, чтобы оно могло использоваться другими базами данных или коллекциями.
Поведение процесса уплотнения зависит от механизма MongoDB следующим образом
db.runCommand({compact: collection-name })
MMAPv1
Операции дефрагментации операций уплотнения данных и amp; индексов. Однако он не освобождает место для операционной системы. Операция по-прежнему полезна для дефрагментации и создания более непрерывного пространства для повторного использования MongoDB. Тем не менее, это бесполезно, когда свободное место на диске очень мало.
Во время операции уплотнения требуется дополнительное пространство на диске до 2 ГБ.
Блокировка уровня базы данных
WiredTiger
Механизм WiredTiger обеспечивает сжатие по умолчанию, которое потребляет меньше места на диске, чем MMAPv1.
Компактный процесс освобождает свободное пространство к операционной системе. Для выполнения компактной операции требуется минимальное дисковое пространство. WiredTiger также блокирует все операции с базой данных, так как он нуждается в блокировке уровня базы данных.
Для механизма MMAPv1 компактность не возвращает пространство в операционную систему. Для освобождения неиспользуемого пространства вам потребуется выполнить операцию восстановления.
db.runCommand({repairDatabase: 1})
Здесь вы можете найти подробную информацию о компактной работе здесь