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

Question

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

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

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

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

Конфигурация:

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

Журнал из главного процесса shard1:

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

Журнал из главного процесса shard2:

Вт, 3 декабря 14:52: 25.302 [conn1369472] Передача данных moveChunk прогресс:{ активный:верно, ns:"xxx.xxx", из:"осколок2/монго2:27018, монгоб2:27018", мин.:{ ключ - фрагмент:ObjectId('4fd2025ae087c37d32039a9e') }, не более:{ ключ - фрагмент:ObjectId('4fd2035ae087c37f04014a79') }, шаблон shardKeyPattern:{ ключ - фрагмент:1.0 }, состояние:"кетчуп", считается:{ клонированный:22773, Клонированные байты:36323458, кетчуп:0, устойчивый:0 }, ок:1.0 } мой мем использовался:0

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

Осколок 2:

Вт, 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:Идентификатор объекта('4ff12a5eddf2b32dff1e7bea') }

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

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

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

Answer 1

Балансировщик правильно ждет, пока большая часть реплики набора отделения назначения будет мигрировать документы, прежде чем инициировать удаление этих документов на Source Shard.

Проблема в том, что у вас есть четыре участника в вашем наборе реплик (Master, Slave, 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 (он будет воссоздан заново).