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

Обновление Glarus BI. Нестандартные варианты

На этой странице описано, как обновиться до нового релиза Glarus BI.

Обновление облачной версии

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

Обновление при самостоятельном размещении

Ниже — шаги для обновления на новую версию.

1. Резервная копия базы данных приложения

База данных приложения хранит буквально всё, что относится к вашему экземпляру Glarus BI (кроме данных подключённых источников). Хотя откаты требуются редко, резервная копия сильно снижает риск потерь, если что‑то пойдёт не так.

См. Резервное копирование данных приложения Glarus BI.

2. Замена версии Glarus BI

Шаги различаются в зависимости от того, запускаете вы контейнерный образ или JAR‑файл.

Обновление контейнерного образа

  1. Остановите текущий контейнер.
  2. Скачайте новый образ (мы рекомендуем использовать конкретный тег, а не latest).

Пример:

docker pull repo/image:latest
  1. Запустите новый контейнер. В зависимости от портов и названия контейнера команда будет выглядеть примерно так:
docker run -d -p 3000:3000 -e MB_DB_CONNECTION_URI="jdbc:postgresql://<host>:5432/metabase?user=<username>&password=<password>" --name glarusbi repo/image:latest

При запуске Glarus BI автоматически выполнит обновление. После завершения обновления вы будете работать в новой версии.

Обновление JAR‑файла

Чтобы обновиться, нужно остановить службу, заменить JAR‑файл на новую версию и снова запустить службу.

Например, если вы запускаете Glarus BI как сервис systemd:

  1. Остановите службу. Например, если вы назвали её glarusbi.service:
sudo systemctl stop glarusbi.service

  1. Загрузите новую версию JAR‑файла и замените текущий (старый) metabase.jar на новый.

  2. Запустите службу снова:

sudo systemctl restart glarusbi.service

Обновление на других платформах

Что происходит при обновлении или откате

Во время обновления мажорной версии (например, v0.52 → v0.57) Glarus BI:

  • выполняет все миграции, необходимые для обновления до новой версии (в том числе изменения схемы базы данных приложения);
  • сохраняет все метаданные, необходимые для работы.

Glarus BI делает это автоматически.

Если после обновления на мажорную версию вам нужно понизить версию, вам потребуется либо восстановление из резервной копии, либо ручная миграция к более старой версии (очень рискованная процедура, работа не гарантируется) — иначе приложение может отказаться запускаться (см. следующий раздел).

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

Откат обновления или переход на более старую версию

Команду отката нужно запускать на JAR‑файле с более высокой версией.

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

Но если после обновления вы внесли изменения (создавали запросы/дашборды и т. п.) и хотите их сохранить, вы можете попробовать использовать команду migrate down, чтобы откатить базу данных приложения до состояния, совместимого с предыдущей версией. При обновлении Glarus BI выполняет миграции, которые могут менять схему базы данных приложения; migrate down отменяет эти изменения.

Внимание

Использование migrate down в Glarus BI может быть небезопасным. Мы рекомендуем в первую очередь восстановление из резервной копии.

Использование команды migrate down

Остановите Glarus BI и используйте текущий обновлённый JAR‑файл (а не тот, к которому вы хотите откатиться), чтобы выполнить откат командой migrate down. Убедитесь, что параметры подключения к базе данных приложения заданы через переменные окружения, например:

export MB_DB_TYPE=postgres
export MB_DB_DBNAME=metabaseappdb
export MB_DB_PORT=5432
export MB_DB_USER=username
export MB_DB_PASS=password
export MB_DB_HOST=localhost
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar migrate down

Если вы используете Docker, запустите команду "migrate down" (с кавычками) и добавьте параметры подключения к базе данных приложения, например:

docker run
  -e "MB_DB_TYPE=postgres" \
  -e "MB_DB_DBNAME=metabaseappdb" \
  -e "MB_DB_PORT=5432" \
  -e "MB_DB_USER=name" \
  -e "MB_DB_PASS=password" \
  -e "MB_DB_HOST=my-database-host" \
--rm metabase/metabase:<tag> "migrate down"

Обратите внимание на кавычки вокруг "migrate down". Также можно просто открыть shell внутри контейнера и выполнить команду миграции внутри контейнера.

После завершения миграции запустите Glarus BI, используя JAR‑файл или контейнерный образ для версии, которую вы хотите использовать.

Обновление Glarus BI в кластере

Если вы запускаете Glarus BI в кластере:

  1. Сведите количество узлов к одному. Нельзя обновлять все узлы одновременно: процесс обновления захватывает migration‑lock на базе данных приложения из одного клиента, который выполняет миграции. Если оставить активными несколько узлов при мажорном обновлении, приложение может работать некорректно: изменения схемы базы данных могут нарушить узлы, которые ещё работают на старой версии.
  2. Выполните обновление обычным образом (как описано выше).
  3. Верните количество узлов к исходному значению.

Убедитесь, что ваш orchestrator/cluster manager не завершит процесс Glarus BI во время выполнения миграций. Иначе вы можете получить повреждённую базу данных приложения и необходимость восстанавливаться из резервной копии.

Дополнительная информация