SystemdDoctor
служба не работает кластеры состояние

etcd: узел не входит в кластер после переустановки

Каталог данных узла помнит, к какому кластеру он относится. После переустановки или клонирования образа идентификаторы расходятся, и узел получает отказ. Удалять каталог данных наугад опасно: на нём может лежать единственная актуальная копия состояния.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Каталог данных остался от другого кластера

    Узел читает свой каталог и видит чужой идентификатор кластера. Присоединение отвергается.

  2. Образ клонирован вместе с данными

    Клонирование машины копирует и каталог данных, и идентификатор участника. Два узла заявляют одно и то же.

  3. Адреса объявления не совпадают с настройками кластера

    Участник объявляет себя по одному адресу, а кластер знает его по другому. Соединение не устанавливается.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Сообщения о присоединении к кластеру.

journalctl -u etcd -n 40 --no-pager | grep -iE "mismatch|member|raft"

Список участников с их адресами и идентификаторами.

sudo etcdctl member list 2>/dev/null

Здоровье узлов кластера.

sudo etcdctl endpoint health 2>/dev/null

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Каталог данных остался от другого кластера
Почему происходит
Узел читает свой каталог и видит чужой идентификатор кластера. Присоединение отвергается.
Как проверить
Посмотрите сообщения службы и каталог данных. 
journalctl -u etcd -n 30 --no-pager | grep -iE "cluster ID mismatch|member"
sudo ls -l /var/lib/etcd/ 2>/dev/null
Как исправить
Убедитесь, что актуальное состояние есть на других узлах, затем очистите каталог данных только этого узла и добавьте его в кластер как нового участника.
2. Образ клонирован вместе с данными
Почему происходит
Клонирование машины копирует и каталог данных, и идентификатор участника. Два узла заявляют одно и то же.
Как проверить
Сравните идентификаторы участников на узлах. 
sudo etcdctl member list 2>/dev/null; cat /etc/machine-id
Как исправить
Перед клонированием очищайте каталог данных и идентификатор машины. Уникальность идентификатора машины важна и для самого systemd.
3. Адреса объявления не совпадают с настройками кластера
Почему происходит
Участник объявляет себя по одному адресу, а кластер знает его по другому. Соединение не устанавливается.
Как проверить
Сравните адреса объявления и список участников. 
systemctl cat etcd | grep -iE "advertise|initial-cluster"
sudo etcdctl member list 2>/dev/null
Как исправить
Приведите адреса объявления в соответствие со списком участников. Изменение адреса участника делается штатной командой, а не правкой настроек.

Пример вывода

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

etcd[5200]: request cluster ID mismatch (got 8e9f1a2b3c4d5e6f want 1a2b3c4d5e6f7081)
etcd[5200]: rejecting connection from member with mismatched cluster ID
systemd[1]: etcd.service: Main process exited, code=exited, status=1/FAILURE

Связанные ошибки

Источники

  • Документация etcd: работа с участниками кластера документация программы
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено запуском узла с каталогом данных от другого кластера.     собственная проверка, systemd 255
    сверено 15 сентября 2026