Миграция на базу данных промышленной эксплуатации

На этой странице описывается, как преобразовать Glarus BI, которая использовала встроенную базу данных приложения H2, в готовый к производству экземпляр с PostgreSQL или MySQL/MariaDB. Подробнее о том, почему вам следует это сделать, см. Как запустить Glarus BI в прод.

Метаданные GlarusBI

Основное различие между локальной установкой и установкой, подготовленное к промышленной эксплуатации заключается в выборе базе данных приложения. С помощью этих метаданных отслеживаются все элементы: ваши вопросы, информационные панели, коллекции и так далее.

GlarusBI поставляется со встроенной базой данных приложения H2, которую не следует использовать для промышленной эксплуатации. Причина, по которой GlarusBI поставляется с базой данных H2, заключается в том, что мы хотим, чтобы люди запускали GlarusBI на своих локальных компьютерах и имели возможность быстро начать работу.

Если же вы хотите запустить GlarusBI в производственной среде, вам потребуется использовать базу данных приложения для хранения метаданных. Вы можете в любое время отказаться от использования базы данных H2, но если вы планируете использовать GlarusBI в рабочей среде, чем раньше вы перейдете на продуктивную базу данных, тем лучше. Если же вы продолжаете использовать с H2 и регулярно не создаете ее резервную копию, метаданные могут быть повреждены, и вы можете потерять все свои вопросы, информационные панели, коллекции и другие элементы.

Как правило процесс миграции происходит однократно. Вы можете выполнить сценарий миграции с любого компьютера, на котором есть файл базы данных приложения H2. Например, если вы пытаетесь выполнить миграцию на AWS Elastic Beanstalk для запуска GlarusBI с базой данных RDS , вы можете запустить миграцию со своего компьютера, а не пытаться копировать файл H2 на виртуальную машину AWS Elastic Beanstalk.

Избегайте запуска процессов миграции и обновления версии одномоментно

При миграции требуется, чтобы исходная и целевая версии GlarusBI были одинаковыми. Это означает, что GlarusBI, которую вы используете для запуска команды миграции, должна быть той же самой, которая в последний раз использовалась для создания или обновления файла H2, и это должна быть та же версия, которую вы будете использовать в рабочей среде. О переходе на новую версию GlarusBI и обновлении можно подумать только после завершения миграции.

При пользовании облачной версией GlarusBI Cloud, вам не стоит беспокоиться о вопросах миграции или обновления версии. Если вы хотите мигрироваться в облачную версию, можете сделать это следующим образом.

Поддерживаемые базы данных для хранения метаданных

  • PostgreSQL. минимально: 9.5.

  • MySQL. Минимум: 8.0.17. Требуемые параметры (которые по умолчанию): utf8mb4_unicode_ci подборка, utf8mb4 набор символов, и innodb_large_prefix=ON.

  • MariaDB. Минимум: 10.4.0. Требуемые параметры (которые по умолчанию): utf8mb4_unicode_ci подборка, utf8mb4 абор символов, и innodb_large_prefix=ON.

Вы можете использовать любую базу данных, которую вы предпочитаете. Если вы не знакомы ни с одной из них или не знаете, какую выбрать, используйте Postgres.

JAR: Как мигрировать с H2 на базу данных промышленной эксплутации

Вы должны использовать одну и ту же версию GlarusBI на протяжении всего процесса миграции.

GlarusBI предоставляет набор команд для миграции на новую базу данных. Необходимо сделать следующее:

1. Проверьте, что вы можете подключиться к целевой базе данных

У вас должен быть настроен доступ к целевой базе данных Postgres или MySQL/MariaDB в любой среде, в которой вы запускаете эту команду миграции. Поэтому, если вы пытаетесь мигрировать данные в облачную базу данных, убедитесь, что вы можете к ней подключиться.

2. Выключите GlarusBI

Пока происходит миграция данных, необходимо ограничить пользователям возможность создавать новые метаданные. В идеале, если вы используете JAR GlarusBI в производственной среде, ваш экземпляр был запущен как служба.

3. Сделайте резервную компию вашей базы данных H2

Создайте резервную копию GlarusBI.

4. Запустите процесс миграции

Запустите команду миграции load-from-h2, используя соответствующие переменные среды для целевой базы данных, в которую вы хотите выполнить миграцию.

Подробную информацию о настройках баз данных MySQL и Postgres можно найти в разделе настройка базы данных приложения.

Ниже приведен пример команды для миграции на базу данных Postgres:

export MB_DB_TYPE=postgres
export MB_DB_CONNECTION_URI="jdbc:postgresql://<host>:5432/metabase?user=<username>&password=<password>"
java -jar glarusBI.jar load-from-h2 /path/to/metabase.db # do not include .mv.db

Вот пример команды для миграции в базу данных MySQL с использованием параметра Java вместо переменных среды:

java -DMB_DB_TYPE=mysql -DMB_DB_CONNECTION_URI="jdbc:mysql://<host>:3306/metabase?user=<username>&password=<password>" -jar glarusBI.jar load-from-h2 metabase.db

Обратите внимание, что имя файла самой базы данных может быть /path/to/metabase.db.mv.db, но при запуске команды load-from-h2 вам нужно привести его к виду /path/to/metabase.db.

GlarusBI ожидает, что вы запустите процесс миграции в совершенно новую (пустую) базу данных; при этом он создаст схему бд и сам перенесет все необходимые данные.

5. Запустите GlarusBI

Запустите GlarusBI (указав коннект к новой БД в переменных окружения). Например, если вы используете Postgres, ваша команда для запуска GlarusBI будет выглядеть примерно так:

export MB_DB_TYPE=postgres
export MB_DB_CONNECTION_URI="jdbc:postgresql://<host>:5432/metabase?user=<username>&password=<password>"
java -jar glarusBI.jar

Docker: как перейти с H2 на базу данных для промышленной эксплуатации

Вы должны использовать одну и ту же версию GlarusBI на протяжении всего процесса миграции.

GlarusBI предоставляет набор команд для миграции на новую базу данных. Необходимо сделать следующее:

1. Проверьте, что вы можете подключиться к целевой базе данных

У вас должен быть настроен доступ к целевой базе данных Postgres или MySQL/MariaDB в любой среде, в которой вы запускаете эту команду миграции. Поэтому, если вы пытаетесь мигрировать данные в облачную базу данных, убедитесь, что вы можете к ней подключиться.

2. Сделайте резервную компию вашей базы данных H2

Создайте резервную копию GlarusBI.

3. Остановите запущенный контейнер GlarusBI

Пока происходит миграция данных, необходимо ограничить пользователям возможность создавать новые метаданные.

4. Загрузите JAR

В каталоге, где вы сохранили файл H2 (вне контейнера), загрузите JAR соответствующий вашей текущей версии GlarusBI.

Убедитесь, что вы используете ту же версию GlarusBI, что и раньше. Если вы хотите выполнить обновление на нову версию, выполните его только после того, как убедитесь, что миграция прошла успешно.

5. Запустите процесс миграции

Создайте еще одну копию файла H2 (можно использовать данные с шага 2).

В том каталоге, где находится файл базы данных H2 и JAR файл GlarusBI запустите команду переноса load-from-h2. Для подключения к целевой базе данных используйте параметры коннекта, или же переменные среды. Команда будет выглядеть примерно так:

export MB_DB_TYPE=postgres
export MB_DB_CONNECTION_URI="jdbc:postgresql://<host>:5432/metabase?user=<username>&password=<password>"
java -jar glarusBI.jar load-from-h2 /path/to/metabase.db # do not include .mv.db

GlarusBI запустится, выполнит миграцию (это означает, что она возьмет данные из файла H2 и поместит их в новую базу данных приложения, в данном случае базу данных Postgres), а затем завершит работу.

Подробную информацию об настройках для баз данных MySQL и Postgres можно найти в разделе Настройка базы данных приложения.

6. Стартуйте новый Docker контейнер, с параметрами новой базы данных

Теперь вы можете стартовать новый контейнер с GlarusBI и выполнить подключение к новой базе данных, в которую мигрировались все ваши данные.

Команда будет выглядеть примерно следующим образом:

docker run -d -p 3000:3000 \
  -e "MB_DB_TYPE=postgres" \
  -e "MB_DB_DBNAME=<your-postgres-db-name>" \
  -e "MB_DB_PORT=5432" \
  -e "MB_DB_USER=<db-username>" \
  -e "MB_DB_PASS=<db-password>" \
  -e "MB_DB_HOST=<your-database-host>" \
  --name metabase metabase/metabase

7. Удалите старый контейнер, который использовал базу данных H2

Если вы сохранили резервную копию файла H2, можете удалить старый контейнер. См. документацию по Docker для удаления контейнеров.

Запуск миграции базы данных приложения GlarusBI вручную

Когда GlarusBI запускается, она обычно пытается определить, необходимо ли внести какие-либо изменения в базе данных приложения, и если да, то автоматически выполняет эти изменения. Если по какой-то причине вы хотите увидеть, что это за изменения, и выполнить их в ручном режиме, установите следующую переменную среды перед запуском GlarusBI:

export MB_DB_AUTOMIGRATE=false

В этом случае, при запуске приложения, если необходимо выполнить изменения в базе данных, вы получите сообщения, указывающие, что приложение не может быть запущено, пока не будет проведены обновления:

2015-12-01 12:45:45,805 [INFO ] metabase.db :: Database Upgrade Required

NOTICE: Your database requires updates to work with this version of GlarusBI.  Please execute the following sql commands on your database before proceeding.

-- *********************************************************************
-- Update Database Script
-- *********************************************************************
-- Change Log: migrations/liquibase.yaml
-- Ran at: 12/1/15 12:45 PM
-- Against: @jdbc:h2:file:/Users/agilliland/workspace/metabase/metabase/metabase.db
-- Liquibase version: 3.4.1
-- *********************************************************************

-- Create Database Lock Table
CREATE TABLE PUBLIC.DATABASECHANGELOGLOCK (ID INT NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED TIMESTAMP, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID));

...

Once your database is updated try running the application again.

2015-12-01 12:46:39,489 [INFO ] metabase.core :: GlarusBI Shutting Down ...

Вы можете вручную выполнить SQL скрипты и после его выполнения, просто перезапустите GlarusBI.

Устранение проблем с миграцией

См. руководство по устранению ошибок.