Управление и обслуживание

Глава актуальна для обоих режимов установки, онлайн и офлайн.

Управление стеком

sudo systemctl start selena.target # поднять всё  
sudo systemctl stop selena.target # остановить всё  
sudo systemctl restart selena-cm.service # перезапустить один компонент  
journalctl -u selena-cm.service -f # логи (или scripts/logs.sh)

Стек включён в multi-user.target - запускается сам после ребута.

Дополнительные переменные окружения (extraEnv)

Любому control-plane сервису возможно передать произвольные переменные окружения через deploy.yaml:

extraEnv:  
cm:  
vars: # инлайн-пары -> рендерятся в /var/lib/selena/runtime/secrets/cm.extra.env  
JAVA_OPTS_APPEND: "-Xmx2g"  
files: # готовые env-файлы оператора (абсолютные пути, формат KEY=VALUE)  
- /etc/selena/custom/cm-tuning.env

Переменные окружения могут быть заданы для следующих сервисов:
postgres, keycloak, minio, lakekeeper, grafana, cm, ide, ai-backend, ai-frontend, mcp.
Для ide окружение является общим для трёх компонентов: web, worker, scheduler. Настройка Engine выполняется через Cluster Manager, а не через extraEnv.

Порядок применения файлов окружения (приоритет у последнего):
<svc>.env → <svc>.extra.env → files (по порядку) → impersonator-файлы CM (только для ide/mcp). Impersonator имеет наивысший приоритет и не переопределяется через extraEnv.
extraEnv позволяет добавлять и переопределять переменные (например, KC_HOSTNAME) на усмотрение администратора.

• Значения пишутся как есть (KEY=VALUE, без кавычек в итоговом файле).

• Файлы из files инсталлятор не копирует - только валидирует (проверяет наличие и абсолютный путь) и подключает юниту через EnvironmentFile=.
  Права доступа к ним обеспечивает оператор (для секретов рекомендуется 0600).

• extra.env перегенерируется каждым запуском install.sh и deploy.yaml:
  переменные задаются в конфиге, ручные правки теряются при переустановке.

• Для применения изменений выполните:
  sudo ./scripts/install.sh --deploy ... && sudo systemctl restart <юнит>.

Удаление

Для удаления компонентов Selena используются команды:

Команда	Действие
sudo bash scripts/uninstall.sh	Остановка и удаление systemd-юнитов
sudo bash scripts/uninstall.sh --delete-data	Остановка и удаление systemd-юнитов + удаление /opt/selena, /var/lib/selena, /etc/selena.
sudo bash scripts/uninstall.sh --delete-data && sudo userdel selena	Чистая переустановка, удаление пользователя selena, иначе при повторной установке будет конфликт UID.

Примечания:

• uninstall.sh без флага --delete-data выполняет удаление каталога /opt/selena. В данном каталоге размещаются метаданные FE (/opt/selena/fe/meta), сторедж BE (/opt/selena/be/storage), логи движка и _dl. На All-in-One- установке это приводит к уничтожению метаданных StarRocks вместе с данными, восстановление кластера невозможно.

• После выполнения uninstall.sh в системе остаются:

  • Пользователь selena-ansible
  • Файл /etc/sudoers.d/90-selena-all-in-one-ansible
  • Каталог /var/lib/selena-engine
  • systemd-юниты Engine на Engine-нодах, созданные плейбуками CM.

• uninstall.sh не обрабатывает конфигурационный файл deploy.yaml. Пути для удаления определяются переменной окружения DATA_ROOT (по умолчанию /var/lib/selena). Если в deploy.yaml изменены параметры roots.*, использование --delete-data на All-in-One установке приведёт к удалению не тех каталогов, а фактические каталоги с данными останутся нетронутыми.

Особенности работы upgrade.sh

• Версии: сравнивается маркер .artifact в каталоге компонента с artifacts.yaml; новый бандл скачивается и проверяется (sha256) до остановки сервиса.
• Конфигурация: изменившиеся env-файлы/юниты вычисляются рендером (install.sh --render-only) - рестартует только затронутое, для ide все три юнита.
  Смена версии тоже видна как изменение (конфиг [<comp>]) - рендер переписывает файлы компонента, change-set дедуплицируется, рестарт один.
• Старая инсталляция без .artifact-маркеров (поставлена install.sh до появления upgrade.sh):
  текущие версии неизвестны → план покажет <unknown> -> <версия> для всех компонентов и, после подтверждения, будут загружены и заменены все бандлы, данные в <dataRoot> не затрагиваются.

Чтобы получить корректный минимальный дифф, установите маркеры фактических версий перед первым запуском:

printf '%s' '<path-из-artifacts.yaml>' | sudo tee /opt/selena/<comp>/.artifact.

⚠️ При пустом маркере major-guard postgres не срабатывает (текущий major неизвестен) - сверьте версию postgres в artifacts.yaml с установленной вручную.

• Отката нет: укажите старую версию в yaml и снова запустите upgrade.sh (для offline: старый бандл должен лежать в bundleDir).
• Смена major-версии PostgreSQL требует --yes и не переносит данные (pg_upgrade вне скоупа). Engine обновляется через CM, а не с помощью upgrade.sh.
• Ошибка на компоненте останавливает процесс, уже обновлённые компоненты не откатываются. Оставшиеся компоненты фиксируются в pending-файле (<runtimeRoot>/upgrade-pending), повторный запуск подхватывает их как recovery [...] и продолжает с места падения (даже если конфиг-дифф уже пуст).
• При отказе от подтверждения (N), прерывании (Ctrl+C), обрыве ввода (закрытие терминала, разрыв SSH, перенаправление < /dev/null - трактуется как отказ) или сбое рендера подготовленные изменения откатываются (restore и daemon-reload). Стенд возвращается к исходному состоянию.