Процедура восстановления после неудачной загрузки Cassandra

Question

Сценарий: новый узел был добавлен в кластер Cassandra. Узел был сплетничен, ему был назначен диапазон токенов, но по ошибке Cassandra была вручную отключена через "cassandra stop service" до того, как начался какой-либо поток от одноранговых узлов. Мы также никогда не видели узел в статусе UJ. После перезапуска этого узла мы видим его в режиме ООН, и файлы журнала коммитов растут, но в каталоге данных не так много данных. Один из наших KS имеет RF=1 на нем.

Вопрос: Какова лучшая процедура, чтобы оправиться от этого? Проблема не в том, чтобы потерять данные из пространства ключей RF=1 и обеспечить правильную работу потоковой передачи данных на новый узел.

Answer 1

Вы можете добавить новый узел двумя способами:

1. Установите для auto_bootstrap нового узла значение true и присоединитесь к кластеру.
2. Установите для auto_bootstrap нового узла значение false и присоединитесь к кластеру. Вручную выполните восстановление для потоковой передачи данных и исправьте свои реплики в своем узле.

После того, как вы добавили новый узел. Ваши старые узлы будут иметь старые токены и некоторые старые данные, которые не будут удалены, пока вы не выполните очистку старых узлов после успешного добавления нового узла.

В вашем случае вы по ошибке остановили новый узел посередине. Таким образом, вы можете выполнить следующие шаги, чтобы исправить реплики и проверить состояние вашего nodetool, чтобы убедиться, что нагрузка распределяется на новый узел:

1. Сделай полный ремонт. (В случае Cassandra 2.2 и выше по умолчанию он работает в режиме инкрементного восстановления. Поэтому проверьте и выполните полный ремонт, а не инкрементный ремонт).
2. Проверьте, что данные о состоянии nodetool передаются в потоковом режиме и нагрузка распределяется на новый узел