# Уникнення зомбі-учасників кластера при оновленні до etcd v3.6

LLMS index: [llms.txt](/llms.txt)

---

*Ця стаття була нещодавно опублікована в [офіційному блозі etcd](https://etcd.io/blog/2025/zombie_members_upgrade/)*. [Основний висновок](https://etcd.io/blog/2025/zombie_members_upgrade/#key-takeaway)? Завжди оновлюйтеся до etcd v3.5.26 або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та дозволяж уникати появі зомбі-учасників.

## Підсумок проблеми {#issue-summary}

Нещодавно спільнота etcd вирішила проблему, яка може виникнути, коли користувачі [оновлюються з v3.5 до v3.6].  Цей баг може призвести до того, що кластер повідомлятиме про "зомбі-учасників", які є вузлами etcd, що були видалені з кластера бази даних деякий час тому, і які знову зʼявляються та приєднуються до консенсусу бази даних. Кластер etcd потім стає неоперабельним, доки ці зомбі-учасники не будуть видалені.

У etcd v3.5 та раніше v2store був джерелом істини для даних про членство, навіть якщо v3store також був присутній. Як частина нашого [плану припинення підтримки v2store], у v3.6 v3store стає джерелом істини для інформації про членство в кластері. Зі [звіту про баг] ми дізналися, що в деяких старих кластерах v2store та v3store могли стати несумісними.  Ця несумісність проявляється після оновлення як поява старих, видалених "зомбі" учасників кластера, які знову зʼявляються в кластері.

## Виправлення та шлях оновлення {#the-fix-and-upgrade-path}

Ми додали [механізм у etcd v3.5.26] для автоматичної синхронізації v3store з v2store, гарантуючи, що уражені кластери будуть відновлені перед оновленням до 3.6.x.

Щоб підтримати багатьох користувачів, які зараз оновлюються до 3.6, ми надали наступний безпечний шлях оновлення:

1. Оновіть ваш кластер до [v3.5.26] або пізнішої версії.
2. Зачекайте та підтвердіть, що всі учасники є справними після оновлення.
3. Оновіться до v3.6.

Ми не можемо надати безпечний обхідний шлях для користувачів, які мають перепони, що перешкоджають оновленню до v3.5.26.  Таким чином, якщо v3.5.26 недоступна з вашого джерела пакунків або постачальника, ви повинні відкласти оновлення до v3.6, доки вона не стане доступною.

## Додаткові технічні деталі {#additional-technical-detail}

**Інформація нижче надається лише для довідки.  Користувачі можуть слідувати безпечному шляху оновлення без знання наступних деталей.**

Ця проблема виникає з кластерами, які працюють у з операційним навантаженням на etcd v3.5.25 або ранішої версії. Це побічний ефект додавання та видалення учасників з кластера або відновлення кластера після збою. Це означає, що проблема є більш імовірною, чим старішим є кластер etcd, але її не можна виключити для будь-якого користувача незалежно від віку кластера.

Супроводжувачі etcd, працюючи зі авторами повідомлення про проблему, виявили три можливі причини виникнення проблеми на основі симптомів та аналізу коду та логів etcd:

1. **Баг у `etcdctl snapshot restore` (v3.4 та старих версіях)**: Під час відновлення знімка за допомогою `etcdctl snapshot restore`, etcdctl мав видалити наявих учасників перед додаванням нових. У v3.4 через баг старі учасники не були видалені, що призвело до появи зомбі-учасників. Зверніться до [коментаря щодо etcdctl].
2. **`--force-new-cluster` у v3.5 та попередніх версіях**: У рідкісних випадках примусове створення нового кластера з одним учасником не повністю видаляло старих учасників, залишаючи зомбі. Проблема була [вирішена](https://github.com/etcd-io/etcd/pull/20339) у v3.5.22. Будь ласка, зверніться до [цього PR](https://github.com/etcd-io/raft/pull/300) у проєкті Raft для детальної технічної інформації.
3. **Увімкнено --unsafe-no-sync**: Якщо `--unsafe-no-sync` увімкнено, у рідкісних випадках etcd може зберегти зміну членства у v3store, але аварійно завершити роботу перед записом у WAL, спричиняючи несумісність між v2store та v3store. Це проблема для кластерів з одним учасником. Для кластерів з багатьма учасниками примусове створення нового кластера з одним учасником з даних аварійного вузла може призвести до появи зомбі-учасників.

<div class="alert alert-info" role="alert"><div class="h4 alert-heading" role="heading">Примітка</div>


`--unsafe-no-sync` загалом не рекомендується, оскільки може порушити гарантії, надані протоколом консенсусу.
</div>


Важливо, що можуть бути інші причини для несумісності даних членства v2store та v3store, які ми ще не виявили. Це означає, що ви не можете припустити, що ви в безпеці лише тому, що не виконували жодної з трьох дій вище. Після оновлення користувачів до etcd v3.6 v3store стає джерелом даних про членство, і подальша несумісність неможлива.

Досвідчені користувачі, які хочуть перевірити сумісність між v2store та v3store, можуть слідувати крокам, описаним у цьому [коментарі]. Ця перевірка не потрібна для виправлення проблеми, і SIG etcd не рекомендує обходити оновлення v3.5.26 незалежно від результатів перевірки.

## Основний висновок {#key-takeaway}

Завжди оновлюйтеся до [v3.5.26] або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та уникає появі зомбі-учасників.

## Подяки {#acknowledgements}

Ми хотіли б подякувати [Christian Baumann] за повідомлення про цю давню проблему оновлення. Його звіт та подальша робота допомогли привернути нашу увагу до проблеми, щоб ми могли дослідити та вирішити її.

[оновлюються з v3.5 до v3.6]: https://etcd.io/docs/v3.6/upgrades/upgrade_3_6/
[плану припинення підтримки v2store]: https://github.com/etcd-io/etcd/issues/12913
[звіту про баг]: https://github.com/etcd-io/etcd/issues/20967
[механізм у etcd v3.5.26]: https://github.com/etcd-io/etcd/pull/20995
[v3.5.26]: https://github.com/etcd-io/etcd/releases/tag/v3.5.26
[коментаря щодо etcdctl]: https://github.com/etcd-io/etcd/issues/20967#issuecomment-3618010356
[Christian Baumann]: https://github.com/thechristschn
[коментарі]: https://github.com/etcd-io/etcd/issues/20967#issuecomment-3590609775