Apache Cassandra. Документация DataStax – Operations. Adding or removing nodes, data centers, or clusters. Replacing a dead node

Перевод статьи “Operations. Adding or removing nodes, data centers, or clusters. Replacing a dead node” из официальной документации DataStax.

Замена вышедшего из строя узла

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

Изначально вы должны подготовить и ввести в кластер другой узел, который будет использоваться вместо вышедшего из строя, а уже потом удалять его. Если узел был узлом-распространителем (seed node), см. Replacing a dead seed node ¹

Порядок действий

1) Ещё раз убедиться, что узел действительно вышел из строя и кластер его отображает как вне сети. Проверить это можно командой nodetool status ²:

На скриншоте команда отображает состояние одного узла как вне сети:

2) Запомните адрес вышедшего из строя узла, он понадобится на шаге 5.

3) Установите Cassandra на новый узел, но не запускайте службу.

Если вы используете Debian/Ubuntu, Cassandra запустится автоматически и вы должны будете остановить ³ службу и очистить ⁴ информацию тестового кластера, созданную по умолчанию при первом запуске.

4) Установите следующие настройки в файле cassandra.yaml и, в зависимости от типа используемого осведомителя (snitch), по необходимости задайте соответствующие настройки в конфигурационных файлах cassandra-topology.properties или cassandra-rackdc.properties:

– auto_bootstrap ⁵ – если эта опция установлена в “false”, вы должны выставить её в “true”. Эта опция не включена в cassandra.yaml изначально и по умолчанию имеет значение “true”.
– cluster_name ⁶ – имя кластера, к которому будет подключен новый узел.
– listen_address/broadcast_address ⁷ – обычно может быть пустым. В противном случае, используйте ip-адрес или имя хоста, которое будут использовать другие узлы кластера Cassandra, чтобы подключиться к текущему новому узлу.
– endpoint_snitch ⁸ – тип осведомителя, который Cassandra будет использовать, чтобы определять узлы и маршрутизировать запросы.
– num_tokens ⁹ – количество vnodes для присоединения к узлу. Если возможности аппаратного обеспечения различаются между узлами кластера, вы можете назначить им разные величины vnodes.
– seed_provider ¹⁰ – поле -seeds в этих настройках отображает список узлов, к какому-либо должен будет подключиться каждый новый узел для получения информации о кластере и инициализации процесса gossip.
Примечание: на узлах источниках не может выполняться процесс начальной загрузки (bootstrap ¹¹). Убедитесь, что новый подключаемый к кластеру узел не числится в списке -seeds. Не делайте все узлы узлами-источниками. Прочтите, пожалуйста, процесс межузлового взаимодействия (Internode communications (gossip) ¹²).
– Измените любые другие нестандартные настройки для вашего кластера в конфигурационных файлах cassandra.yaml и cassandra-topology.properties или cassandra-rackdc.properties. Используйте команду diff, чтобы найти и слить (по исходному файлу) любые различия между существующими и новыми узлами.

5) Запустите новый узел с выставленной опцией replace_address ¹³:

– При установке по умолчанию: добавьте эту опцию к файлу /usr/share/cassandra/cassandra-env.sh

JVM_OPTS=”$JVM_OPTS -Dcassandra.replace_address=address_of_dead_node

– При установке в произвольное расположение: запустите Cassandra со следующей опцией:

$ sudo bin/cassandra -Dcassandra.replace_address=address_of_dead_node

6) Если вы используете установку из репозиториев, после окончания процесса начальной инициализации (bootstrap) узла, удалите опции, которые вы добавляли на шаге 5.

Дальнейшие шаги

Удалите ip-адрес вышедшего из строя и уже удаленного узла из конфигурационных файлов cassandra-topology.properties или cassandra-rackdc.properties.

Внимание: подождите как минимум 72 часа, чтобы убедиться, что gossip ¹⁴ не использует информацию о старом узле. Если вы удалите эту информацию слишком рано, могут возникнуть проблемы.

Оригинал статьи – Replacing a dead node ¹⁵