Миграция данных

Перевод Автоматический failover базы данных Moodle в PostgreSQL с помощью ClusterControl

06.04.2021 18:11:06 |

Автор: admin

Один из ключевых моментов в обеспечении высокой доступности быстрая реакция на сбой. Хотя нередко можно встретить ручное управление базами данных и систему мониторинга, которая следит за их состоянием и отправляет предупреждения дежурному персоналу. А это означает, что кому-то, возможно, придется проснуться среди ночи, добраться до компьютера, войти в систему и посмотреть логи то есть до начала восстановления может пройти довольно много времени. В идеале весь этот процесс должен быть автоматизирован.

В этой статье мы рассмотрим, как развернуть полностью автоматизированную систему, которая детектируют отказ первичной базы данных, и инициирует failover, изменяя роль (promote) вторичной базы данных. Для реализации автоматического failover базы данных Moodle PostgreSQL мы будем использовать ClusterControl.

Преимущество автоматического failover

Уменьшается время на восстановление базы данных
Увеличивается время uptime
Уменьшается зависимость от DBA или администраторов, настраивающих высокую доступность баз данных

Архитектура

На текущий момент у нас есть один первичный сервер Postgres и два вторичных все за балансировщиком нагрузки HAProxy, который отправляет трафик Moodle на первичный узел PostgreSQL. Для настройки автоматического failover в ClusterControl есть важные параметры восстановления кластера (cluster recovery) и узла (node auto recovery).

На какой сервер переключаться

В ClusterControl есть белый и черный списки серверов, с помощью которых вы можете настраивать участие в failover.

В конфигурации cmon это две переменные:

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

Процесс автофайловера (auto failover)

Шаг 1

Начинаем загрузку данных на первичном сервере (192.168.33.14) с помощью sysbench.

[root@centos11 sysbench]# /bin/sysbench --db-driver=pgsql --oltp-table-size=100000 --oltp-tables-count=24 --threads=2 --pgsql-host=****** --pgsql-port=6543 --pgsql-user=sbtest --pgsql-password=***** --pgsql-db=sbtest /usr/share/sysbench/tests/include/oltp_legacy/parallel_prepare.lua run sysbench 1.0.20 (using bundled LuaJIT 2.1.0-beta2)   Running the test with following options: Number of threads: 2 Initializing random number generator from current time    Initializing worker threads...   Threads started!   thread prepare0 Creating table 'sbtest1'... Inserting 100000 records into 'sbtest1' Creating secondary indexes on 'sbtest1'... Creating table 'sbtest2'...

Шаг 2

После этого остановим первичный сервер Postgres (192.168.33.14). Так как в ClusterControl включен параметр enable_cluster_autorecovery, то на роль первичного будет выбран первый подходящий сервер.

# service postgresql-12 stop

Шаг 3

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

В нашем случае 192.168.33.13 становится новым первичным сервером, а вторичные сервера теперь реплицируются с него. И HAProxy направляет трафик базы данных с серверов Moodle на новый первичный сервер.

Запуск на 192.168.33.13

postgres=# select pg_is_in_recovery();  pg_is_in_recovery  -------------------  f (1 row)

Запуск на 192.168.33.15

postgres=# select pg_is_in_recovery();  pg_is_in_recovery  -------------------  t (1 row)

Текущая топология

HAProxy автоматически обнаруживает недоступность узлов и перестает отправлять на него трафик. Эта проверка выполняется сценариями проверки работоспособности, которые настраиваются во время развертывания ClusterControl.

После того как ClusterControl повысит роль вторичного сервера до первичного, HAProxy помечает, что старый первичный сервер в оффлайне и переводит новый первичный узел в онлайн.

Когда старый первичный сервер снова заработает, то он не синхронизируется автоматически с новым первичным сервером. Мы должны вернуть его обратно в топологию и сделать это можно через интерфейс ClusterControl. Это позволит избежать потери или несогласованности данных, например, если нужно выяснить причину выхода из строя сервера.

ClusterControl передаст резервную копию с нового первичного сервера и настроит репликацию.

Заключение

Автоматический failover важная часть любой продуктивной базы Moodle. Благодаря ему можно сократить время простоя при отказе сервера, а также при выполнении задач по обслуживанию и миграции. Важно все настроить правильно, чтобы программное обеспечение автоматического failover могло принять правильные решения.

Перевод статьи подготовлен в преддверии старта курса "PostgreSQL".

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

ЗАПИСАТЬСЯ НА ВЕБИНАР

Подробнее..

Категории: Postgresql , Миграция данных , Блог компании otus , Clustercontrol

Перевод Миграции баз данных с Flyway

15.06.2020 18:18:41 |

Автор: admin

Перевод статьи подготовлен в преддверии старта курса Разработчик Java.

1. Введение

В этой статье описываются ключевые концепции Flyway и пример использования этого фреймворка для непрерывного изменения схемы базы данных на примере in-memory базы данных H2 с помощью maven-плагина flyway.

Flyway обновляет версии баз данных с помощью миграций. Миграции можно писать на SQL (с синтаксисом, специфичным для конкретной СУБД) или на Java.

Миграции могут быть версионными или повторяющимися. Первые имеют уникальную версию и применяются ровно один раз. У вторых номера версии нет, и они применяются, когда у них изменяется контрольная сумма.
Повторяющиеся миграции в рамках одного запуска всегда применяются после выполнения версионных миграций. Повторяющиеся миграции применяются в порядке их описания. В одной миграции все операции выполняются в рамках одной транзакции базы данных.

В этой статье мы сосредоточим внимание на использовании maven-плагина для миграций базы данных.

2. Flyway maven plugin

Добавим flyway maven plugin в pom.xml:

<plugin>    <groupId>org.flywaydb</groupId>    <artifactId>flyway-maven-plugin</artifactId>    <version>4.0.3</version></plugin>

Актуальную версию плагина можно посмотреть в Maven Central.
Список параметров плагина, можно посмотреть в документации. Параметры плагина можно настроить четырьмя различными способами.

2.1. Раздел <configuration> плагина
Параметры можно указать напрямую в теге в разделе плагина в pom.xml:

org.flywaydb
flyway-maven-plugin
4.0.3
databaseUser
databasePassword
schemaName

2.2. Maven properties

Также плагин можно настроить, указав параметры в <properties>:

<project>    ...    <properties>        <flyway.user>databaseUser</flyway.user>        <flyway.password>databasePassword</flyway.password>        <flyway.schemas>schemaName</flyway.schemas>        ...    </properties>    ...</project>

2.3. Внешний файл конфигурации

Или описать конфигурацию в отдельном .properties-файле:

flyway.user=databaseUserflyway.password=databasePasswordflyway.schemas=schemaName...

По умолчанию имя файла конфигурации flyway.properties. Этот файл должен находиться в том же каталоге, что и файл pom.xml. Кодировка задается в параметре flyway.encoding (по умолчанию UTF-8).

Если для файла вы используете другое имя (например, customConfig.properties), то его нужно указать явно при вызове maven:

$ mvn -Dflyway.configFile=customConfig.properties

2.4. System Properties

И наконец, параметры могут быть указаны как system properties при вызове maven из командной строки:

$ mvn -Dflyway.user=databaseUser -Dflyway.password=databasePassword  -Dflyway.schemas=schemaName

Если конфигурация указана несколькими способами, то приоритет будет следующий:

System properties
Внешний файл конфигурации
Раздел <properties>
Раздел <configuration> плагина

3. Пример миграции

В этом разделе мы рассмотрим необходимые шаги для миграции схемы базы данных на примере in-memory базы данных H2 с помощью maven-плагина. Для конфигурации Flyway мы будем использовать внешний файл.

3.1. Изменения в POM

Для начала, добавим зависимость на H2:

<dependency>    <groupId>com.h2database</groupId>    <artifactId>h2</artifactId>    <version>1.4.196</version></dependency>

Здесь мы также можем проверить последнюю доступную версию драйвера в Maven Central. Плагин для Flyway добавляем, как было описано ранее.

3.2. Настройка Flyway во внешнем файле

Создаем в $PROJECT_ROOT файл myFlywayConfig.properties со следующим содержимым:

flyway.user=databaseUserflyway.password=databasePasswordflyway.schemas=app-dbflyway.url=jdbc:h2:mem:DATABASEflyway.locations=filesystem:db/migration

Приведенная выше конфигурация указывает, что скрипты миграции находятся в каталоге db/migration, а для подключения к базе данных H2 используются databaseUser и databasePassword.

Схема базы данных для приложения app-db.

Конечно, в параметрах flyway.user, flyway.password и flyway.url необходимо указать имя, пароль и URL вашей базы данных.

3.3. Первая миграция

По соглашениям Flyway имена скриптов миграции должны быть в следующем формате:

<Prefix><Version>__<Description>.sql

Где:

<Prefix> префикс. Для версионных миграций по умолчанию равен V. Префикс настраивается через свойство flyway.sqlMigrationPrefix.
<Version> номер версии миграции. Мажорную и минорную версии можно разделить подчеркиванием. Версия всегда должна начинаться с 1.
<Description> текстовое описание миграции. Описание должно быть отделено от номера версии двумя подчеркиваниями.

Пример: V1_1_0__my_first_migration.sql

Итак, давайте создадим каталог db/migration в $PROJECT_ROOT со скриптом миграции V1_0__create_employee_schema.sql и SQL для создания таблицы employee:

CREATE TABLE IF NOT EXISTS `employee` (     `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,    `name` varchar(20),    `email` varchar(50),    `date_of_birth` timestamp )ENGINE=InnoDB DEFAULT CHARSET=UTF8;

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

Далее, в $PROJECT_ROOT запускаем следующую команду maven для применения миграций базы данных:

$ mvn clean flyway:migrate -Dflyway.configFile=myFlywayConfig.properties

Должна выполниться наша первая миграция.
Теперь схема базы данных выглядит следующим образом:
employee:

+----+------+-------+---------------+| id | name | email | date_of_birth |+----+------+-------+---------------+

Мы можем повторить предыдущие шаги для выполнения других миграций.

3.5. Вторая миграция

Для второй миграции создаем файл с именем V2_0_create_department_schema.sql, содержащий следующие два запроса:

CREATE TABLE IF NOT EXISTS `department` ( `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,`name` varchar(20) )ENGINE=InnoDB DEFAULT CHARSET=UTF8; ALTER TABLE `employee` ADD `dept_id` int AFTER `email`;

Выполним миграцию, также как делали для первой миграции.
Теперь схема нашей базы данных изменилась: в employee добавлен новый столбец и создана новая таблица department:

employee:

+----+------+-------+---------+---------------+| id | name | email | dept_id | date_of_birth |+----+------+-------+---------+---------------+

department:

+----+------+| id | name |+----+------+

Для проверки, что обе миграции прошли успешно, запустим следующую команду maven:

$ mvn flyway:info
-Dflyway.configFile=myFlywayConfig.properties

4. Отключение Flyway в Spring Boot

Иногда может потребоваться отключить Flyway-миграции.

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

В Spring Boot это сделать очень просто.

4.1. Spring Boot 1.x

Все, что нам нужно сделать, это установить свойство flyway.enabled в файле application-test.properties:

flyway.enabled=false

4.2. Spring Boot 2.x

В более поздних версиях Spring Boot это свойство было изменено на

spring.flyway.enabled:spring.flyway.enabled=false

4.3 Пустая FlywayMigrationStrategy

Если мы хотим отключить только автоматическую миграцию Flyway при запуске, но хотим запускать миграции вручную, то использование вышеописанных свойств нам не подойдет.

Это связано с тем, что Spring Boot не будет автоматически конфигурировать бины Flyway и, следовательно, нам придется настраивать их самостоятельно, что не очень удобно.

В этом случае мы можем оставить Flyway включенным и реализовать пустую FlywayMigrationStrategy:

@Configurationpublic class EmptyMigrationStrategyConfig {     @Bean    public FlywayMigrationStrategy flywayMigrationStrategy() {        return flyway -> {            // do nothing         };    }}

Фактически это отключит Flyway-миграции при запуске приложения.

Но мы все равно можем запускать миграции вручную:

@RunWith(SpringRunner.class)@SpringBootTestpublic class ManualFlywayMigrationIntegrationTest {     @Autowired    private Flyway flyway;     @Test    public void skipAutomaticAndTriggerManualFlywayMigration() {        flyway.migrate();    }}

5. Как работает Flyway

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

Фреймворк работает следующим образом:

Проверяет схему базы данных на наличие таблицы метаданных (по умолчанию SCHEMA_VERSION). Если таблица метаданных не существует, то создает ее.
Сканирует classpath на наличие доступных миграций.
Сравнивает миграции с таблицей метаданных. Если номер версии меньше или равен версии, помеченной как текущая, то игнорирует ее.
Отмечает все оставшиеся миграции как ожидающие (pending). Потом сортирует их по возрастанию номеров версий и выполняет в указанном порядке.
По мере применения миграций обновляет таблицу метаданных.

6. Команды

В Flyway есть следующие основные команды по управлению миграциями:

Info. Отображение текущего состояния / версии схемы базы данных. Информация о том, какие миграции ожидаются, какие были применены, состояние выполненных миграций и дата их выполнения.
Migrate. Обновление схемы базы данных до текущей версии. Сканирование classpath для поиска доступных миграций и применение ожидающих миграций.
Baseline. Установка версии схемы базы данных, игнорируя миграции до baselineVersion включительно. Baseline помогает использовать Flyway на уже существующей базе данных. Новые миграции применяются в обычном режиме.
Validate. Проверка текущей схемы базы данных на соответствие доступным миграциям.
Repair. Восстановление таблицы метаданных.
Clean. Удаление всех объектов в схеме. Конечно, никогда не нужно использовать clean в продакшен базах данных.

7. Заключение

В этой статье мы показали, как работает Flyway и как его можно использовать для надежного и простого управления изменениями базы данных.
Код статьи доступен на GitHub.

УПРАВЛЯЕМ ВЕРСИЯМИ БАЗ ДАННХ ЧЕРЕЗ FLYWAY