Репликация

Настройка репликации для Tantor PipelineDB идентична настройке репликации в обычном PostgreSQL. Если вы уже делали это раньше, представленная информация не будет новой для вас. Если нет, то рекомендуем прочитать данный раздел, потому что настройка репликации в PostgreSQL имеет много особенностей, так как функционал репликации дорабатывался и развивался в течение долгого времени. В «Истории репликации в PostgreSQL» Питера Айзентраута (The history of replication in PostgreSQL) представлена подробная информации об эволюции этой функциональности.

Старые методы репликации, такие как резервные серверы с доставкой журналов (Log-Shipping Standby Servers), рассматриваться не будут, поскольку они чрезмерно сложны и не очень надежны. Они оправданы только в случае если вы работаете со старой версией PostgreSQL, но поскольку Pipeline DB встроен в ядро PostgreSQL 15+, можно использовать все последние и улучшенные функции, которые предлагает PostgreSQL.

Потоковая репликация

Tantor PipelineDB поддерживает потоковую репликацию PostgreSQL (streaming replication), как асинхронную, так и синхронную, из коробки. Используя потоковую репликацию, можно создать узел горячего резервирования, который синхронизируется с основным сервером, отслеживая журнал предварительной записи, и может обслуживать запросы только на чтение. В случае отказа основного узла, узел горячего резервирования может стать новым основным сервером.

Допустим, у нас уже есть экземпляр Tantor PipelineDB, работающий на localhost:5432. Первое, что нужно сделать, это создать роль на основном сервере с привилегиями REPLICATION. Эта роль будет использоваться резервным сервером для подключения к основному и потоковой передачи WAL.

psql -h localhost -p 5432 -d postgres -c \
"CREATE ROLE replicator WITH LOGIN REPLICATION;"

CREATE ROLE

Также можете создать роль с опцией PASSWORD, если основной сервер находится в открытой сети. Совет: сервер никогда не должен размещаться в открытой сети.

Затем нужно добавить запись для резервного сервера в файл pg_hba.conf . Его можно найти в каталоге данных основного сервера. Файл pg_hba.conf обрабатывает все сведения аутентификации клиента для Tantor PipelineDB. Для нашего примера добавим следующую запись в него, но в реальном сценарии запись почти всегда будет отличаться.

host replication replicator 0.0.0.0/0 trust

Затем нужно установить несколько параметров конфигурации на основном сервере, либо обновив файл pipelinedb.conf, либо передав их как флаги -c при запуске pipelinedb. Установите wal_level в hot_standby, hot_standby на on, max_replication_slots на значение 1, а max_wal_senders на значение 2. Хотя одному резервному узлу достаточно одного соединения отправителя, при загрузке (не обязательно, но по крайней мере в методе, описанном ниже) требуется 2 соединения. Нужно будет перезапустить основной узел после обновления этих параметров.

И, наконец, создайте слот репликации replication slot для резервного узла. Слоты репликации — это средства резервного узла для связи с основным сервером, чтобы он всегда знал, какие сегменты WAL нужно хранить. Как только резервный узел потребляет сегмент WAL, он обновляет столбец restart_lsn в каталоге pg_replication_slots чтобы основной узел знал, что теперь он может удалить этот сегмент WAL.

psql -h localhost -p 5432 -d postgres -c \
"SELECT * FROM pg_create_physical_replication_slot('replicator_slot');"

    slot_name    | xlog_position
-----------------+---------------
 replicator_slot |
(1 row)

Это все операции, которые нужно выполнить на основном узле. Теперь перейдите к резервному узлу. Первое, что нужно сделать на резервном сервере, это сделать базовую резервную копию основного сервера. Можно рассматривать это как синхронизацию rsync каталога данных основного сервера, который резервный сервер будет использовать в качестве отправной точки. Для этого используйте утилиту pg_basebackup. Также можно использовать rsync — он обычно немного быстрее, но требуется дополнительно самостоятельно настроить аутентификацию. pg_basebackup использует обычное соединение с PostgreSQL для отправки всех файлов базы, поэтому не нужно дополнительно настраивать аутентификацию.

pg_basebackup -X stream -D /path/to/standby_datadir -h localhost -p 5432 -U replicator

Аргументу -X stream требуется второй слот при создании базовой резервной копии. По сути, это потоковая передача WAL для изменений, которые происходят во время создания базовой резервной копии, поэтому вручную настраивать параметр wal_keep_size не нужно.

Теперь все настроено. Давайте запустим горячее резервирование через порт 6544.

pg_ctl start -D /path/to/standby_datadir -o "-p 6544"

В файле журнала резерва должно появиться что-то похожее:

LOG: entering standby mode
LOG: redo starts at 0/5000028
LOG: consistent recovery state reached at 0/50000F0
LOG: database system is ready to accept read only connections
LOG: started streaming WAL from primary at 0/6000000 on timeline 1

Для проверки, подключитесь к резервному узлу и убедитесь, что он находится в режиме восстановления.

psql -h localhost -p 6544 -d postgres -c \
"SELECT pg_is_in_recovery();"

 pg_is_in_recovery
-------------------
 t
(1 row)

Высокая доступность

PostgreSQL не поставляется со встроенными опциями высокой доступности. Большинство развертываний предполагают ручное переключение узла горячего резервирования в случае отказа основного сервера. Переключение Failover можно запустить с помощью pg_ctl promote.