Аварийный режим#

Что такое аварийный режим#

Аварийный режим — особое состояние узла, при котором его функциональность ограничена. Узлы в этом режиме не присоединяются к кластеру и остаются изолированными до завершения аварийного режима.

Узлы могут переходить в аварийный режим при перезапуске в ситуациях, которые могут привести к повреждению данных, или если требуемые действия могут повлиять на работу кластера, когда узел остается в его составе. Для вхождения узлов в аварийный режим требуется перезапуск. Подробнее об этом написано ниже в разделе «Причины перехода в аварийный режим».

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

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

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

Процесс выполнения задач в аварийном режиме#

Когда узел получает команду на вход в аварийный режим, он создает файл maintenance_tasks.mntc в рабочей директории. Если этот файл присутствует после перезапуска, узел автоматически входит в аварийный режим и пытается выполнить необходимые задачи.

Список задач:

Задача	Обслуживание	Выполняется автоматически при запуске
`defragmentationMaintenanceTask`	Запланирована дефрагментация узла	Да
`indexRebuildMaintenanceTask`	Запланировано восстановление индексов данных	Да

После завершения задач файл maintenance_tasks.mntc удаляется. Узел продолжает работать в аварийном режиме до ручного перезапуска.

Также переход в аварийный режим можно инициировать вручную в плановом порядке. Подробнее об этом написано ниже в разделе «Плановый аварийный режим».

Причины перехода в аварийный режим#

Возможное повреждение данных#

Если узел с включенной персистентностью и отключенным WAL-журналированием аварийно завершает работу во время создания контрольной точки (checkpointing), он не сможет надежно определить, произошло ли повреждение данных. В этом случае при следующем запуске узел обнаружит возможное повреждение данных и завершит работу. При следующем перезапуске узел войдет в аварийный режим и будет ожидать действий администратора.

Для решения проблемы:

Перезапустите узел — он войдет в аварийный режим.
Используйте скрипт управления для выполнения команды control.sh --persistence clean corrupted, чтобы удалить потенциально поврежденные данные. Также можно сохранить резервные копии с помощью команды control.sh --persistence backup corrupted.

Примеры команд:
```
control.sh --host {host} --port {port} --persistence backup corrupted
control.sh --host {host} --port {port} --persistence clean corrupted
```
IP-адрес и порт узла можно узнать из его логов.
После завершения задачи перезапустите узел — он возобновит процесс создания контрольной точки (checkpointing).

Узел останется в аварийном режиме, пока потенциально поврежденные данные не будут удалены. Данные можно удалить вручную и затем перезапустить узел. В этом случае узел восстановит утраченные данные из резервных копий на других узлах кластера с помощью процесса ребалансировки. Подробнее об этом процессе написано в разделе «Ребалансировка» документа «Руководство прикладного разработчика».

После удаления данных узел выйдет из аварийного режима и присоединится к кластеру при следующем перезапуске.

Плановый аварийный режим#

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

Команды, которые запускают аварийный режим при следующем перезапуске:

control.sh --defragmentation — дефрагментация узла;
control.sh --cache indexes_force_rebuild — восстановление индексов данных.

Подробнее об этих командах написано в разделе «Утилита control» в подразделах «Дефрагментация» и «Перестройка индексов».

Для выхода из аварийного режима и возвращения узла в кластер перезапустите узел.

Устаревшие кеши#

Кеш считается устаревшим при соблюдении двух условий:

узел покинул кластер (например при входе в аварийный режим);
пока узел был недоступен, кеш в кластере был удален.

Устаревшие кеши необходимо удалять.

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

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