Создание кластера Postgres на Ubuntu с помощью Patroni + Consul
Опубликовано:
Используемые термины: Patroni,
Кластер Postgresql, созданный штатными средствами не совсем удобен в эксплуатации — у него сложные механизмы отслеживания проблем с репликацией, нет возможности автоматического переключения с основной ноды на резервную и обратно, сложный процесс восстановления после падения. Приложение Patroni позволяет сделать процесс управления кластером Postgresql проще. Оно хранит данные кластера в базе типа key-value и ориентируется на работоспособность системы с помощью DCS (Distributed Control Service). В качестве таких систем для Patroni могут выступать:
- Consul Hashicorp.
- Kubernetes.
- Zookeeper.
- etcd.
В данной инструкции мы рассмотрим процесс установки и настройки Patroni с Consul.
Предполагается, что у нас уже есть кластер consul, а также серверы с установленным Postgresql (чистыми без полезных данных). На последних также должны быть установлены consul в режиме агента или сервера. Ссылки на необходимые материалы будут приведены в конце данной инструкции.
Предварительная настройка
Прежде чем перейти к настройке patroni и кластера, подготовим наши серверы баз данных.
Настройка брандмауэра
Если на наших серверах используется брандмауэр, то нам нужно открыть порт 5432, по которому работает postgresql, а также порт 8008 для patroni.
Вводим команды:
iptables -I INPUT -p tcp --dport 5432 -j ACCEPT
iptables -I INPUT -p tcp --dport 8008 -j ACCEPT
Для сохранения правил вводим:
apt install iptables-persistent
netfilter-persistent save
Подготовка СУБД
Patroni самостоятельно инициализирует базу и настройки, поэтому наш каталог с данными Postgresql должен быть чист, а сервис postgresql находится в выключенном состоянии.
Если на вашем сервере баз данных есть данные, действия ниже приведут к их потере. В этом случае стоит развернуть кластер на других серверах и перенести данные.
На наших серверах СУБД смотрим путь до каталога с данными:
su - postgres -c "psql -c 'SHOW data_directory;'"
В моем случае для обоих серверов путь был /var/lib/postgresql/14/main — сохраняем путь. Скоро он нам понадобиться.
Останавливаем сервис postgres и запрещаем его автозапуск:
systemctl disable postgresql --now
Удаляем содержимое каталога с данными, путь до которого нам вернула команда SHOW data_directory:
rm -rf /var/lib/postgresql/14/main/*
Готово. Можно переходить к установке и настройке Patroni.
Установка и настройка Patroni
Данное приложение разработано на Python и требует установки как последнего, так и некоторых его компонентов.
Выполняем команду:
apt install python3 python3-pip python3-psycopg2
* в нашем примере мы будем работать с python версии 3. Также нам нужна библиотека для работы с postgresql python3-psycopg2.
Теперь ставим сам patroni, как приложение python:
pip3 install patroni[consul]
Установка завершена. Переходим к настройке.
Создадим каталог для хранения конфигурации:
mkdir /etc/patroni
И сам конфигурационный файл:
vi /etc/patroni/patroni.yml
name: postgres01.dmosk.local
scope: pgdb
watchdog:
mode: off
consul:
host: "localhost:8500"
register_service: true
#token: <consul-acl-token>
restapi:
listen: 0.0.0.0:8008
connect_address: "192.168.0.11:8008"
auth: 'patrest:password'
bootstrap:
dcs:
ttl: 30
loop_wait: 10
maximum_lag_on_failover: 1048576
postgresql:
use_pg_rewind: true
use_slots: true
parameters:
archive_mode: "on"
wal_level: hot_standby
max_wal_senders: 10
wal_keep_segments: 8
archive_timeout: 1800s
max_replication_slots: 5
hot_standby: "on"
wal_log_hints: "on"
initdb:
- encoding: UTF8
- data-checksums
pg_hba:
- local all all trust
- host replication replicator 192.168.0.0/24 md5
- host replication replicator 127.0.0.1/32 trust
- host all all 0.0.0.0/0 md5
postgresql:
pgpass: /var/lib/postgresql/14/.pgpass
listen: 0.0.0.0:5432
connect_address: "192.168.0.11:5432"
data_dir: /var/lib/postgresql/14/main/
bin_dir: /usr/lib/postgresql/14/bin/
pg_rewind:
username: postgres
password: password
pg_hba:
- local all all trust
- host replication replicator 192.168.0.0/24 md5
- host replication replicator 127.0.0.1/32 trust
- host all all 0.0.0.0/0 md5
replication:
username: replicator
password: password
superuser:
username: postgres
password: password
* данные конфигурационные файлы на разных серверах будут немного различаться. Опишем подробнее опции, на которые нам нужно обратить внимание:
- name — имя узла, на котором настраивается данный конфиг.
- scope — имя кластера. Его мы будем использовать при обращении к ресурсу, а также под этим именем будет зарегистрирован сервис в consul.
- consul - token — если наш кластер consul использует ACL, необходимо указать токен.
- restapi - connect_address — адрес на настраиваемом сервере, на который будут приходить подключения к patroni.
- restapi - auth — логин и пароль для аутентификации на интерфейсе API.
- pg_hba — блок конфигурации pg_hba для разрешения подключения к СУБД и ее базам. Необходимо обратить внимание на подсеть для строки host replication replicator. Она должна соответствовать той, которая используется в вашей инфраструктуре.
- postgresql - pgpass — путь до файла, который создаст патрони. В нем будет храниться пароль для подключения к postgresql.
- postgresql - connect_address — адрес и порт, которые будут использоваться для подключения к СУДБ.
- postgresql - data_dir — путь до файлов с данными базы.
- postgresql - bin_dir — путь до бинарников postgresql.
- pg_rewind, replication, superuser — логины и пароли, которые будут созданы для базы.
Создадим юнит в systemd для patroni:
vi /lib/systemd/system/patroni.service
[Unit]
Description=Patroni service
After=syslog.target network.target
[Service]
Type=simple
User=postgres
Group=postgres
ExecStart=/usr/local/bin/patroni /etc/patroni/patroni.yml
ExecReload=/bin/kill -s HUP $MAINPID
KillMode=process
TimeoutSec=30
Restart=no
[Install]
WantedBy=multi-user.target
* обратите внимание, что в официальной документации предлагается не перезапускать автоматически службу (Restart=no). Это дает возможность разобраться в причине падения базы.
Перечитываем конфигурацию systemd:
systemctl daemon-reload
Разрешаем автозапуск и стартуем сервис:
systemctl enable patroni --now
Проверяем статусы сервиса на обоих серверах:
systemctl status patroni
Посмотреть список нод
patronictl -c /etc/patroni/patroni.yml list pgdb
* где pgdb — имя нашей базы (указана с использованием директивы scope в конфигурационном файле patroni).
Мы должны увидеть что-то на подобие:
+------------------------+--------------+---------+---------+----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+ Cluster: pgdb (7126124696482454785) --+---------+---------+----+-----------+
| postgres01.dmosk.local | 192.168.0.11 | Leader | running | 1 | |
| postgres02.dmosk.local | 192.168.0.12 | Replica | running | 1 | 0 |
+------------------------+--------------+---------+---------+----+-----------+
Можно проверить, что сервер консул разрешает имена кластера:
nslookup -port=8600 master.pgdb.service.consul 127.0.0.1
nslookup -port=8600 replica.pgdb.service.consul 127.0.0.1
* где consul — настроенный в consul домен.
Команды нам должны вернуть адреса соответствующих серверов — лидера и реплики.
Наш кластер в рабочем состоянии.
Читайте также
Другие инструкции, имеющие отношение к кластеризации Postgres:
1. Установка и запуск PostgreSQL на Ubuntu.
2. Установка и настройка кластера Consul Hashicorp на Linux Ubuntu.
3. Установка агента Consul и примеры регистрации сервисов.
