Монго БД Реплика установила Застрял в состоянии ВОССТАНОВЛЕНИЯ

Мы создали набор реплик, и теперь проблема состоит в том, что 2 члена набора реплик [набор 3 элементов] находятся в режиме восстановления с 48 часов. Первоначально размер восстанавливающихся узлов увеличивался, а теперь даже это прекратилось. Таким образом, при восстановлении узлов они застряли после 90 ГБ данных с 60+ ГБ локальных данных.

Как выйти из этого режима?

Простой, хотя и немного небезопасный способ

1. Остановить первый вторичный
2. Удалить содержимое этого dbpath
3. Перезапустите вторичный
4. Подождите, пока он догонит первичную
5. Повторите процесс со вторым вторичным

Это немного небезопасно, так как неизвестно, почему вторичные серверы перешли в состояние восстановления.

Более безопасный, но и более навязчивый способ

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

Самый безопасный, но и самый навязчивый способ

1. Выключите весь набор реплик
2. Удалить содержимое dbpathна обоих вторичных
3. Скопируйте содержимое dbpathв оба сайтаdbpath
4. Начните старый первичный.
5. Начните одну из старых вторичных.
6. Подождите, пока не будет выбран новый основной.
7. Запустите оставшееся среднее.

Некоторые заметки:

Используйте MMS . Он бесплатный, его легко настроить, и он дает вам хорошую информацию о вашем наборе реплик. Постарайтесь, чтобы значение «задержки репликации» оставалось равным 0, и примите все необходимые меры, чтобы ваша задержка репликации никогда не превышала «окно журнала репликации».

Всегда убедитесь, что у вас есть сеть 1 Гб и (извините) дерьмо нагрузка на ОЗУ. Чем больше, тем лучше. Дополнительное правило: скорее половина ОЗУ и SSD, чем удвоение ОЗУ и отсутствие SSD (при этом ОЗУ остается в разумных пределах).

Отказ от ответственности: всегда делайте резервную копию производственных данных, прежде чем возиться с ними.

Процесс репликации завершается неудачно, даже если вы начинаете чистое копирование с нового dbpath на вторичном сервере . Поэтому нужно внести некоторые изменения в оплог . Размер оплога должен быть установлен на оптимальное значение, чтобы он мог обрабатывать все записи приложения в него.

Увеличение размера оплога:

Завершение работы основного сервера

use admin

db.shutdownServer()

Начните основной как автономный и запустите на другом порту, скажем, 37017

Вход в Монго в порт 37017

mongo --port 37017

Удалить старое содержимое в локальной базе данных

В целях безопасности сделайте backop старого оплога перед тем, как уронить

mongodump --db local --collection 'oplog.rs' --port 37017

Удалить старое содержимое в локальной базе данных

use local

db.oplog.rs.drop()

db.me.drop()

db.replset.election.drop()

db.replset.minvalid.drop()

db.startup_log.drop()

Коллекция Replset не может быть удалена, поэтому удалите ее с необходимым идентификатором:

db.system.replset.remove({ "_id" : "your_replsetname"})

Создайте новый оплог необходимого размера, скажем, 50 ГБ

db.runCommand( { create: "oplog.rs", capped: true, size: (50 * 1024 * 1024 * 1024) } )

Также вы можете указать размер оплога в МБ в файле mongod.conf, скажем, для 50 ГБ это 429496 МБ.

replication:
   oplogSizeMB: 429496

Надеюсь это поможет !!!

Редактировать:

Как упомянул Николас Толи Коттрелл в комментариях. В версии 3.6 MongoDB мы можем изменять размер журнала во время выполнения без перезапуска.

Проверьте текущий размер оплога

use local
db.oplog.rs.stats().maxSize

Чтобы изменить размер оплога до 10 ГБ

db.adminCommand({replSetResizeOplog: 1, size: 10000})