MongoDB Replica Set SECONDARY Застрял в состоянии «ROLLBACK»

Во время недавнего автоматического обновления нашего mongodb PRIMARY, когда PRIMARY ушел навсегда, перешел в состояние ROLLBACK.

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

Я бы хотел, чтобы кто-то помог проанализировать, что именно пошло не так.

  • В наших журналах появляются два разных отката. Это тот случай, или он занял 3 часа?
  • Если первый откат (в 19:00) был успешным, почему ничего не появилось в каталоге ou rollback?
  • Любое догадки о причине всех этих предупреждений? Может ли это быть связано с откатом отката?
  • Мы потеряли 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/

11 голосов | спросил Chris W. 17 Mayam12 2012, 00:02:56

2 ответа


7

Когда экземпляр MongoDB переходит в состояние отката, а данные отката превышают 300 МБ данных, вы должны вручную вмешаться. Он будет оставаться в состоянии отката до тех пор, пока вы не предпримете действие для сохранения /удаления /перемещения этих данных, затем (затем вторичный) следует повторно синхронизировать, чтобы вернуть его в соответствие с основным. Это не обязательно полная пересинхронизация, но это самый простой способ.

Несколько откатов являются симптомом, а не причиной проблемы. Откат происходит только тогда, когда вторичный, который не синхронизировался (из-за отставания или проблемы с репликацией), становится основным и берет записи. Таким образом, проблемы, которые приводят к тому, что должно произойти в первую очередь, - это то, о чем нужно позаботиться - сам откат - это то, что вам нужно иметь в качестве администратора, слишком много потенциальных ошибок для MongoDB для автоматического согласования данных.

Если вы хотите снова имитировать это для целей тестирования, я изложил, как это сделать:

http://comerford.cc/2012/05/28 /имитируя-откат-на-MongoDB /

В конце концов, эти данные будут храниться в коллекции (в локальной БД), а не сбрасываться на диск, что даст возможность более эффективно работать с ней:

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

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

Наконец, руководство содержит аналогичную информацию в блоге Кристины:

https://docs.mongodb.com/manual/core/replica -SET-откаты

ответил Adam C 7 J0000006Europe/Moscow 2012, 21:08:05
2

«Решение», которое мы закончили, полностью уничтожило нашу базу данных на машине, которая застряла в режиме ROLLBACK и разрешила blanked SECONDARY для повторной синхронизации с мастером. Это кажется субоптимальным решением, потому что, как я уже мог сказать, у нас все еще было много места на oplog, поэтому машины должны иметь , теоретически, удалось повторно синхронизировать.

Надеюсь, кто-то придумает лучший ответ для этого.

ответил Chris W. 21 Maypm12 2012, 23:13:31

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132