MongoDB Replica-Set Очистка диска

Я пытаюсь уменьшить размер моего набора реплик MongoDB (коллекции такого же размера, но дисковое пространство продолжает расти). Согласно веб-сайту MongoDB, я должен просто запустить mongod --repair на главном узле, чтобы сжать все коллекции. Проблема будет в простое сайта. Итак, у меня есть два варианта (о которых я знаю):

  1. Снимите вторичный узел из набора реплик, запустите на нем mongod --repair и перезапустите его снова на наборе реплик. Я попробовал это и не смог исправить ошибки разрешения на «локальную» коллекцию.

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

Кто-нибудь еще сталкивался с этим сценарием? Я удивлен отсутствием информации при поиске этого.


mongodb replication diskspace
person Jed    schedule 04.12.2012    source источник
comment
В вашем вопросе вы говорите, что Mongo потребляет ресурсы сверх своего обычного жадного потребления?   -  person fdsaas    schedule 04.12.2012

Ответы (1)


arrow_upward
1
arrow_downward

Снимите вторичный узел из набора реплик, запустите на нем mongod --repair и перезапустите его снова на наборе реплик.

Это обычная практика, которую обычно называют «ремонтом прокаткой». Вы извлекаете каждую вторичную реплику из набора реплик и восстанавливаете ее, а в конечном итоге отключаете первичную для восстановления в качестве последнего шага. Если у вас всегда есть доступное большинство узлов набора реплик, этот подход минимизирует возможное время простоя.

Если вы часто удаляете данные, вам следует рассмотреть возможность использования новой опции сбора PowerOf2Sizes в MongoDB 2.2. Это изменяет метод распределения для выделения пространства документа в степени двойки (например, для документа размером 500 байтов будет выделено 512 байтов), что позволяет более эффективно повторно использовать пространство из удаленных документов (с небольшими затратами на несколько дополнительных байтов на каждый документ). документ).

Я попробовал это и не смог исправить ошибки разрешения на «локальную» коллекцию.

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

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

Похоже, вы объединяете Journal, который используется для обеспечения устойчивости и восстановления после сбоя, с _ 3_, используемый для репликации.

Если вы повторно синхронизируете узел с основным, все данные будут скопированы. В течение этого начального периода узел будет в состоянии ВОССТАНОВЛЕНИЕ и не будет считаться «здоровым» узлом (т.е. доступным для запросов).

Как только узел будет захвачен, он перейдет в нормальное ВТОРИЧНОЕ состояние, после чего oplog будет использоваться для текущей синхронизации.

Дальнейшее чтение:

person Stennie    schedule 04.12.2012