Настройка репликации PostgreSQL в контейнерах Docker

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

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

Мы рассмотрим процесс поднятия двух контейнеров с 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

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

docker ps

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

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

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

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

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

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

docker exec -it postgresql_01 bash

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

su - postgres

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

createuser --replication -P repluser

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

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

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

exit

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

exit

Открываем конфигурационный файл 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;'"

Читайте также

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

1. Установка Docker на Linux

2. Настройка потоковой репликации PostgreSQL

# Linux # Серверы # Базы данных # DevOps
Дмитрий Моск — частный мастер
Была ли полезна вам эта инструкция?

Да            Нет