Перейти к основному содержимому
Версия: 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).