Перейти к содержанию

Обновление AW

Внимание Перед переходом на релиз 1.39 требуется изучить рекомендации по обновлению предыдущих версий (начиная от вашей текущей).

Внимание!!! Перед обновлением на версию 1.38 и старше необходимо обновиться на 1.37.4.

Внимание Перед переходом на релиз 1.39 настоятельно рекомендуется выполнить резервное копирование БД AW и проверить наличие свободного места на диске (см. ниже).

Технические изменения в выпуске AW 1.39.*

Обновление PostgreSQL до версии 18

Все базы данных PostgreSQL в составе AW (основная БД db, БД Airflow etl-airflow-db, БД MLflow etl-mlflow-db) переведены на PostgreSQL 18.

Перенос данных выполняется автоматически при первом запуске новой версии с помощью служебных одноразовых сервисов db-upgrade, etl-airflow-db-upgrade и etl-mlflow-db-upgrade. Сервисы баз данных запускаются только после успешного завершения соответствующего сервиса обновления — при ошибке обновления база не стартует, а приложение не увидит частично перенесённые данные.

Обновление выполняется в режиме копирования: данные каждой базы копируются в новый каталог, а старый каталог не изменяется и остаётся резервной копией.

База данных Старый каталог (резервная копия) Новый каталог Переменная
Основная БД (PostgreSQL 13) ../db/postgres ../db/postgres18 AW_DB_POSTGRES18_DIR
БД Airflow (PostgreSQL 12) ../db/airflow ../db/airflow18 AW_DB_AIRFLOW_POSTGRES18_DIR
БД MLflow (PostgreSQL 15) ../db/mlflow ../db/mlflow18 ML_FLOW_POSTGRES18_DIR

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

требуется = размер_базы × 1.5 + 256 МиБ

Например, для базы размером 40 ГиБ требуется около 60 ГиБ свободного места. Оценить размер баз и свободное место можно командами на серверах с соответствующими БД (из рабочей директории приложения, по умолчанию /opt/aw/app):

du -sh ../db/postgres ../db/airflow ../db/mlflow
df -h ../db

Если места недостаточно, обновление не начнется (сервис *-upgrade завершится с ошибкой, в его логе будет указано требуемое и доступное место). В этом случае освободите место на диске или укажите для нового каталога путь на другом диске с помощью переменных AW_DB_POSTGRES18_DIR, AW_DB_AIRFLOW_POSTGRES18_DIR, ML_FLOW_POSTGRES18_DIR в секции env соответствующего сервера в конфигурации профиля.

На большой базе первый запуск после обновления занимает больше времени, чем обычно, — в это время копируются данные. Ход обновления можно посмотреть в логе сервиса на сервере с БД:

docker compose logs -f db-upgrade

Лог также сохраняется в файл pg-upgrade-to-18.log в новом каталоге базы. Повторный запуск безопасен: уже обновленные базы пропускаются.

После нескольких дней стабильной работы старые каталоги (../db/postgres, ../db/airflow, ../db/mlflow) можно удалить вручную, чтобы освободить место.

Откат. Так как старые каталоги не изменяются, для отката достаточно остановить AW и развернуть предыдущую версию. Данные, записанные после обновления, при откате будут потеряны, поэтому откат имеет смысл только сразу после обновления.

Переход на аутентификацию SCRAM

В PostgreSQL 18 метод шифрования паролей md5 объявлен устаревшим, поэтому AW переведен на scram-sha-256:

  • pgbouncer обновлен до версии 1.25 и работает с AUTH_TYPE: scram-sha-256;
  • при переносе базы пароль суперпользователя перешифровывается из md5 в scram-sha-256 (сам пароль не меняется, берется из переменных .env);
  • если в базе есть созданные вручную роли с md5-паролями, их список выводится в лог сервиса db-upgrade. Пароли таких ролей рекомендуется перешифровать командой ALTER ROLE ... WITH PASSWORD '...'.

Ошибка FATAL: server login failed: wrong password type в логах pgbouncer или приложения означает, что используется pgbouncer со старыми настройками. Убедитесь, что используется docker-compose.yml из нового релиза.

Изменения в конфигурации

Добавлены сервисы:

  • db-upgrade, etl-airflow-db-upgrade, etl-mlflow-db-upgrade — одноразовые сервисы обновления PostgreSQL до версии 18 (см. выше);
  • code-model-changes — обработка изменений кодовых моделей;
  • mcp — MCP-сервер AW, доступен по адресу <адрес AW>/mcp.

Внимание!! Если вы используете измененный конфигурационный файл web-сервера Nginx (по умолчанию /opt/aw/app/docker/nginx/nginx.conf на сервере с контейнером frontend) или внешний Nginx, добавьте в него проксирование на сервис mcp:

location ~ ^/mcp {
    proxy_pass http://mcp;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    proxy_read_timeout 3600;
}

Добавлены переменные:

Переменная Описание Значение
по умолчанию
AW_DB_POSTGRES18_DIR Каталог основной БД (PostgreSQL 18) ../db/postgres18
AW_DB_AIRFLOW_POSTGRES18_DIR Каталог БД Airflow (PostgreSQL 18) ../db/airflow18
ML_FLOW_POSTGRES18_DIR Каталог БД MLflow (PostgreSQL 18) ../db/mlflow18
AW_WIDGET_MAX_RESULT_BYTES Предел объема результата запроса виджета в ClickHouse, байт. 0 — лимит выключен 268435456 (256 МиБ)
AW_WIDGET_MAX_MEMORY_USAGE Предел памяти одного запроса виджета в ClickHouse, байт. 0 — действует профиль пользователя ClickHouse 0
AW_WIDGET_PHP_MEMORY_LIMIT Предел памяти процесса PHP на время запроса виджета (-1 — без предела) 2G
MLFLOW_SERVER_ALLOWED_HOSTS Разрешенные значения заголовка Host для MLflow (список через запятую, * — проверка отключена) *
MLFLOW_AUTH_DB_URI URI БД прав доступа MLflow postgresql://mlflow:mlflow@etl-mlflow-db:5432/mlflow_permissions

Лимиты AW_WIDGET_* применяются только к интерактивному получению данных виджета (данные, шапка, итоги) и не затрагивают экспорт и синхронизацию. При срабатывании лимита пользователь получает ошибку, усеченные данные не отображаются и не кэшируются.

Автоматизированное обновление конфигурационного файла профиля

Команда update. awctl update - анализирует текущий конфигурационный файл профиля, генерирует конфигурационный файл для новый версии AW и переносит все изменения сделанные в старом конфигурационном файле.

Обновление конфигурации профиля AW

Выполняем команду: - /opt/awctl/awctl update --version <номер новой версии AW> <имя профиля> Результатом выполнениия команды станет новый конфигурационный файл профиля с перенесенными изменениями из старого. Рез. копия старого конфигурационного профиля сохраняется под именем config.<старая версия AW>.yml.

  • рекомендуется проверить новый конфигурационный файл - корректность переноса секций env, настроек aw_host, aw_user и т.п.
  • выполнить команду gen - /opt/awctl/awctl gen <имя профиля>
  • выполнить команду install - /opt/awctl/awctl install <имя профиля>
  • выполнить команду migrate - /opt/awctl/awctl migrate <имя профиля>

Ручное обновление конфигурационного файла профиля

Подготовка нового конфигурационного файла профиля

Т.к. кол-во сервисов в составе AW может меняться от версии к версии, при обновлении распределенной установки требуется сгенерировать распределение сервисов по серверам заново:

/opt/awctl/awctl init --preset <кол-во серверов> --release-path <путь к архиву с релизом AW> <имя профиля>
Далее из рез. копии старого файла конфигурации профиля необходимо перенести в новый значения:

  • aw_home, aw_host, aw_ssh_host, aw_user, aw_ssh_user, aw_ssh_password и т.п. для каждого сервера
  • секцию env для каждого сервера, если используется
  • значения with_extra_hosts, with_traefik из секции aw

Сделать это можно с помощью любого удобного текстового редактора.

Обновление AW

Для обновления установки AW выполните следующие действия:

  1. Генерируем конфигурационные файлы для серверов:

    /opt/awctl/awctl gen <имя_профиля>

  2. При обновлении с версия 1.2* - останавливаем AW:

    /opt/awctl/awctl stop <имя_профиля>

    Удаляем содержимое директории db/rabbitmq

    cd /opt/aw/db/rabbitmq
rm -rf ./*

  3. Выполняем установку AW:

    /opt/awctl/awctl install <имя_профиля>
    Если установка выполняется из полного релизного архива (release-<версия AW>.tar), то выполнение команды может занять длительное время.

  4. Выполняем миграции:

    /opt/awctl/awctl migrate <имя_профиля>