Пример настройки синхронной реплики

Внимание!
В данном разделе приводится конечный пример настройки кластера баз данных с синхронной репликацией. Обратите внимание, что здесь приводятся некоторые параметры (например ip адреса хостов или каталоги баз данных), которые могут не соответствовать вашим.

Начальные условия

Операционная система на серверах — CentOS 7.

172.31.101.70 — IP сервера, назначенного основным (мастер).

172.31.101.71 — IP резервного сервера (реплика).

СУБД установлена из RPM пакетов (см. Страница загрузки. QHB для Centos 7 и 8).

Каталог размещения БД — PG_DATA = /u01/qhb/db.

/usr/local/qhb/ — путь установки QHB по умолчанию.

Сервисы systemd сконфигурированы с учетом вышеперечисленного.

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

  1. Создаем пользователя QHB для репликации:
create user repluser replication password 'repluser';
  1. Устанавливаем необходимые параметры в файле конфигурации vi /u01/qhb/db/qhb.conf:
listen_addresses = '*'
wal_level = hot_standby
max_wal_senders = 2
max_replication_slots = 2
hot_standby = on
hot_standby_feedback = on
logging_collector = on
log_directory = './log'
synchronous_commit = on
synchronous_standby_names = '*'
  1. Устанавливаем параметры доступа к базе данных с машины резервного сервера в файле конфигурации
vi /u01/qhb/db/qhb_hba.conf


host replication repluser 172.31.101.70/32 md5
host replication repluser 172.31.101.71/32 md5

Внимание!
Существующую запись host replication не изменяем.

  1. Производим рестарт сервиса СУБД
systemctl restart qhb && systemctl status qhb

Настройка резервного сервера

  1. Останавливаем сервис СУБД на сервере реплики
systemctl stop qhb && systemctl status qhb
  1. Удаляем директорию с данными базы данных
rm -rf /u01/qhb/db/* # Полное удаление данных

Внимание!
Удаляя директорию, вы должны полностью осознавать необратимость данного действия и тот факт, что все данные, файлы конфигурации и логи будут утеряны без возможности восстановления.

  1. В случае если ситуация позволяет, выполняем восстановление через бэкап.

Если объем данных в базе данных большой, то рекомендуется воспользоваться копией данных, при ее наличии.

Восстановление через утилиту бэкапирования запускается от системного пользователя QHB:

sudo -u qhb \#
/usr/local/qhb/bin/qhb_basebackup \#Утилита бэкапа
-h 172.31.101.70 \ # IP адрес мастер сервера
-p 5432 \ # Порт по умолчанию; рекомендуется сменить, если конфигурация была изменена
-U repluser \ # Пользователь, созданный ранее на основном сервере, с правами репликации
-D /u01/qhb/db/ \ # Директория размещения СУБД
-Fp -Xs -P -R # Набор ключей, необходимых для репликации

Для лучшего понимания следует ознакомиться с функционированием ключей -Fp, -Xs, -P и -R данной утилиты, описанных в разделе Параметры qhb_basebackup.

Если копия делается при помощи qhb_basebackup, параметры подключения для реплики будут указаны в файле qhb.auto.conf.
Следует удостовериться в корректности заданной строки подключения.

Если копия базы данных была развернута через файл (или иной корректный способ, не указанный в данной инструкции), то до старта необходимо скорректировать несколько параметров:

  • запуск сервера СУБД в резервном режиме. Для этого требуется создать файл standby.signal в директории кластера базы данных (рядом с qhb.conf).
sudo -u qhb touch /u01/qhb/db/standby.signal
ls -la standby.signal
#-rw------- 1 qhb qhb     0 Nov 25 15:34 standby.signal
  • в файле конфигурации qhb.conf необходимо указать строку подключения к основному серверу:
primary_conninfo = 'user=repluser password=repluser host=172.31.101.70 port=5432 sslmode=disable sslcompression=0 gssencmode=disable krbsrvname=postgres target_session_attrs=any'

Примечание
Строка подключения длинная, и некоторые консольные редакторы могут применить опцию word-wrap, нарушая визуальную целостность строки.

  1. В обоих случаях параметры СУБД в файле конфигурации будут скопированы с мастера, и следует изменить некоторые значения на соответствующие реплике.

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

vi /u01/qhb/db/qhb.conf

listen_addresses = '*'
logging_collector = on
log_directory = 'log' # Удостоверьтесь в существовании директории и наличии необходимых прав.
  1. Теперь и только теперь можно запустить СУБД на втором сервере, реплике.
systemctl start qhb && systemctl status qhb

Проверка

  1. Проверяем на мастере:
/usr/local/qhb/bin/psql -x -c "select * from pg_stat_replication"

Должен высветится один слот:

pid              | 15566
usesysid         | 16385
usename          | repluser
application_name | walreceiver
client_addr      | 172.31.101.71
client_hostname  |
client_port      | 40516
backend_start    | 2020-11-25 09:45:22.249802-03
backend_xmin     |
state            | streaming
sent_lsn         | 0/30001F8
write_lsn        | 0/30001F8
flush_lsn        | 0/30001F8
replay_lsn       | 0/30001F8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 1
sync_state       | sync
                   ^^^^^^^
reply_time       | 2020-11-25 09:47:22.710523-03

Причем sync_state должен быть sync (репликация синхронная).

  1. Создадим таблицу на мастере:
CREATE TABLE rtest (vname VARCHAR(40));
  1. Заполним случайными значениями на миллион строк:
insert into rtest select substr(md5(random()::text), 0, 40) from generate_series(1,1000000);
  1. На ведомом сервере проверяем чтение из таблицы:
qhb=# select count(*) from rtest;
  count  
---------
 1000000
(1 row)

Дополнительные настройки

В некоторых вариантах рекомендовано прописать явное указание слота репликации.

На реплике в файл qhb.auto.conf добавить параметр primary_slot_name = 'standby_slot2_qhb'.

На мастере выполнить команду SQL:

SELECT pg_create_physical_replication_slot('standby_slot2_qhb');

Запрос по активным слотам репликации должен показывать на мастере нашу реплику

SELECT * FROM pg_replication_slots WHERE active=true;

См. также

Внешнее руководство с инструкциями и пояснениями, qhb_basebackup

Copyright © KVANTOM LLC, 2019-2023