Набір реплік MongoDB ВТОРИЧНО застряг у стані `ROLLBACK`

Під час нещодавнього автоматизованого оновлення нашої mongodb PRIMARY, коли PRIMARYвідступив, він назавжди перейшов у ROLLBACKстан.

Після декількох годин перебування в ROLLBACKстані .bsonв rollbackкаталозі бази даних mongodb досі не було файлу відката. Це, а також цей рядок у нашому файлі журналу:, [rsSync] replSet syncThread: 13410 replSet too much data to roll backсхоже, вказує на те, що ROLLBACKпроцес не вдався.

Я хотів би допомогти проаналізувати, що саме пішло не так.

• Здається, у наших журналах відбулися дві різні відмови. Це так чи це тривало 3 години?
• Якщо перший відкат (о 19:00) був успішним, чому нічого не з’явилося в rollbackкаталозі ou ?
• Будь-яка здогадка про причину всіх цих попереджень? Це може бути пов'язано з відмовою відмови?
• Ми втратили 18 секунд даних через першу ROLLBACK?
• Чи є загальне вирішення проблеми "застряг у ROLLBACKдержаві"? Нарешті, нам довелося шлангувати весь наш БД і повторно синхронізуватись з основного.

Відповідні рядки журналу:

# Primary coming back after restart...
Tue May 15 19:01:01 [initandlisten] MongoDB starting : pid=3684 port=27017 dbpath=/var/lib/mongodb 64-bit host=magnesium
Tue May 15 19:01:01 [initandlisten] db version v2.0.5, pdfile version 4.5
# ... init stuff
Tue May 15 19:01:01 [initandlisten] journal dir=/var/lib/mongodb/journal
Tue May 15 19:01:01 [initandlisten] recover : no journal files present, no recovery needed
# ... More init stuff
Tue May 15 19:01:03 [rsStart] trying to contact rs1arb1.c9w.co:27017
Tue May 15 19:01:03 [rsStart] trying to contact rs1m2.c9w.co:27017
Tue May 15 19:01:03 [rsStart] replSet STARTUP2
Tue May 15 19:01:03 [rsHealthPoll] replSet member rs1arb1.c9w.co:27017 is up
Tue May 15 19:01:03 [rsHealthPoll] replSet member rs1arb1.c9w.co:27017 is now in state ARBITER
Tue May 15 19:01:03 [rsSync] replSet SECONDARY
Tue May 15 19:01:05 [rsHealthPoll] replSet member rs1m2.c9w.co:27017 is up
Tue May 15 19:01:05 [rsHealthPoll] replSet member rs1m2.c9w.co:27017 is now in state PRIMARY
Tue May 15 19:01:09 [rsSync] replSet syncing to: rs1m2.c9w.co:27017
Tue May 15 19:01:09 [rsSync] replSet our last op time written: May 15 19:00:51:6
Tue May 15 19:01:09 [rsSync] replSet rollback 0
Tue May 15 19:01:09 [rsSync] replSet ROLLBACK
Tue May 15 19:01:09 [rsSync] replSet rollback 1
Tue May 15 19:01:09 [rsSync] replSet rollback 2 FindCommonPoint
Tue May 15 19:01:09 [rsSync] replSet info rollback our last optime:   May 15 19:00:51:6
Tue May 15 19:01:09 [rsSync] replSet info rollback their last optime: May 15 19:01:09:19
Tue May 15 19:01:09 [rsSync] replSet info rollback diff in end of log times: -18 seconds
Tue May 15 19:01:10 [rsSync] replSet WARNING ignoring op on rollback no _id TODO : nimbus.system.indexes { ts: Timestamp 1337108400000|17, h: 1628369028235805797, op: "i", ns: "nimbus.system.indexes", o: { unique: true, name: "pascalquery_ns_key_start_ts_keyvals", key: { __ns__: 1, _key: 1, start_ts: 1, _keyval.a: 1, _keyval.b: 1, _keyval.c: 1, _keyval.d: 1, _keyval.e: 1, _keyval.f: 1, _keyval.g: 1, _keyval.h: 1 }, ns: "nimbus.wifi_daily_series", background: true } }
# ...
# Then for several minutes there are similar warnings
# ...
Tue May 15 19:03:52 [rsSync] replSet WARNING ignoring op on rollback no _id TODO : nimbus.system.indexes { ts: Timestamp 1337097600000|204, h: -3526710968279064473, op: "i", ns: "nimbus.system.indexes", o: { unique: true, name: "pascalquery_ns_key_start_ts_keyvals", key: { __ns__: 1, _key: 1, start_ts: 1, _keyval.a: 1, _keyval.b: 1, _keyval.c: 1, _keyval.d: 1, _keyval.e: 1, _keyval.f: 1, _keyval.g: 1, _keyval.h: 1 }, ns: "nimbus.wifi_daily_series", background: true } }
Tue May 15 19:03:54 [rsSync] replSet rollback found matching events at May 15 15:59:13:181
Tue May 15 19:03:54 [rsSync] replSet rollback findcommonpoint scanned : 6472020
Tue May 15 19:03:54 [rsSync] replSet replSet rollback 3 fixup

Потім пізніше чомусь відбувається інший відкат ...

Tue May 15 22:14:24 [rsSync] replSet rollback re-get objects: 13410 replSet too much data to roll back
Tue May 15 22:14:26 [rsSync] replSet syncThread: 13410 replSet too much data to roll back
Tue May 15 22:14:37 [rsSync] replSet syncing to: rs1m2.c9w.co:27017
Tue May 15 22:14:37 [rsSync] replSet syncThread: 13106 nextSafe(): { $err: "capped cursor overrun during query: local.oplog.rs", code: 13338 }
Tue May 15 22:14:48 [rsSync] replSet syncing to: rs1m2.c9w.co:27017
Tue May 15 22:15:30 [rsSync] replSet our last op time written: May 15 19:00:51:6
Tue May 15 22:15:30 [rsSync] replSet rollback 0
Tue May 15 22:15:30 [rsSync] replSet rollback 1
Tue May 15 22:15:30 [rsSync] replSet rollback 2 FindCommonPoint
Tue May 15 22:15:30 [rsSync] replSet info rollback our last optime:   May 15 19:00:51:6
Tue May 15 22:15:30 [rsSync] replSet info rollback their last optime: May 15 22:15:30:9
Tue May 15 22:15:30 [rsSync] replSet info rollback diff in end of log times: -11679 seconds
# More warnings matching the above warnings
Tue May 15 22:17:30 [rsSync] replSet rollback found matching events at May 15 15:59:13:181
Tue May 15 22:17:30 [rsSync] replSet rollback findcommonpoint scanned : 7628640
Tue May 15 22:17:30 [rsSync] replSet replSet rollback 3 fixup

Єдиною корисною інформацією про зворотні відкази, які я знайшов, є ці замітки, які не стосуються "застрягли в ситуації відкату". http://www.mongodb.org/display/DOCS/Replica+Sets+-+Rollbacks http://www.snailinaturtleneck.com/blog/2011/01/19/how-to-use-replica-set-rollbacks/

Коли екземпляр MongoDB переходить у стан відкату, а дані про відкат перевищують 300 Мб даних, вам потрібно вручну втрутитися. Він залишатиметься у відмовному стані до тих пір, поки ви не вживатимете заходів щодо збереження / видалення / переміщення цих даних, тоді (тепер уже вторинний) слід повторно змінити його, щоб привести їх у відповідність до основного. Це не повинно бути повним пересинхронізацією, але це найпростіший спосіб.

Кілька відкатів є симптомом, а не причиною проблеми. Відкат відбувається лише тоді, коли вторинний, який не синхронізувався (або через відставання, або через проблему з реплікацією), стає основним і приймає записи. Таким чином, проблеми, які спричиняють це в першу чергу, - це те, про що потрібно подбати - сам відкат - це те, з чим вам потрібно боротися як адміністратор - існує занадто багато потенційних підводних каменів для MongoDB, щоб автоматично узгодити дані.

Якщо ви хочете ще раз імітувати це для тестування, я окреслив, як це зробити тут:

http://comerford.cc/2012/05/28/simulating-rollback-on-mongodb/

Врешті-решт, ці дані будуть зберігатися в колекції (в локальній БД), а не скидатися на диск, що відкриє можливості ефективнішого впорядкування з ними:

https://jira.mongodb.org/browse/SERVER-4375

На даний момент, як тільки відбувається відкат, як ви виявили, необхідне втручання вручну.

Нарешті, посібник містить подібну інформацію до блогу Крістіни зараз:

https://docs.mongodb.com/manual/core/replica-set-rollbacks

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

Сподіваємось, хтось придумає кращу відповідь на це.