Поднимаем кластер PostgreSQL в Docker и Testcontainers

Привет Хабр!

В одной их своих предыдущих статей я рассказывал о том, как запустить PostgreSQL в Docker. Тогда речь шла об использовании «ванильных» образов Postgres и поднятии одного хоста. В большинстве случаев этого достаточно как для тестов, так и для экспериментов, но нужно понимать, что в промышленной эксплуатации чаще всего используются высокодоступные (отказоустойчивые, кластеризованные) конфигурации PostgreSQL.

Такое решение помимо собственно отказоустойчивости позволяет частично решить проблему производительности, перераспределяя чтение данных с primary хоста на реплики. Все запросы на запись при этом по-прежнему будут идти на primary хост.

Терминология

Небольшое отступление касательно терминологии:

• primary = master = мастер-хост

• slave = standby = secondary = реплика

• failover — автоматический процесс превращения резервного хоста (реплики) в основной (при возникновении аварийной ситуации). Реплика становится новым primary и начинает обслуживать запрос на запись.

• switchover — ручной процесс переноса primary с одного хоста на другой в кластере.

Больше терминологии здесь.

Из коробки PostgreSQL предоставляет механизм для превращения (promote) реплики в primary в случае аварии, но не предоставляет полноценного решения для построения HA-кластера (High Availability). На рынке существует целый ряд таких решений от разных вендоров (вы можете встретить термин HA-утилиты). Я рекомендую посмотреть видеодоклад Алексея Лесовского для расширения кругозора в этой области.

Наверное, самым популярным решением на данный момент является Patroni, но я в этой статье буду использовать repmgr от EnterpriseDB. Дело в том, что для repmgr уже есть готовые образы от bitnami, которые регулярно обновляются.

Отказоустойчивость в кластере PostgreSQL достигается за счёт WAL и потоковой репликации. Более подробно об этом можно почитать в блоге Selectel. Важно понимать: любые изменения, которые вы совершаете на primary, сначала попадают в WAL, а потом транслируются по сети на реплику и проигрываются там. 

Лирическое отступление

Поэтому выполнение какой-либо DML команды, обернутое в блок BEGIN/ROLLBACK, не является безопасным: оно защищает только от видимого внешнему наблюдателю изменения данных, но потенциально может замедлить или даже уронить ваш кластер БД.

Например, есть большая таблица на 100 Гбайт; нужно проверить миграцию, которая обновит примерно половину строк в этой таблице. Что может пойти не так? Может закончиться CPU или место на диске (MVCC и WAL), забиться сеть. В это время все остальные запросы, приходящие на кластер, будут простаивать и, вероятно, прерываться по таймауту. Снаружи ситуация будет выглядеть как denial of service.

Прежде чем выполнить какую-либо команду на БД, подумайте, к чему она приведёт.

Кластер через docker-compose

Сначала давайте поднимем кластер PostgreSQL в Docker через compose-файл. Исходные коды, как обычно, доступны на GitHub.

Мой вариант compose-файла базируется на таковом от bitnami. Дополнительно я добавил мониторинг через postgres_exporter. Для запуска выполните команду из директории с compose-файлом:

docker-compose --project-name="habr-pg-ha-14" up -d

Имейте в виду, что кластер будет подниматься некоторое время: на Linux быстрее, на macOS/Windows дольше. В зависимости от мощности вашего компьютера для старта кластера может потребоваться до двух минут.

version: "3.9" services:   pg-1:     container_name: postgres_1     image: docker.io/bitnami/postgresql-repmgr:14.9.0     ports:       - "6432:5432"     volumes:       - pg_1_data:/bitnami/postgresql       - ./create_extensions.sql:/docker-entrypoint-initdb.d/create_extensions.sql:ro     environment:       - POSTGRESQL_POSTGRES_PASSWORD=adminpgpwd4habr       - POSTGRESQL_USERNAME=habrpguser       - POSTGRESQL_PASSWORD=pgpwd4habr       - POSTGRESQL_DATABASE=habrdb       - REPMGR_PASSWORD=repmgrpassword       - REPMGR_PRIMARY_HOST=pg-1       - REPMGR_PRIMARY_PORT=5432       - REPMGR_PARTNER_NODES=pg-1,pg-2:5432       - REPMGR_NODE_NAME=pg-1       - REPMGR_NODE_NETWORK_NAME=pg-1       - REPMGR_PORT_NUMBER=5432       - REPMGR_CONNECT_TIMEOUT=1       - REPMGR_RECONNECT_ATTEMPTS=2       - REPMGR_RECONNECT_INTERVAL=1       - REPMGR_MASTER_RESPONSE_TIMEOUT=5     restart: unless-stopped     networks:       - postgres-ha    pg-2:     container_name: postgres_2     image: docker.io/bitnami/postgresql-repmgr:14.9.0     ports:       - "6433:5432"     volumes:       - pg_2_data:/bitnami/postgresql       - ./create_extensions.sql:/docker-entrypoint-initdb.d/create_extensions.sql:ro     environment:       - POSTGRESQL_POSTGRES_PASSWORD=adminpgpwd4habr       - POSTGRESQL_USERNAME=habrpguser       - POSTGRESQL_PASSWORD=pgpwd4habr       - POSTGRESQL_DATABASE=habrdb       - REPMGR_PASSWORD=repmgrpassword       - REPMGR_PRIMARY_HOST=pg-1       - REPMGR_PRIMARY_PORT=5432       - REPMGR_PARTNER_NODES=pg-1,pg-2:5432       - REPMGR_NODE_NAME=pg-2       - REPMGR_NODE_NETWORK_NAME=pg-2       - REPMGR_PORT_NUMBER=5432       - REPMGR_CONNECT_TIMEOUT=1       - REPMGR_RECONNECT_ATTEMPTS=2       - REPMGR_RECONNECT_INTERVAL=1       - REPMGR_MASTER_RESPONSE_TIMEOUT=5     restart: unless-stopped     networks:       - postgres-ha    pg_exporter-1:     container_name: pg_exporter_1     image: prometheuscommunity/postgres-exporter:v0.11.1     command: --log.level=debug     environment:       DATA_SOURCE_URI: "pg-1:5432/habrdb?sslmode=disable"       DATA_SOURCE_USER: habrpguser       DATA_SOURCE_PASS: pgpwd4habr       PG_EXPORTER_EXTEND_QUERY_PATH: "/etc/postgres_exporter/queries.yaml"     volumes:       - ./queries.yaml:/etc/postgres_exporter/queries.yaml:ro     ports:       - "9187:9187"     networks:       - postgres-ha     restart: unless-stopped     depends_on:       - pg-1    pg_exporter-2:     container_name: pg_exporter_2     image: prometheuscommunity/postgres-exporter:v0.11.1     command: --log.level=debug     environment:       DATA_SOURCE_URI: "pg-2:5432/habrdb?sslmode=disable"       DATA_SOURCE_USER: habrpguser       DATA_SOURCE_PASS: pgpwd4habr       PG_EXPORTER_EXTEND_QUERY_PATH: "/etc/postgres_exporter/queries.yaml"     volumes:       - ./queries.yaml:/etc/postgres_exporter/queries.yaml:ro     ports:       - "9188:9187"     networks:       - postgres-ha     restart: unless-stopped     depends_on:       - pg-2  networks:   postgres-ha:     driver: bridge  volumes:   pg_1_data:   pg_2_data: 

Инициируем auto failover

Одной из функциональных возможностей repmgr является switchover — ручная управляемая смена мастер-хоста в кластере. К сожалению, в образах от bitnami эта операция не поддерживается (в старом репозитории была issue на это, но сейчас репозиторий удален).

Для тестирования доступен только failover режим. Как его инициировать? Просто погасите контейнер с primary:

docker stop postgres_1

В логах на реплике появятся записи типа:

LOG:  database system was not properly shut down; automatic recovery in progress … LOG:  database system is ready to accept connections

После этого бывшая реплика станет primary и будет готова обслуживать запросы на запись.

Теперь можно вернуть обратно в строй первый хост:

docker start postgres_1

Он поднимется, увидит, что есть новый мастер, и продолжит функционировать как реплика:

INFO  ==> This node was acting as a primary before restart!  INFO  ==> Current master is 'pg-2:5432'. Cloning/rewinding it and acting as a standby node...  ...  LOG:  database system is ready to accept read-only connections

Кто сейчас primary?

Возникает вопрос: «Как понять, в какой роли функционирует конкретный хост?» Ответить на него поможет простой запрос:

select case when pg_is_in_recovery() then 'secondary' else 'primary' end as host_status;

Из консоли контейнера его удобнее выполнять без явного входа в psql:

psql -c "select case when pg_is_in_recovery() then 'secondary' else 'primary' end as host_status;" "dbname=habrdb user=habrpguser password=pgpwd4habr"

А ещё удобнее сделать это из командной строки:

docker exec postgres_1 psql -c "select case when pg_is_in_recovery() then 'secondary' else 'primary' end as host_status;" "dbname=habrdb user=habrpguser password=pgpwd4habr"

Кластер в Testcontainers

Автоматизированное тестирование и Continuous Integration (CI) — две практики, которые, на мой взгляд, сильно изменили разработку ПО. Когда нужно проверить взаимодействие приложения с каким-либо хранилищем или брокером сообщений, удобно и полезно использовать Testcontainers. В библиотеке pg-index-health, которую я совместно с open source сообществом поддерживаю и развиваю, есть функционал по сбору статистики на всех хостах кластера. Для его полноценной проверки нам потребовалось поднимать кластер PostgreSQL в end-to-end тестах.

Готового модуля для кластера в Testcontainers не было, поэтому мы сделали небольшую обёртку PostgresBitnamiRepmgrContainer над стандартным JdbcDatabaseContainer и упаковали всё это в PostgreSqlClusterWrapper. Большое спасибо Алексею @Evreke Антипину за проделанную работу!

PostgreSqlClusterWrapper умеет поднимать двухнодовый кластер, а также «гасить» первый хост, вызывая тем самым auto failover. Jar-ник доступен в Maven Central.

Основной сложностью стала правильная инициализация кластера: поднять первый хост, затем второй; дождаться, пока второй хост войдет в кластер и начнёт стримить WAL с primary. Для этой цели мы использовали LogMessageWaitStrategy и Awaitility.

Зачем PostgreSqlClusterWrapper может пригодиться вам? Главным образом, это возможность проверить поведение вашего приложения при возникновении нештатной ситуации на БД: сможет ли оно продолжить корректно работать при смене мастера.

Тюнинг параметров JDBC драйвера

JDBC driver поддерживает клиентскую балансировку и сам может переподключаться к новому primary-хосту, если в connection URL указать сразу несколько хостов базы данных.

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

jdbc:postgresql://localhost:32769,localhost:32770/test_db?connectTimeout=1&hostRecheckSeconds=2&socketTimeout=600&targetServerType=primary

Здесь мы видим два инстанса БД на разных портах: localhost:32769 и localhost:32770, но гораздо важнее и интереснее параметры подключения.

targetServerType=primary указывает, что нас интересует только мастер-хост БД. Если вы хотите организовать чтение с реплики, то вам подойдёт вариант targetServerType=secondary или targetServerType=preferSecondary.

Параметр connectTimeout определяет, как много времени мы готовы ждать до установления соединения с сервером БД. Значение по умолчанию — 10 секунд. Уменьшение этого значения позволяет более агрессивно перебирать хосты в списке и пытаться к ним подключиться.

Опция hostRecheckSeconds влияет на частоту проверки, кто у нас сейчас мастер, а кто реплика.

И, наконец, socketTimeout выступает в качестве глобального ограничителя времени выполнения всех запросов к БД. Установка этого параметра не обязательна; более того, конкретное значение нужно аккуратно подбирать под ваши нужды.

Безусловно, это далеко не все параметры, которые поддерживает JDBC драйвер, но это, на мой взгляд, необходимый минимум.

В промышленных приложениях обычно используется пул соединений к БД. Каждая реализация connection pool’а имеет свой набор параметров, позволяющих тонко управлять соединениями в пуле. Более подробно об этом можно почитать в статье Database timeouts. Для HikariCP, как минимум, имеет смысл настроить connectionTimeout и validationTimeout:

import com.zaxxer.hikari.HikariConfig; import com.zaxxer.hikari.HikariDataSource;  import javax.annotation.Nonnull;  import lombok.SneakyThrows; import lombok.experimental.UtilityClass; import org.postgresql.Driver;  @UtilityClass public class HikariDataSourceProvider {      @Nonnull     @SneakyThrows     public HikariDataSource getDataSource(@Nonnull final String jdbcUrl,                                           @Nonnull final String username,                                           @Nonnull final String password) {         final HikariConfig hikariConfig = new HikariConfig();         hikariConfig.setMaximumPoolSize(3);         hikariConfig.setConnectionTimeout(250L);         hikariConfig.setMaxLifetime(30_000L);         hikariConfig.setValidationTimeout(250L);         hikariConfig.setJdbcUrl(jdbcUrl);         hikariConfig.setUsername(username);         hikariConfig.setPassword(password);         hikariConfig.setDriverClassName(Driver.class.getCanonicalName());         return new HikariDataSource(hikariConfig);     } } 

Я подготовил пару приложений, демонстрирующих использование PostgreSqlClusterWrapper, и разместил их на GitHub: консольное и spring-boot. Пусть они станут отправной точкой для ваших экспериментов!