В 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
покорно удалит поврежденные документы за вас.
Как и ожидалось, этот узел содержит набор данных, отличный от остальной части набора. Если обновление попадет в этот единственный документ, весь набор может потерпеть крах.
Что еще хуже, вполне возможно, что эта ситуация может оставаться в состоянии покоя в течение длительного времени, только чтобы нанести внезапный удар без видимой причины.