Управление и освобождение дискового пространства в развертываниях MongoDB

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

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

Проверка использования диска на уровне хоста

Начните с файловой системы, содержащей dbPath MongoDB. MongoDB не может безопасно продолжать запись, если этот том заполнен.

df -h /var/lib/mongodb

Также проверьте, какие каталоги растут:

du -sh /var/lib/mongodb/* | sort -h

Используйте ваш фактический dbPath; /var/lib/mongodb распространен в пакетах Linux, но не универсален.

Проверка метрик хранилища MongoDB

Внутри mongosh сравните логический размер данных с выделенным размером хранилища.

use myDatabase
db.stats()

Полезные поля включают:

dataSize: Логический размер данных документов.
storageSize: Пространство, выделенное для данных коллекции.
indexSize: Пространство, используемое индексами.

Для конкретной коллекции:

db.orders.stats({ scale: 1024 * 1024 })

Посмотрите на size, storageSize и totalIndexSize. Если storageSize намного больше, чем size, коллекция может иметь повторно используемое внутреннее пространство от обновлений и удалений. Если totalIndexSize велик, индексы могут быть самым быстрым способом уменьшить использование диска.

Распространенные причины роста диска MongoDB

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

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

Пробелы в хранении — еще одна распространенная причина. Коллекции журналов, сессий, событий и аудита растут бесконечно, если вы не архивируете или не удаляете старые документы.

Безопасные способы уменьшения будущего роста

Лучшее решение проблемы с диском обычно заключается в предотвращении неограниченного роста.

Для данных, основанных на времени, создайте TTL-индекс:

db.logEvents.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 86400 }
)

Удаление TTL обрабатывается фоновым монитором и не происходит мгновенно до секунды. Тем не менее, это хороший выбор для журналов, сессий и временных событий, где точное время удаления не критично.

Просмотрите индексы перед удалением чего-либо:

db.orders.getIndexes()
db.orders.aggregate([{ $indexStats: {} }])

$indexStats может показать, использовался ли индекс с момента запуска процесса. Относитесь к этому как к подсказке, а не доказательству. Индекс для ежемесячного отчета может выглядеть неиспользуемым в тихую неделю.

Удалите подтвержденный неиспользуемый индекс по имени:

db.orders.dropIndex('customerId_1_createdAt_-1')

Возврат пространства из существующих файлов

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

Осторожное использование `compact`

compact может переписать данные коллекции и индекса, чтобы уменьшить использование диска. Это ресурсоемкая операция и может блокировать операции на затронутой коллекции, в зависимости от вашей версии MongoDB и развертывания.

db.runCommand({ compact: 'orders' })

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

Дамп и восстановление при сильной фрагментации

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

mongodump --db myDatabase --collection orders --out /backup/mongo-dump

После проверки дампа и планирования переключения восстановите в целевой среде:

mongorestore --db myDatabase --collection orders \
  /backup/mongo-dump/myDatabase/orders.bson

Не удаляйте производственные данные, пока у вас нет проверенной резервной копии и плана отката.

Чего не следует делать

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

Не предполагайте, что du и логический размер MongoDB должны совпадать. Сжатие, индексы, внутреннее свободное пространство и поведение файловой системы влияют на числа.

Будьте осторожны со старыми советами о предварительном выделении в стиле MMAPv1. Современные развертывания MongoDB обычно используют WiredTiger, и его поведение хранения отличается.

Практический вывод

Когда использование диска MongoDB выглядит неправильным, сначала измерьте хост, затем базы данных, коллекции и индексы. Используйте TTL-индексы и архивирование для замедления роста. Удаляйте только подтвержденные ненужные индексы. Для реального возврата пространства файловой системе планируйте compact или рабочий процесс дампа и восстановления, вместо того чтобы ожидать, что удаление немедленно уменьшит файлы.