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

Question

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

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

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

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

Config:

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

Вход от главного процесса shard1:

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

Вход от главного процесса shard2:

Вт 3 декабря 14: 52: 25,302 [conn1369472] Передача данных moveChunk прогресс: {активные: истинно, нс: "xxx.xxx", из: "shard2/mongo2: 27018, mongob2: 27018", мин: {shardkey: ObjectId ('4fd2025ae087c37d32039a9e')}, макс: {shardkey: ObjectId ('4fd2035ae087c37f04014a79')}, shardKeyPattern: {shardkey: 1,0}, state: «catchup», counts: {cloned: 22773, clonedBytes: 36323458, catchup: 0, stable: 0}, ok: 1.0} my mem used: 0

Обновление: Я подтвердил, что удаление slaveDelay привело к тому, что балансир снова работает. Как только они встали, чтобы ускорить движение кусков. Таким образом, проблема, похоже, связана с slaveDelay. Я также подтвердил, что балансир работает с «secondaryThrottle»: 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

Балансинер должным образом ожидает, чтобы НАЗНАЧЕНИЕ набора реплик целевого осколка перенесло документы, прежде чем инициировать удаление этих документов на исходном осколке.

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

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

Answer 2

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

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

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