Используемые термины: PostgreSQL , Docker .
Мы рассмотрим процесс поднятия двух контейнеров с PostgreSQL и настройки репликации данных между ними. Использовать будем систему на базе Linux, однако, сам процесс настройки Docker и репликации не зависит от операционной системы.
Предварительная настройка
Создаем контейнеры с PostgreSQL
Настраиваем кластер СУБД
На стороне основного сервера
На стороне реплики
Проверяем синхронизацию данных
Читайте также
Подготовка компьютера
На компьютере, где мы будем запускать наш кластер баз данных должен быть установлен 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;'»
Читайте также
Вам могут быть полезны следующие инструкции:
