Репліка Монго БД встановлена ​​"Застрягла" у стані ВІДОМОГО

Ми створили набір реплік, і тепер проблема полягає в тому, що два члени набору реплік [3 набору членів] знаходяться в режимі відновлення з 48 годин. Спочатку розміри відновлюваних вузлів збільшувалися, а тепер навіть це припинилося. Тож у відновлення вузлів вони застрягли після 90 ГБ даних із 60+ ГБ локальних даних.

Як вийти з цього режиму?

Легкий, хоч і трохи незахищений спосіб

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

Це трохи невпевнено, оскільки невідомо, чому вторинники перейшли у стан відновлення.

Більш безпечний, але і більш нав'язливий спосіб

Як зазначено вище, але зупиніть свою заявку під час процесу. Це запобігає можливості, щоб ваша програма вставляла більше даних, ніж вторинні можуть здавати. Однак проблема може виникнути під час виробництва.

Найбезпечніший, але й самий настирливий спосіб

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

Деякі примітки:

Використовуйте MMS . Це безкоштовно, його легко налаштувати, і він дає хорошу інформацію про ваш набір реплік. Постарайтеся зберегти значення для "відставання реплікації" близько 0, і візьміть усі необхідні засоби, щоб ваш відставання реплікації ніколи не перевищувало "вікно оплогів реплікації".

Завжди переконайтеся, що у вас є 1Gb мережа та (вибачте) завантаженість оперативної пам’яті. Чим більше, тим краще. Додаткове правило: швидше половина оперативної пам’яті та SSD, ніж подвоєння оперативної пам’яті та відсутність SSD (при цьому RAM залишається в розумних межах)

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

Процес реплікації закінчується невдачею, навіть якщо ви починаєте скретч з нового dbpath на вторинному. Отже, справа в тому, щоб внести деякі зміни в oplog . Розмір oplog повинен бути встановлений на оптимальне значення, щоб воно могло обробляти всі записи програми в нього.

Збільшення розміру oplog:

Відключення основного сервера

use admin

db.shutdownServer()

Почніть основну, як самостійну, і запустіть на різних портах, скажімо, 37017

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

mongo --port 37017

Видаліть старий вміст у локальній базі даних

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

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) } )

Також ви можете вказати розмір oplog у МБ у файлі mongod.conf, скажімо, для 50 Гб його 429496 Мб

replication:
   oplogSizeMB: 429496

Сподіваюся, що це допомагає !!!

Редагувати:

Як згадував Ніколас Толлі Коттрелл у коментарях. У MongoDB версії 3.6 ми можемо змінювати розмір oplog під час виконання без перезавантаження.

Перевірте поточний розмір оплогу

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

Щоб змінити розмір oplog до 10 ГБ

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