MoveChunk не смог включить TO-shard в передачу данных: не может принимать новые куски, потому что

У меня есть производственный кластер MongoDb с 2.6.5, который я недавно перенес из двух-трех осколков. Я работала как два осколка примерно на год. Каждый осколок представляет собой набор реплик с 3 серверами, и у меня есть одна коллекция. Осколок коллекции около 240G, и с новым осколком я теперь равномерно распределены куски 2922 на каждый осколок. Моя производственная среда работает очень хорошо. Нет проблем с доступом к данным.

[Примечание: 1461 должно быть числом кусков, перемещенных из rs0 и shard1, чтобы сделать 2922 на shard2.]

Мое намерение заключалось в том, чтобы очертить еще три коллекции, поэтому я начал с одного и ожидал, что он распространится по осколкам. Но нет - я закончил с этой повторяющейся ошибкой:

2014-10-29T20: 26: 35.374 + 0000 [Балансировка] moveChunk результат: {причина: {ok: 0.0, errmsg: "не может принимать новые куски, потому что все еще 1461 удалений из предыдущей миграции" },

ok: 0.0, errmsg: "moveChunk не смог задействовать TO-shard при передаче данных: не может принимать новые куски, потому что еще осталось 1461 удалений из предыдущей миграции" }

2014-10-29T20: 26: 35.375 + 0000 [Балансир] перемещение балансира не удалось: {причина: {ok: 0.0, errmsg: "не может принимать новые куски, потому что все еще 1461 удалений из предыдущей миграции" },

ok: 0.0, errmsg: "moveChunk не смог задействовать TO-shard в передаче данных: не может принимать новые куски, потому что все еще 1461 удалений из предыдущей миграции" } from: rs0 to: shard1 chunk: min: { account_id: MinKey} max: {account_id: -9218254227106808901}

С небольшим исследованием я решил, что должен просто дать ему некоторое время, так как, очевидно, ему нужно очистить вещи после переезда. Я запустил sh.disableBalancing( "collection-name" ), чтобы остановить ошибки от попыток очертить новую коллекцию. sh.getBalancerState показывает true, как и sh.isBalancerRunning. Однако я дал ему 24 часа, и сообщение об ошибке одно и то же. Я бы подумал, что он очистил бы/удалил бы хотя бы 1 из 1461, который нужно удалить.

Это обычное поведение сейчас в мире 2.6? Должен ли я обрабатывать все мои собранные коллекции каждый раз, когда я выращиваю окружающую среду другим осколком?
Любая идея, как получить эту очистку? или я должен просто уйти из основного на shard1, что кажется проблемой?
Если я уйду из основного, у меня все еще есть файлы для удаления/очистки в любом случае? Или это позаботится о вещах, чтобы я мог начать собирать новые коллекции?

Заранее благодарим за любые идеи.

Ответ 1

Это не так часто встречается в этой проблеме, но я видел, что это происходит спорадически.

Лучшее исправление, которое нужно предпринять, заключается в том, чтобы спустить основной из привязанного TO-осколка, который очистит удаление фона. Нити для удаления существуют только в текущем первичном (они будут реплицироваться из этого первичного через oplog по мере их обработки). Когда вы отключаете его, он становится вторичным, потоки больше не могут писать, и вы получаете новый первичный элемент без ожидающих удаления. Возможно, вы захотите перезапустить прежний первичный элемент после шага вниз, чтобы очистить старые курсоры, но это обычно не является срочным.

После этого вы останетесь с большим количеством потерянных документов, которые могут быть адресами с помощью команды cleanUpOrphaned, которую я бы рекомендовал использовать в низкое время трафика (если у вас есть такие времена).

Для справки, если это повторяющаяся проблема, то, скорее всего, первичные ресурсы немного борются с нагрузкой, и чтобы избежать очередей удалений, вы можете установить _waitForDelete для балансира равным true (false по умолчанию) следующим образом:

use config
db.settings.update(
   { "_id" : "balancer" },
   { $set : { "_waitForDelete" : true } },
   { upsert : true }
)

Это означает, что каждая миграция происходит медленнее (возможно, значительно), но не приведет к накоплению фоновых удалений.