Как узнать, завершен ли ремонт nodetool?

У меня есть кластер 2 node apache cassandra (2.0.3) с коэффициентом rep от 1. Я изменяю множитель rep на 2, используя следующую команду в cqlsh

ALTER KEYSPACE "mykeyspace" WITH REPLICATION =   { 'class' : 'SimpleStrategy', 'replication_factor' : 2 };

Затем я попытался запустить рекомендуемый "ремонт nodetool" после выполнения этого типа alter.

Проблема в том, что эта команда иногда заканчивается очень быстро. Когда он заканчивается, он обычно говорит "Потерянное уведомление...", а код выхода не равен нулю.

Поэтому я просто повторяю этот "ремонт nodetool" до тех пор, пока он не завершится без ошибок. Я также проверяю, что "состояние nodetool" сообщает о ожидаемом дискового пространства для каждого node. (с номером rep 1, каждый node скажет около 7 ГБ каждый, и я ожидаю, что после восстановления nodetool каждый из них будет составлять 14 ГБ каждый, если не использовать кластер в среднем)

Есть ли более правильный способ определить, что "ремонт nodetool" завершен в этом случае?

Ответ 1

Вообще говоря, вы можете контролировать операцию nodetool repair с помощью двух команд nodetool:

compactionstats
NetStats

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

Это проверяет активные вычисления Merkle Tree:

$ nodetool compactionstats
pending tasks: 0
Active compaction remaining time :        n/a

Резервные потоки могут отслеживаться с помощью:

$ nodetool netstats

Фактически TheLastPickle Аарон Мортон предлагает использовать следующую команду Bash script/для мониторинга любых активных потоков восстановления:

while true; do date; diff <(nodetool -h localhost netstats) <(sleep 5 && nodetool -h localhost netstats); done

DataStax опубликовал на своих форумах поддержки сообщения о устранении неполадок при ремонте. Если у вас есть какие-либо потоки восстановления, вы можете увидеть их с помощью netstats. Это может произойти, если один из ваших узлов становится недоступным в процессе восстановления. Чтобы отслеживать конкретные операции восстановления, вы можете проверить свой файл журнала на следующие записи:

DEBUG [WRITE-/172.30.77.197] 2013-05-03 12: 43: 09,107 OutboundTcpConnection.java(строка 165) ошибка записи в /172.30.77.197 java.net.SocketException: Соединение reset

Обратите внимание, что сеансы ремонта также должны быть обозначены в вашей системе .log:

[repair #02fc68f0-210c-11e7-aa88-c35a9a02c19a] Starting...

[repair #02fc68f0-210c-11e7-aa88-c35a9a02c19a] Completed...

Ответ 2

Резервные потоки можно отслеживать с помощью опции --trace при запуске команды восстановления:

nodetool repair --trace <key_space> <table>

Ответ 3

Мы также можем следить за ходом ремонта в консоли Opscenter в разделе Активности.