# Повреждение данных

> Повреждение и восстановление данных etcd

---

Индекс LLMS: [llms.txt](/ru/llms.txt)

---

В etcd встроено автоматическое обнаружение повреждения данных, предотвращающее расхождение состояния участников.

> [!NOTE]
> В etcd 3.7 используйте приведённые ниже флаги функций и параметры длительности. Прежние экспериментальные флаги проверки повреждения данных удалены; см. [параметры конфигурации](/ru/docs/etcd/op-guide/configuration/#feature-gates).

## Включение обнаружения повреждения данных {#enabling-data-corruption-detection}

Повреждение данных можно обнаруживать с помощью:

* Начальной проверки, включаемой флагом `--feature-gates=InitialCorruptCheck=true`.
* Периодической проверки:
  * Хеша ревизии компактизации, включаемой флагом `--feature-gates=CompactHashCheck=true`.
  * Хеша последней ревизии, включаемой флагом `--corrupt-check-time`.

Начальная проверка выполняется при начальной инициализации участника etcd.
Участник сравнивает своё постоянное состояние с другими участниками и завершает работу при несовпадении.

Обе периодические проверки выполняются лидером уже работающего кластера.
Лидер сравнивает своё постоянное состояние с другими участниками и при несовпадении подаёт аварийный сигнал CORRUPT.
Обе проверки решают одну задачу, однако для баланса между производительностью и временем обнаружения стоит включить обе.

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

### Проверка хеша ревизии компактизации {#compacted-revision-hash-check}

Если проверка включена флагом `--feature-gates=CompactHashCheck=true`, она выполняется раз в минуту.
Период можно изменить флагом `--compact-hash-check-time` в формате: `1m` — раз в минуту, `1h` — раз в час.
Проверка расширяет компактизацию вычислением контрольной суммы, которую можно сравнить между участниками кластера.
Дополнительное сканирование базы данных не выполняется, поэтому стоимость проверки очень мала, но кластеру требуется регулярная компактизация.

### Проверка хеша последней ревизии {#latest-revision-hash-check}

Проверка включается флагом `--corrupt-check-time`; необходимо указать период выполнения в формате: `1m` — раз в минуту, `1h` — раз в час.
Из-за высокой стоимости рекомендуется период в несколько часов.
Для проверки вычисляется контрольная сумма путём сканирования всего содержимого etcd на заданной ревизии.

## Восстановление повреждённого участника {#restoring-a-corrupted-member}

Повреждённого участника можно восстановить тремя способами:

* Очистить постоянное состояние участника
* Заменить участника
* Восстановить весь кластер

После восстановления повреждённого участника аварийный сигнал CORRUPT можно удалить.

### Очистка постоянного состояния участника {#purge-member-persistent-state}

Состояние участника можно очистить следующим образом:

1. Остановите экземпляр etcd.
2. Создайте резервную копию каталога данных etcd.
3. Переместите подкаталог `snap` из каталога данных etcd.
6. Запустите `etcd` с `--initial-cluster-state=existing` и списком участников кластера в `--initial-cluster`.

После этого участник etcd должен загрузить актуальный снимок у лидера.

### Замена участника {#replace-member}

Участника можно заменить следующим образом:

1. Остановите экземпляр etcd.
2. Создайте резервную копию каталога данных etcd.
3. Удалите каталог данных.
4. Удалите участника из кластера командой `etcdctl member remove`.
5. Добавьте его обратно командой `etcdctl member add`.
6. Запустите `etcd` с `--initial-cluster-state=existing` и списком участников кластера в `--initial-cluster`.

### Восстановление всего кластера {#restore-whole-cluster}

Кластер можно восстановить, сохранив снимок текущего лидера и восстановив его на всех участниках.
Выполните `etcdctl snapshot save` для лидера и следуйте [процедуре восстановления кластера](/ru/docs/etcd/op-guide/recovery/).