Как настроить репликацию PostgreSQL между нодами в контейнерах Docker

Опубликовано: 13.05.2021

Используемые термины: PostgreSQL, Docker.

Мы рассмотрим процесс поднятия двух контейнеров с PostgreSQL и настройки репликации данных между ними. Использовать будем систему на базе Linux, однако, сам процесс настройки Docker и репликации не зависит от операционной системы.

Подготовка компьютера

На компьютере, где мы будем запускать наш кластер баз данных должен быть установлен Docker. Также мы сразу рассмотрим развертывание нужной нам инфраструктуры в docker-compose. Для установки необходимой одноименной платформы смотрим инструкцию Установка Docker на Linux.

После мы можем переходить к поднятию контейнеров.

Запуск контейнеров с СУБД

Как говорилось выше, мы будем поднимать наши контейнеры с помощью docker-compose.

Создадим каталог, в котором будем работать:

mkdir -p /opt/docker/postgresql

Переходим в него:

cd /opt/docker/postgresql

Создаем файл для docker-compose:

vi docker-compose.yml

—

services:

postgresql_01:
image: postgres
container_name: postgresql_01
restart: always
volumes:
– /data/postgresql_01:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: postgres024

postgresql_02:
image: postgres
container_name: postgresql_02
restart: always
volumes:
– /data/postgresql_02/:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: postgres024

* рассмотрим некоторый опции подробнее:

postgresql_01/postgresql_02 — названия для сервисов, контейнеры для которых мы будем поднимать.
image — образ, из которого будут создаваться контейнеры. В данном примере мы берем официальный образ postgres.
container_name — имя, которое будет присвоено контейнеру после его запуска. В нашем примере это postgresql_01 и postgresql_02.
restart — режим перезапуска. Говорит, в каких случаях наш контейнер должен стартовать.
volumes — хорошим тоном для работы базы данных в контейнере является проброс каталога хостового компьютера внутрь контейнера. Таким образом, после удаления контейнера данные останутся на компьютере. В нашем примере в каталоге /data будут созданы каталоги postgresql_01 и postgresql_02, которые будут прокинуты в каталог /var/lib/postgresql/data контейнера.
environment — для первого запуска необходима инициализация базы данных. Без пароля системы выдает ошибку. Поэтому мы задаем переменную среды POSTGRES_PASSWORD.

Запускаем наши контейнеры:

docker-compose up -d

Мы должны увидеть:

Creating postgresql_02 … done
Creating postgresql_01 … done

А если вывести список контейнеров:

… мы должны увидеть наши два.

Теперь можно переходить к настройке репликации.

Настройка репликации

Условимся, что первичный сервер или master будет в контейнере с названием postgresql_01. Вторичный — postgresql_02. Мы будем настраивать потоковую (streaming) асинхронную репликацию.

Настройка на мастере

Подключаемся к контейнеру docker:

docker exec -it postgresql_01 bash

Заходим под пользователем postgres:

su – postgres

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

createuser –replication -P repluser

* в данном примере будет создаваться учетная запись repluser с правами репликации.

Система потребует ввода пароля. Придумываем его и набираем дважды.

Выходим из-под пользователя postgres:

Выходим из контейнера:

Открываем конфигурационный файл postgresql.conf:

vi /data/postgresql_01/postgresql.conf

Приводим к следующием виду некоторые параметры:

wal_level = replica
max_wal_senders = 2
max_replication_slots = 2
hot_standby = on
hot_standby_feedback = on

* где

wal_level указывает, сколько информации записывается в WAL (журнал операций, который используется для репликации). Значение replica указывает на необходимость записывать только данные для поддержки архивирования WAL и репликации.
max_wal_senders — количество планируемых слейвов;
max_replication_slots — максимальное число слотов репликации (данный параметр не нужен для postgresql 9.2 — с ним сервер не запустится);
hot_standby — определяет, можно или нет подключаться к postgresql для выполнения запросов в процессе восстановления;
hot_standby_feedback — определяет, будет или нет сервер slave сообщать мастеру о запросах, которые он выполняет.

Посмотрим подсеть, которая используется для контейнеров с postgresql:

docker network inspect postgresql_default | grep Subnet

В моем случае, ответ был:

“Subnet”: “172.19.0.0/16”,

Теперь открываем файл:

vi /data/postgresql_01/pg_hba.conf

И добавляем строку после остальных «host replication»:

host replication all 172.19.0.0/16 md5

* в данном примере мы разрешили подключение пользователю replication из подсети 172.19.0.0/16 с проверкой подлинности по паролю.

Перезапустим докер контейнер:

docker restart postgresql_01

Настройка на слейве

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

rm -r /data/postgresql_02/*

* в данном примере мы удалим все содержимое каталога /data/postgresql_02.

Мы должны быть уверены, что в базе нет ничего важного. Только после этого стоить удалять данные.

Заходим внутрь контейнера postgresql_02:

docker exec -it postgresql_02 bash

Выполняем команду:

su – postgres -c “pg_basebackup –host=postgresql_01 –username=repluser –pgdata=/var/lib/postgresql/data –wal-method=stream –write-recovery-conf”

* где postgresql_01 — наш мастер; /var/lib/postgresql/data — путь до каталога с данными слейва.

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

Проверка

Смотрим статус работы мастера:

docker exec -it postgresql_01 su – postgres -c “psql -c ‘select * from pg_stat_replication;'”

Смотрим статус работы слейва:

docker exec -it postgresql_02 su – postgres -c “psql -c ‘select * from pg_stat_wal_receiver;'”

ADMINS24