Repmgr: управление репликацией postgresql
PostgreSQL - это мощная и очень развитая база данных, функциональная и дружелюбная. В комплект входит надежный и очень удобный механизм потоковой репликации (я писал о нем здесь). Не смотря на мощь и удобство – этот инструмент сложен в настройке и не всегда понятен, особенно, если серверов баз много. Все становится еще хуже, если у вас сложная схема репликации с каскадами (master > slave > slave of slave). Чтобы облегчить жизнь DBA в таких ситуациях – известные специалисты по консалтингу Postgres, компания 2ndQuadrant придумали repmgr – специальный инструмент для управления настройками репликации для PostgreSQL.
Repmgr может:
- облегчить создание новых серверов
- облегчить переключение на другой сервер (promote)
- автоматизировать переключение на новый сервер при отказе старого (failover)
- вести аудит событий репликации в кластере (event flow)
- официально repmgr поддерживает мультимастер с помощью механизма bidirectional replication. Это жуткий грязный хак, и я очень не рекомендую его использовать
Repmgr требует (ограничения):
- postgresql 9 или 10 (так как только в 9 версии появилась потоковая репликаця)
- доступ с каждого узла кластера на каждый узел кластера по протоколам SSH (непривелигированый) и postgresql (5432)
- одинаковую версию Postgres (только major)
- одинаковую архитектуру сервера (вы не сможете реплицировать данные с ARM на AMD64)
- одинаковую версию repmgr на всех узлах кластера (одинаковость должна быть полной)
- пользователя с правами SUPERUSER, от имени которого repmgr будет проводить операции. Пароль от этого пользователя хранится в файловой системе кластера в открытом виде.
Установка
Repmgr поставляется в виде пакета и входит в стандартный для всех пользователей postgresql репозиторий PGDG. В данной статье я продемонстрирую настройку для debian, но для centos он настраивается практически так же – меняются только пути доступа к файлам. Добавим репозиторий:
sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -
apt-get update
Теперь можно установить необходимые для работы пакеты:
apt-get install postgresql-10 postgresql-10-repmgr -y
Для repmgr важно, чтобы все хосты видели друг друга по hostname. Я рекомендую иметь внутренний DNS для решения этой задачи, но если у вас по какой-то причине его нет – придется добавить имена и адреса серверов кластера в /etc/hosts. Например:
192.168.0.17 pg1.lab.office pg1
192.168.0.18 pg2.lab.office pg2
192.168.0.19 pg3.lab.office pg3
Для того, что бы repmgr мог копировать базу с одного сервера на другой – пользователю repmgrd нужен доступ по ssh без ввода пароля. Для этого на каждом из серверов нужно сгенерировать ssh public key. Этот public key нужно положить на все остальные сервера кластера в файл ~/.ssh/authorized_keys. Это нужно сделать для пользователя, от которого будет запущен repmgr. Обычно это тот же пользователь, от имени которого запущен postgres. Создадим ключи на каждом сервере:
sudo -u postgres ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/var/lib/postgresql/.ssh/id_rsa):
Created directory '/var/lib/postgresql/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/lib/postgresql/.ssh/id_rsa.
Your public key has been saved in /var/lib/postgresql/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:oqFJ3/Gr8oeBgQpAsKSlImbUOLroa/YaFbJ8AxlsBng postgresql@pg1
Публичный ключ из файла /var/lib/postgresql/.ssh/id_rsa.pub надо добавить на все остальные сервера кластера, в файл ~/.ssh/authorized_keys. Заодно поправим права:
#на сервере pg1
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCoavDuAETBMZBD0NwRvSEDYL1avCIkSLzxMG50L6b7nIeasrfv90AGjARxID9THkUXDNkdKhfRIu+WGFYxlgZ6zqPQCyZyQvKjcJr325pbo9it474LpLpeHuPrXdeMSzSilxvAKvYX/ml7L9KtOnYMDusFK1XdGeV25qcj2OSLWBY168riW5vvGWFYTCdU6q9eQ+JN2zCpoZzXKNqhh+dpItt1QiKRw84u7EtUW6U02tw1V5nmO+HGyG2A50S5/JNS7lbj/7IYAXwIgtlBrf3mzCPCIoHbjlSny/V6sp3S7QWNrxynpkI7o+oMvJq5frAEpn0syiUmtOz56Qnw67GP postgres@pg2" >> /var/lib/postgresql/.ssh/authorized_keys
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDfl8Rg47u97kGUPf7OwF4jeGhcIxVtWEVDk1AKJt5o3Y65v5jzrjoI5F0YrboEzr+oPu5BV24M6dOI5u3ysRBX/osQI2fBlt+hotAIWXPiP8UUy9CgIdQH59h/MJcp3jPH0KYQTwF8WJDr1skUcUzKGswuofBaElm5TpME+Oz2vygXEl2vL9Pfo5kfdsk9ov58cUJNlDGtxTo/Rzw9XFRnkBimzwvem/gmdpYBFb45ulsbLVmdBcv+QTU7PQ+knqIyERboTecS8wBYoKnlCTA0LZscvyeHjKwILSl9ZFfir3CRdYtxNqx4Zk/hMphx4Bt7hn96KUXRiMf3ODpd2yp1 postgres@pg3" >> /var/lib/postgresql/.ssh/authorized_keys
chown postgres /var/lib/postgresql/.ssh/authorized_keys
chmod 600 /var/lib/postgresql/.ssh/authorized_keys
Убедимся, что доступ есть:
root@pg1:~# sudo -u postgres ssh pg2.lab.office -x 'w'
09:04:07 up 3 days, 23:48, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
logan pts/0 192.168.0.70 14:28 1:19 0.22s 0.02s sshd: logan [priv]
Для остальных серверов делаем по аналогии.
Для того, чтобы процесс repmgr мог сам перезапускать постгрес - ему нужны соответствующие права. Чтобы их дать - создадим файл /etc/sudoers.d/repmgr и впишем туда:
Cmnd_Alias PGRE = /bin/systemctl status postgresql, \
/bin/systemctl start postgresql, \
/bin/systemctl stop postgresql, \
/bin/systemctl restart postgresql, \
/bin/systemctl reload postgresql
postgres ALL=(ALL) NOPASSWD: PGRE
Это позволит пользователю postgres перезапускать процесс сервера postgres.
Теперь нам надо настроить сам postgresql. Обязательный минимум:
- доступность из сети (директива
listen_addresses) - репликация (
wal_level,archive_mode) - лимит
max_wal_senders- как минимум на 1 больше количества серверов в кластере hot_standby- для серверов в режиме slave.- права на репликацию в hba
Если вы строите кластер на debian - настройки надо скопировать на все сервера кластера. Для centos это не обязательно, так как файл настроек лежит прямо в data directory и при клонировании repmgr вытащит файлы.
Пример настроек - /etc/postgresql/10/main/postgresql.conf:
# тут приведены не все настройки, а только то, что я поменял
# часть настроек в файле закомментирована, а в части указаны другие значения.
# Пользуйтесь поиском.
listen_addresses = '*'
wal_level = replica
archive_mode = on
archive_command = 'cp %p /var/lib/pg-arch/%f'
max_wal_senders = 4
hot_standby = on
В данном примере мы не удаляем архивированные сегменты, а перемещаем их папку /var/lib/pg-arch/. Это позволит восстановить “отставший” slave. Подробнее я писал здесь. Эту папку нужно создать (владелец - postgres, права доступа - 700). Папку нужно периодически чистить – postgres сам не очищает архивы. В упомянутой выше статье вы найдете детальное описание.
Пример настроек hba. В данном примере пользователь БД называется repmgr. Служебная база repmgr - repmgrdb:
# Не менять! сломаются локальные операции!
local all postgres peer
# TYPE DATABASE USER ADDRESS METHOD
local all all md5
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
# replication settings
local replication all peer
host replication all 127.0.0.1/32 md5
host replication all ::1/128 md5
host repmgrdb repmgr 192.168.0.0/24 md5
host replication repmgr 192.168.0.0/24 md5
#remote access to server cluster. any DB, any user, any host, password required
host all all 0.0.0.0/0 md5
С настройкой postgres закончили, перезапускаем сервер и создаем служебную базу и пользователя. Пароль для пользователя лучше сделать посложнее:
service postgresql status
sudo -u postgres psql
psql (10.4 (Debian 10.4-2.pgdg90+1))
Type "help" for help.
postgres=# create user repmgr with superuser;
postgres=# alter role repmgr with password 'Ahn7yaechie6hoe0av8eF0ei';
postgres=# create database repmgrdb owner repmgr;
postgres=# \q
Чтобы repmgr мог обращаться к серверу БД и ему не требовалось вводить пароль – нужно создать файл /var/lib/postgresql/.pgpass. Владельцем файла должен быть пользователь postgres, права - 0600 (иначе он игнорируется). Структура файла - IP:port:DB:user:password. * означает “любое”. К сожалению pgpass не в состоянии работать с CIDR, то есть задать адрес как 192.168.0.* можно, а 192.168.0.0/24 – нельзя. Пример файла:
*:5432:repmgrdb:repmgr:Ahn7yaechie6hoe0av8eF0ei
*:5432:replication:repmgr:Ahn7yaechie6hoe0av8eF0ei
Вторая запись нужна для самого процесса репликации.
Теперь настроим repmgr. Его настройки в debian лежат в файле /etc/repmgr.conf. Пример с комментариями:
# ID узла (сервера). В рамках кластера обязательно уникальный
node_id=1
# hostname. Остальные узлы должны иметь возможность найти этот именно по этому имени.
node_name='pg1.lab.office'
# строка подключения к БД
conninfo='host=pg1.lab.office user=repmgr dbname=repmgrdb connect_timeout=2'
# директория с данными postgres.
data_directory='/var/lib/postgresql/10/main/'
# режим репликации. Пока что поддерживается только этот
replication_type=physical
# log file. Не забудьте создать папку для него.
log_file='/var/log/repmgr/repmgr.log'
# записывать статус каждые 5 минут (300 секунд)
log_status_interval=300
# где находятся bin-файлы postgres.
pg_bindir='/usr/lib/postgresql/10/bin/'
# не использовать password из conninfo (строки выше)
# мы храним пароль в .pgpass, это безопаснее. Потому - false
use_primary_conninfo_password=false
ssh_options='-q -o ConnectTimeout=10'
# режим failover
failover=manual
# очередность выборов мастера в случае отказа
# эта настройка и последующие применимы только если failover - auto
priority=100
reconnect_attempts=3
reconnect_interval=5
promote_command='/usr/bin/repmgr -f /etc/repmgr.conf standby promote --log-to-file'
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'
# команды запуска, остановки и перезапуска сервиса. Должны соответствовать тому, что мы вписали в sudo.
service_start_command = 'sudo -n /bin/systemctl start postgresql'
service_stop_command = 'sudo -n /bin/systemctl stop postgresql'
service_restart_command = 'sudo -n /bin/systemctl restart postgresql'
service_reload_command = 'sudo -n /bin/systemctl reload postgresql'
Теперь можно зарегистрировать первый сервер в кластере:
sudo -u postgres repmgr -f /etc/repmgr.conf primary register
Проверим, что он там появился:
root@pg1:~# sudo -u postgres repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+----------------+---------+-----------+----------------+----------+-------------------------------------------------------------------
1 | pg1.lab.office | primary | * running | | default | host=pg1.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
Все ок. Теперь настроим остальные два сервера. Они настраиваются по аналогии с первым сервером. Только в конфиге repmgr.conf нужно поменять node_id, node_name и conninfo. На 2 и 3 серверах запускать postgres не нужно.
Удалим существующий data-dir и склонируем базу с мастера:
root@pg2:~# service postgresql stop
root@pg2:~# rm -rf /var/lib/postgresql/10/main/*
root@pg2:~# sudo -u postgres repmgr -f /etc/repmgr.conf -h pg1.lab.office -U repmgr -d repmgrdb standby clone
NOTICE: destination directory "/var/lib/postgresql/10/main/" provided
NOTICE: starting backup (using pg_basebackup)...
HINT: this may take some time; consider using the -c/--fast-checkpoint option
NOTICE: standby clone (using pg_basebackup) complete
NOTICE: you can now start your PostgreSQL server
HINT: for example: sudo -n /bin/systemctl start postgresql
HINT: after starting the server, you need to register this standby with "repmgr standby register"
Запускаем сервер, регистрируемся:
root@pg2:~# service postgresql start
root@pg2:~# sudo -u postgres /usr/bin/repmgr standby register
NOTICE: standby node "pg2.lab.office" (id: 2) successfully registered
Проверяем, что изменилось:
root@pg1:~# sudo -u postgres repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+----------------+---------+-----------+----------------+----------+-------------------------------------------------------------------
1 | pg1.lab.office | primary | * running | | default | host=pg1.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
2 | pg2.lab.office | standby | running | pg1.lab.office | default | host=pg2.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
Третий сервер запускаем по аналогии со вторым.
Failover
Итак, мастер сломался и надо переключится на slave:
root@pg2:~# sudo -u postgres repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+----------------+---------+---------------+----------------+----------+-------------------------------------------------------------------
1 | pg1.lab.office | primary | ? unreachable | | default | host=pg1.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
2 | pg2.lab.office | standby | running | pg1.lab.office | default | host=pg2.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
3 | pg3.lab.office | standby | running | pg1.lab.office | default | host=pg3.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
WARNING: following issues were detected
- when attempting to connect to node "pg1.lab.office" (ID: 1), following error encountered :
"could not connect to server: Connection refused
Is the server running on host "pg1.lab.office" (192.168.0.17) and accepting
TCP/IP connections on port 5432?"
- node "pg1.lab.office" (ID: 1) is registered as an active primary but is unreachable
Прежде чем продолжить – обязательно убедитесь, что старый мастер (pg1) отключен и не “оживет” в самый неподходящий момент. Repmgr не умеет работать с fencing-ом и вы можете потерять часть данных.
Повышаем pg2 до мастера:
root@pg2:~# sudo -u postgres repmgr -f /etc/repmgr.conf standby promote
NOTICE: promoting standby to primary
DETAIL: promoting server "pg2.lab.office" (ID: 2) using "/usr/lib/postgresql/10/bin/pg_ctl -w -D '/var/lib/postgresql/10/main/' promote"
waiting for server to promote.... done
server promoted
NOTICE: STANDBY PROMOTE successful
DETAIL: server "pg2.lab.office" (ID: 2) was successfully promoted to primary
Проверяем статус:
root@pg2:~# sudo -u postgres repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+----------------+---------+-----------+----------------+----------+-------------------------------------------------------------------
1 | pg1.lab.office | primary | - failed | | default | host=pg1.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
2 | pg2.lab.office | primary | * running | | default | host=pg2.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
3 | pg3.lab.office | standby | running | pg1.lab.office | default | host=pg3.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
pg3 по-прежнему ждет данных от pg1. Его нужно переключить на новый мастер:
root@pg3:~# sudo -u postgres /usr/bin/repmgr standby follow -f /etc/repmgr.conf --upstream-node-id=2
NOTICE: setting node 3's primary to node 2
NOTICE: restarting server using "sudo -n /bin/systemctl restart postgresql"
NOTICE: STANDBY FOLLOW successful
DETAIL: node 3 is now attached to node 2
Проверим состояние кластера:
root@pg2:~# sudo -u postgres repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+----------------+---------+-----------+----------------+----------+-------------------------------------------------------------------
1 | pg1.lab.office | primary | - failed | | default | host=pg1.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
2 | pg2.lab.office | primary | * running | | default | host=pg2.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
3 | pg3.lab.office | standby | running | pg2.lab.office | default | host=pg3.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
WARNING: following issues were detected
- when attempting to connect to node "pg1.lab.office" (ID: 1), following error encountered :
"could not connect to server: Connection refused
Is the server running on host "pg1.lab.office" (192.168.0.17) and accepting
TCP/IP connections on port 5432?"
Теперь мы можем убрать старый сервер из конфигурации:
root@pg2:~# sudo -u postgres repmgr -f /etc/repmgr.conf primary unregister --node-id=1
Проверяем еще раз:
root@pg2:~# sudo -u postgres repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Connection string
----+----------------+---------+-----------+----------------+----------+-------------------------------------------------------------------
2 | pg2.lab.office | primary | * running | | default | host=pg2.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
3 | pg3.lab.office | standby | running | pg2.lab.office | default | host=pg3.lab.office user=repmgr dbname=repmgrdb connect_timeout=2
Теперь можно спокойно чинить pg1, без риска что он внезапно вернется в сеть и будет конфликт записи в slave.
Возврат мастера
Самый простой способ вернуть старый сервер - удалить его datadir и зарегистрировать заново как slave:
root@pg1:~# rm -rf /var/lib/postgresql/10/main/*
root@pg1:~# sudo -u postgres repmgr -f /etc/repmgr.conf -h pg2.lab.office -U repmgr -d repmgrdb standby clone
NOTICE: destination directory "/var/lib/postgresql/10/main/" provided
NOTICE: starting backup (using pg_basebackup)...
HINT: this may take some time; consider using the -c/--fast-checkpoint option
NOTICE: standby clone (using pg_basebackup) complete
NOTICE: you can now start your PostgreSQL server
HINT: for example: sudo -n /bin/systemctl start postgresql
HINT: after starting the server, you need to register this standby with "repmgr standby register"
root@pg1:~# service postgresql start
root@pg1:~# sudo -u postgres /usr/bin/repmgr standby register
WARNING: --upstream-node-id not supplied, assuming upstream node is primary (node ID 2)
NOTICE: standby node "pg1.lab.office" (id: 1) successfully registered
Заключение
Repmgr - простой, понятный инструмент, который сильно облегчает операции в master-slave конфигурациях. Он не позволит полностью автоматизировать защиту от отказов (для этого нужны другие инструменты), но поможет в простых конфигурациях. Я очень рекомендую использовать его – самостоятельно или в сочетании с pgpool-II. В таком варианте pgpool отвечает за балансировку запросов, фенсинг и инициирует failover, когда это необходимо. Repmgr отвечает за сам низкоуровневый процесс failover (и это намного лучше, чем рекомендуемый pgpool набор жутковатых скриптов!).
При этом я очень не рекомендую:
- использовать автоматический failover средствами repmgr. Строго говоря – он не работает. Для работы repmgr нужен работающий сервер postgresql, и если postgresql master упал – repmgr не в состоянии самостоятельно переключится (из-за упавшего мастера)
- использовать bidirectional multimaster. Эта функция заявлена в описании, но работает крайне плохо - сервера теряют связь друг с другом и часто трут конфликтующие данные. Проверено до версии 4.0.5