Прямо перед тем, как мой вторичный ресурс устареет, в журнале сначала будет написано следующее:

2017-04-25T06:48:02.991+0000 I STORAGE  [DataFileSync] flushing mmaps took 13530ms  for 3150 files

Затем он дает мне странное устаревшее сообщение, обратите внимание на «b» в самом старом из доступных.

2017-04-25T06:50:03.815+0000 I REPL     [ReplicationExecutor] could not find member to sync from
2017-04-25T06:50:03.815+0000 E REPL     [rsBackgroundSync] too stale to catch up -- entering maintenance mode
2017-04-25T06:50:03.815+0000 I REPL     [rsBackgroundSync] our last optime : (term: 6, timestamp: Apr 25 06:32:08:333)
2017-04-25T06:50:03.815+0000 I REPL     [rsBackgroundSync] oldest available is (term: 6, timestamp: Apr 25 06:32:08:3b1)
2017-04-25T06:50:03.815+0000 I REPL     [rsBackgroundSync] See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember

Я использую монгодб 3.2.8. Ожидается ли, что b будет там? Ожидается ли это?

2
user3820901 25 Апр 2017 в 22:09

1 ответ

Нет, не ожидается. Значения временной метки должны быть десятичными, а не шестнадцатеричными, а значение мс 3b1 больше 333.

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

0
JJussi 26 Апр 2017 в 12:51