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

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

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

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

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

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

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

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

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

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

Задача

Обслуживание

Выполняется автоматически при запуске

defragmentationMaintenanceTask

Запланирована дефрагментация узла

Да

indexRebuildMaintenanceTask

Запланировано восстановление индексов данных

Да

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

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

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

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

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

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

  1. Перезапустите узел — он войдет в аварийный режим.

  2. Используйте скрипт управления для выполнения команды 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-адрес и порт узла можно узнать из его логов.

  3. После завершения задачи перезапустите узел — он возобновит процесс создания контрольной точки (checkpointing).

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

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

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

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

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

  • control.sh --defragmentation schedule — дефрагментация узла;

  • control.sh --cache schedule_indexes_rebuild — планирование перестройки индексов данных кеша в аварийном режиме.

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

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