Reaper не удалось запустить восстановление на узлах Кассандры

#cassandra #cassandra-3.0

Вопрос:

После того, как Reaper не удалось запустить ремонт на 18 узлах кластера Cassandra, я выполнил полный ремонт каждого узла, чтобы устранить проблему с неудачным ремонтом, после полного ремонта Reaper успешно выполнил, но через несколько дней снова не удалось запустить Reaper, я вижу следующую ошибку в system.log

 ERROR [RMI TCP Connection(33673)-10.196.83.241] 2021-09-01 09:01:18,005 RepairRunnable.java:276 - Repair session 81540931-0b20-11ec-a7fa-8d6977dd3c87 for range [(-606604147644314041,-98440495518284645], (-3131564913406859309,-3010160047914391044]] failed with error Terminate session is called
java.io.IOException: Terminate session is called
        at org.apache.cassandra.service.ActiveRepairService.terminateSessions(ActiveRepairService.java:191) ~[apache-cassandra-3.11.0.jar:3.11.0]

INFO  [Native-Transport-Requests-2] 2021-09-01 09:02:52,020 Message.java:619 - Unexpected exception during request; channel = [id: 0x1e99a957, L:/10.196.18.230:9042 ! R:/10.254.252.33:62100]
io.netty.channel.unix.Errors$NativeIoException: readAddress() failed: Connection timed out
 

в nodetool tpstats я вижу некоторые незавершенные задачи

 Pool Name                         Active   Pending
ReadStage                              0         0
Repair#18                              3        90
ValidationExecutor                     3         3 
 

Также в nodetool compactionstats нем есть 4 незавершенных задания:

 -bash-4.2$ nodetool compactionstats
pending tasks: 4
- Main.visit: 1
- Main.post: 1
- Main.stream: 2
 

Мой вопрос в том, почему даже после полного ремонта reaper все еще выходит из строя? и какова основная причина незавершенного ремонта?

PS: версия Reaper 2.2.3, не уверен, что это ошибка в Reaper!

Ответ №1:

Скорее всего, у вас недостаточно сегментов в определении ремонта Reaper, или тайм-аут по умолчанию (30 минут) слишком мал для вашего ремонта. Сегменты (и связанный с ними сеанс восстановления) завершаются, когда они достигают тайм-аута, чтобы избежать застрявшего ремонта. При неправильной настройке это может привести к поведению, которое вы наблюдаете. Nodetool не устанавливает тайм-аут для ремонта, что объясняет, почему он проходит там. Хорошей новостью является то, что ничто не помешает ремонту пройти с Reaper после правильной настройки.

В настоящее время мы работаем над адаптивным ремонтом, чтобы Reaper справлялся с этой ситуацией автоматически, но в то же время вам нужно будет справиться с этим вручную. Проверьте список сегментов в пользовательском интерфейсе и примените следующее правило:

  • Если у вас отказывает менее 20% сегментов, удвоьте время ожидания, изменив hangingRepairTimeoutMins значение в конфигурационном yaml.
  • Если у вас более 20% сегментов выходят из строя, удвоьте количество сегментов.

Как только ремонт пройдет не менее двух раз, проверьте максимальную продолжительность сегментов и дополнительно настройте количество сегментов так, чтобы они длились не более 15 минут.

Предполагая, что вы еще не используете Cassandra 4.0, теперь, когда вы запустили восстановление через nodetool, у вас есть sstable, которые помечены как восстановленные, как и при инкрементном восстановлении. Это создаст проблему, так как ремонт Reaper не помечает sstables как отремонтированные, и теперь у вас есть два разных пула sstables (отремонтированных и не отремонтированных), которые нельзя уплотнить вместе. Вам нужно будет использовать sstablerepairedset инструмент для пометки всех sstables как неподготовленных, чтобы вернуть все sstables в один пул. Пожалуйста, прочтите документацию, чтобы узнать, как этого добиться.

Ответ №2:

Может произойти ряд вещей, например, Reaper не может подключиться к узлам через JMX (по какой-либо причине). С помощью предоставленной вами ограниченной информации невозможно диагностировать проблему.

Вам нужно будет проверить журналы Жнецов на наличие подсказок о первопричине.

В качестве примечания, это не связано с ремонтом и представляет собой клиент/драйвер/приложение, подключающееся к узлу на порту CQL:

 INFO  [Native-Transport-Requests-2] 2021-09-01 09:02:52,020 Message.java:619 - Unexpected exception during request; channel = [id: 0x1e99a957, L:/10.196.18.230:9042 ! R:/10.254.252.33:62100]
io.netty.channel.unix.Errors$NativeIoException: readAddress() failed: Connection timed out
 

Ваше здоровье!