Перейти к основному содержимому
Версия: 2.0.x

Плавное завершение работы

Начиная с версии v1.5.2, Selena поддерживает плавное завершение работы (Graceful Exit).

Обзор​

Плавное завершение работы — это механизм, предназначенный для поддержки обновлений и перезапусков без прерывания работы узлов FE, BE и CN в Selena. Его основная цель — минимизировать влияние на выполняющиеся запросы и задачи загрузки данных во время операций обслуживания, таких как перезапуск узла, последовательное обновление или масштабирование cluster.

Плавное завершение работы гарантирует, что:

  • Узел прекращает принимать новые задачи после начала завершения работы;
  • Существующим запросам и заданиям загрузки разрешено завершиться в контролируемом временном окне;
  • Системные компоненты (FE/BE/CN) координируют изменения статуса, чтобы cluster корректно перенаправлял трафик.

Механизмы плавного завершения работы различаются для узлов FE и BE/CN, как описано ниже.

Механизм плавного завершения работы FE​

Сигнал триггера​

Плавное завершение работы FE инициируется командой:

stop_fe.sh -g

Это отправляет сигнал SIGUSR1, тогда как завершение по умолчанию (без опции -g) отправляет сигнал SIGTERM.

Осведомлённость балансировщика нагрузки​

При получении сигнала:

  • FE немедленно возвращает HTTP 500 на конечной точке /api/health.
  • Балансировщики нагрузки обнаруживают ухудшенное состояние в течение ~15 секунд и прекращают направлять новые соединения к этому FE.

Логика опустошения соединений и завершения работы​

Follower FE

  • Обрабатывает запросы только на чтение.
  • Если у узла FE нет активных сессий, соединение закрывается немедленно.
  • Если выполняется SQL, узел FE ожидает завершения выполнения перед закрытием сессии.

Leader FE

  • Обработка запросов на чтение идентична обработке Follower.

  • Обработка запросов на запись требует:

    • Закрытия BDBJE.
    • Разрешения завершения выбора нового Leader.
    • Перенаправления последующих записей на вновь избранного Leader.

Контроль тайм-аута​

Если запрос выполняется слишком долго, FE принудительно завершает работу через 60 секунд (настраивается с помощью опции --timeout).

Механизм плавного завершения работы BE/CN​

Сигнал триггера​

Плавное завершение работы BE инициируется командой:

stop_be.sh -g

Плавное завершение работы CN инициируется командой:

stop_cn.sh -g

Это отправляет сигнал SIGTERM, тогда как завершение по умолчанию (без опции -g) отправляет сигнал SIGKILL.

Переход состояния​

После получения сигнала:

  • Узел BE/CN помечает себя как завершающийся.
  • Он отклоняет новые фрагменты запросов, возвращая INTERNAL_ERROR.
  • Он продолжает обрабатывать существующие фрагменты.

Цикл ожидания для выполняющихся запросов​

Поведение, при котором BE/CN ожидает завершения существующих фрагментов, контролируется параметром конфигурации BE/CN loop_count_wait_fragments_finish (по умолчанию: 2). Фактическая продолжительность ожидания равна loop_count_wait_fragments_finish × 10 секунд (то есть 20 секунд по умолчанию). Если фрагменты остаются после тайм-аута, BE/CN продолжает нормальное завершение работы (закрытие потоков, сети и других процессов).

Улучшенная осведомлённость FE​

Начиная с версии v1.5.2, FE больше не помечает BE/CN как DEAD на основе сбоев heartbeat. Он корректно распознаёт состояние BE/CN "завершение работы", что позволяет значительно увеличить временные окна плавного завершения для завершения фрагментов.

Конфигурации​

Конфигурации FE​

stop_fe.sh -g --timeout​

  • Описание: Максимальное время ожидания перед принудительным завершением FE.
  • По умолчанию: 60 (секунд)
  • Как применить: Укажите в команде скрипта, например, --timeout 120.

Минимальное время обнаружения LB​

  • Описание: Балансировщику нагрузки требуется минимум 15 секунд для обнаружения ухудшенного состояния.
  • По умолчанию: 15 (секунд)
  • Как применить: Фиксированное значение

Конфигурации BE/CN​

loop_count_wait_fragments_finish​

  • Описание: Продолжительность ожидания BE/CN для существующих фрагментов. Умножьте значение на 10 секунд.
  • По умолчанию: 2
  • Как применить: Измените в файле конфигурации BE/CN или обновите динамически.

graceful_exit_wait_for_frontend_heartbeat​

  • Описание: Ожидает ли BE/CN подтверждения SHUTDOWN от FE через heartbeat. Начиная с версии v1.5.2.
  • По умолчанию: false
  • Как применить: Измените в файле конфигурации BE/CN или обновите динамически.

stop_be.sh -g --timeout, stop_cn.sh -g --timeout​

  • Описание: Максимальное время ожидания перед принудительным завершением BE/CN. Установите значение больше, чем loop_count_wait_fragments_finish * 10, чтобы предотвратить завершение до достижения времени ожидания BE/CN.
  • По умолчанию: false
  • Как применить: Укажите в команде скрипта, например, --timeout 30.

Глобальные переключатели​

Плавное завершение работы включено по умолчанию начиная с версии v1.5.2. Чтобы временно отключить его, установите параметр конфигурации BE/CN loop_count_wait_fragments_finish в 0.

Ожидаемое поведение во время плавного завершения работы​

Рабочие нагрузки запросов​

Тип запросаОжидаемое поведение
Короткий (менее 20 секунд)BE/CN ожидает достаточно долго, поэтому запросы завершаются нормально.
Средний (от 20 до 60 секунд)Запросы, завершённые в окне ожидания BE/CN, возвращаются успешно; иначе запросы отменяются и требуют ручного повтора.
Длительный (более 60 секунд)Запросы, вероятно, будут прерваны FE/BE/CN из-за тайм-аута и требуют ручного повтора.

Задачи загрузки данных​

  • Задачи загрузки через Flink или Kafka Connectors автоматически повторяются без видимого пользователю прерывания.
  • Задачи Stream Load (без фреймворка), Broker Load и Routine Load могут завершиться с ошибкой при разрыве соединения. Требуется ручной повтор.
  • Фоновые задачи автоматически перепланируются и выполняются механизмом повтора FE.

Операции обновления и перезапуска​

Плавное завершение работы обеспечивает:

  • Отсутствие простоя всего cluster;
  • Безопасное последовательное обновление путём опустошения узлов по одному.

Ограничения и различия версий​

Различия поведения версий​

ВерсияПоведение
v1.5.2Плавное завершение работы BE имеет недостатки: FE может преждевременно пометить BE/CN как DEAD, что приводит к отмене запросов. Эффективное ожидание ограничено (15 секунд по умолчанию).
v1.5.2+Полностью поддерживает увеличенную продолжительность ожидания; FE корректно определяет состояние BE/CN "завершение работы". Рекомендуется для production.

Операционные ограничения​

  • В экстремальных случаях (например, зависание BE/CN) плавное завершение работы может не сработать. Завершение процесса требует kill -9, с риском частичной персистентности данных (восстановимой через snapshot).

Использование​

Предварительные требования​

Версия Selena:

  • v1.5.2+: Базовая поддержка плавного завершения работы.
  • v1.5.2+: Улучшенное управление статусом, более длительные окна ожидания (до нескольких минут).

Конфигурация:

  • Убедитесь, что loop_count_wait_fragments_finish установлен в положительное целое число.
  • Установите graceful_exit_wait_for_frontend_heartbeat в true, чтобы FE мог обнаружить состояние BE "EXITING".

Выполнение плавного завершения работы FE​

./bin/stop_fe.sh -g --timeout 60

Параметры:

  • --timeout: Максимальное время ожидания перед принудительным завершением узла FE.

Поведение:

  • Система сначала отправляет сигнал SIGUSR1.
  • После тайм-аута переходит к SIGKILL.

Проверка состояния FE​

Вы можете проверить состояние FE через следующий API:

http://<fe_host>:8030/api/health

Балансировщик нагрузки удаляет узел после получения последовательных ответов не-200.

Выполнение плавного завершения работы BE/CN​

  • Для v1.5.2:

    • BE:
    ./be/bin/stop_be.sh -g
    • CN:
    ./be/bin/stop_cn.sh -g

  • Для v1.5.2+:

    • BE:
    ./bin/stop_be.sh -g --timeout 600
    • CN:
    ./bin/stop_cn.sh -g --timeout 600

BE/CN завершает работу немедленно, если фрагментов не осталось.

Проверка статуса BE/CN​

Выполните на FE:

SHOW BACKENDS;

StatusCode:

  • SHUTDOWN: Плавное завершение работы BE/CN в процессе.
  • DISCONNECTED: Узел BE/CN полностью завершил работу.

Рабочий процесс последовательного обновления​

Процедура​

  1. Выполните плавное завершение работы на узле A.
  2. Убедитесь, что узел A отображается как DISCONNECTED на стороне FE.
  3. Обновите и перезапустите узел A.
  4. Повторите вышеуказанное для оставшихся узлов.

Мониторинг плавного завершения работы​

Проверьте логи FE fe.log, логи BE be.log или логи CN cn.log, чтобы убедиться, были ли задачи во время завершения работы.

Устранение неполадок​

BE/CN завершается по тайм-ауту​

Если задачи не завершаются в течение периода плавного завершения работы, BE/CN запускает принудительное завершение (SIGKILL). Проверьте, вызвано ли это чрезмерно длительной продолжительностью задачи или неправильными конфигурациями (например, слишком малым значением --timeout).

Статус узла не SHUTDOWN​

Если статус узла не SHUTDOWN, проверьте, установлен ли loop_count_wait_fragments_finish в положительное целое число, или отправил ли BE/CN heartbeat перед завершением работы (если нет, установите graceful_exit_wait_for_frontend_heartbeat в true).