Тайм-аут балансировщика MongoDB с задержкой реплики

Question

У нас есть установка двух осколков mongodb. Каждый осколок содержит хозяина, раба, раба с задержкой раба 24 ч и арбитра. Однако балансировщик не может перенести какие-либо осколки, ожидая миграции задержанного ведомого. Я попытался установить для _secondaryThrottle значение false в конфигурации балансировщика, но проблема не устранена.

Кажется, что миграция продолжается в течение дня, а затем завершается неудачей (тонна ожидания подчиненных сообщений в журналах). В конце концов он сдается и начинает новую миграцию. В сообщении говорится, что ожидание 3 ведомых, но задержка ведомого скрыта и равен 0, поэтому он должен ждать этого. И если _secondaryThrottle сработал, он не должен ждать никакого рабского права?

Так было уже несколько месяцев, поэтому конфиг должен был быть перезагружен на всех mongoses. Некоторые монгозы, работающие на балансире, недавно были перезапущены.

У кого-нибудь есть идеи, как решить проблему, у нас не было этих проблем до запуска отложенного раба, но это только наша теория.

Config:

{ "_id" : "balancer", "_secondaryThrottle" : false, "stopped" : false }

Вход из основного процесса shard1:

[migrateThread] предупреждение: выполнить миграцию, ожидая 3 подчиненных для 'xxx.xxx' { shardkey: ObjectId('4fd2025ae087c37d32039a9e') } -> {shardkey: ObjectId('4fd2035ae087c37f04014a79') }, ожидающих: 529dc9d9: 9 репликация, чтобы наверстать упущенное перед входом в критическую секцию

Вход из основного процесса shard2:

Вт Дек 3 14:52:25.302 [conn1369472] Ход передачи данных moveChunk: { active: true, ns: "xxx.xxx", из: "shard2/mongo2:27018,mongob2:27018", мин: { shardkey: ObjectId('4fd2025ae087c37d32039a9e') }, не более: { shardkey: ObjectId('4fd2035ae087c37f04014a79') }, shardKeyPattern: { shardkey: 1.0 }, состояние: "catchup", количество: {клонировано: 22773, клонировано: 0458, 363: 363: 3632: 363, 363: 3632 0}, хорошо: 1.0} моя память использовала: 0

Обновление: я подтвердил, что удаление slaveDelay снова заработало балансировщиком. Как только они набрали скорость, куски переместились. Таким образом, проблема, похоже, связана с slaveDelay. Я также подтвердил, что балансировщик работает с "secondThrottle": false. Похоже, это все равно ждет рабов.

Shard2:

Вт дек 10 11:44:25.423 [migrateThread] предупреждение: выполнить миграцию в ожидании 3 рабов для 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea'} для ожидания)) 52a6f089:81

Вт дек 10 11:44:26.423 [migrateThread] Ожидание, пока репликация наверстает упущенное, прежде чем войти в критическую секцию

Вт дек 10 11:44:27.423 [migrateThread] Ожидание, когда репликация наверстает упущенное, прежде чем войти в критическую секцию

Вт дек 10 11:44:28.423 [migrateThread] Ожидание, пока репликация наверстает упущенное, прежде чем войти в критическую секцию

Вт дек 10 11:44:29.424 [migrateThread] Ожидание, пока репликация наверстает упущенное, прежде чем войти в критическую секцию

Вт дек 10 11:44:30.424 [migrateThread] Ожидание, пока репликация перехватит работу, прежде чем войти в критическую секцию

Вт дек 10 11:44:31.424 [migrateThread] Ожидание, когда репликация наверстает упущенное, прежде чем войти в критическую секцию

Вт дек 10 11:44:31.424 [migrateThread] коммит миграции успешно сброшен во вторичные файлы для 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea')

Вт дек 10 11:44:31.425 [migrateThread] коммит миграции перенесен в журнал для 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }

Вт дек 10 11:44:31.647 [migrateThread] коммит миграции успешно сброшен во вторичные файлы для 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea')

Вт дек 10 11:44:31.667 [migrateThread] коммит миграции перенесен в журнал для 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }

Answer 1

Балансировщик должным образом ожидает, пока БОЛЬШИНСТВО набора реплик сегмента назначения не перенесет документы для переноса, прежде чем инициировать удаление этих документов в исходном сегменте.

Проблема в том, что в вашем наборе реплик есть ЧЕТЫРЕ участника (ведущий, ведомый, подчиненный с задержкой на 24 часа и арбитр). Это означает, что три - это большинство. Я не уверен, почему вы добавили арбитра, но если вы удалите его, то ДВА будет большинством, и балансировщику не придется ждать задержанного раба.

Альтернативный способ достижения того же результата - настроить задержанного ведомого с votes:0 собственности и оставить арбитра в качестве третьего узла голосования.

Answer 2

Какую версию вы используете? Существует известная ошибка в 2.4.2 и ниже, а также в 2.2.4 и ниже, которая приводит к неправильному подсчету числа вторичных объектов в наборе (и, следовательно, делает невозможным выполнение записи по умолчанию w: Большинство для миграции). Это ошибка (исправлена ​​в 2.4.3+ и 2.2.5+):

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

Отключение вторичного газа должно быть правильным решением, но вы можете захотеть сделать flushRouterConfig на любом mongos процессы (или просто перезапустите все mongos процессы), чтобы убедиться, что настройки вступают в силу для ваших миграций, особенно если они используют ежедневный перерыв. В качестве еще одного потенциального исправления до обновления вы также можете удалить коллекцию local.slaves (она будет воссоздана).