Физическая репликация

Физическая репликация основана на непрерывной передаче записей журнала предзаписи (WAL) с мастер-сервера на реплику. Сервер-реплика создается как физическая копия мастера, например, с помощью утилиты pg_basebackup. Для перехода в режим постоянного восстановления в каталоге данных (PGDATA) реплики размещается пустой файл standby.signal, а строка подключения к мастеру настраивается параметром primary_conninfo.

Принцип работы репликации:

На мастере процесс walsender передает по протоколу репликации записи WAL в потоковом режиме.
На реплике процесс walreceiver получает записи WAL, а процесс startup применяет их в режиме непрерывного восстановления — аналогично восстановлению после сбоя, но без завершения работы.
Мастер должен разрешать подключения по протоколу репликации, что настраивается в файле pg_hba.conf.
Параметр wal_level на мастере должен быть установлен в значение replica (по умолчанию).

Операции на реплики

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

Разрешенные операции:

читающие запросы (SELECT, COPY TO);
читающие транзакции (BEGIN, COMMIT, ROLLBACK);
установка и сброс сессионных параметров (SET, RESET);
резервное копирование (логическое и физическое).

Запрещенные операции:

пишущие запросы (INSERT, UPDATE, DELETE и подобные);
команды DDL (CREATE, DROP, ALTER и подобные);
операции обслуживания (VACUUM, ANALYZE, REINDEX и подобные);
команды управления доступом (GRANT, REVOKE).

Процессы на мастере и реплике

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

Процессы на мастере:

walwriter — помещает записи WAL из кеша в файлы сегментов журнала предзаписи. На реплике этот процесс не работает, так как реплика получает записи WAL из потока;
autovacuum — выполняет автоочистку. На реплике автоочистка не выполняется;
walsender — передает поток репликации на реплику. В обычной топологии работает только на мастере, однако при каскадной репликации может запускаться и на реплике, передавая WAL дальше.

Процессы на реплике:

walreceiver — принимает записи WAL из потока репликации с мастера;
startup — применяет полученные записи WAL в режиме непрерывного восстановления.

Настройка мастера

Перед созданием сервера-реплики необходимо убедиться, что мастер-сервер корректно настроен для передачи WAL. Проверка включает два этапа: валидация параметров WAL и проверка правил аутентификации для подключений репликации.

Проверим параметры max_wal_senders и wal_level, используя команду \dconfig с маской в оболочке psql.

[postgres@ServerName ~]$ psql -c '\dconfig (max_wal_se|wal_lev)*'

Разбор команды

\dconfig — служебная команда psql для просмотра параметров конфигурации сервера;
маска (max_wal_se|wal_lev)* — регулярное выражение, фильтрующее параметры, имена которых начинаются на max_wal_se или wal_lev.

List of configuration parameters
Parameter        | Value
-----------------+---------
max_wal_senders  | 10
wal_level        | replica
(2 rows)

Параметр max_wal_senders равен 10, что допускает до 10 одновременных подключений репликации. Параметр wal_level установлен в значение replica — необходимое условие для физической репликации.

Проверим правила аутентификации для подключений репликации в файле pg_hba.conf, обратившись к функции pg_hba_file_rules().

[postgres@ServerName ~]$ psql -c "SELECT type,user_name,address,auth_method FROM pg_hba_file_rules() WHERE 'replication'=ANY(database)"

Разбор команды

функция pg_hba_file_rules() возвращает правила аутентификации из файла pg_hba.conf в виде строк таблицы;
выражение 'replication' = ANY(database) отбирает правила, где в столбце баз данных указано replication;
поле database содержит массив значений, поэтому применяется оператор ANY, гарантирующий, что в результат попадет конфигурация исключительно для репликационных соединений.

type   | user_name | address   | auth_method
-------+-----------+-----------+---------------
local  | {all}     |           | peer
 host  | {all}     | 127.0.0.1 | scram-sha-256
 host  | {all}     | ::1       | scram-sha-256
(3 rows)

Существуют три правила, разрешающих подключения репликации. При подключении через локальный Unix-сокет (local) применяется метод peer — аутентификация средствами ОС: роль в базе данных должна называться так же, как пользователь операционной системы, и пароль не требуется. При подключении по сети через localhost (127.0.0.1 или ::1) используется метод scram-sha-256 — аутентификация по паролю средствами СУБД.

Подготовка реплики

Для создания сервера-реплики необходимо выполнить физическое копирование данных с мастера. Реплика создается как точная копия мастер-сервера с использованием утилиты pg_basebackup. Все операции выполняются от пользователя postgres — владельца каталога данных.

Определим текущий каталог.

[postgres@ServerName ~]$ pwd

/var/lib/postgres

Домашний каталог пользователя postgres расположен по пути /var/lib/postgres. В нем создаем каталог для данных реплики.

[postgres@ServerName ~]$ mkdir rpl_pgdata

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

[postgres@ServerName ~]$ pg_basebackup -D rpl_pgdata/ -c fast -R -T /pgdata/06/newdisk=/home/postgres/newdisk-2

Разбор команды

pg_basebackup — утилита для создания полной физической копии сервера;
опция -D rpl_pgdata/ — путь к каталогу, в который будет скопирована база данных;
опция -c fast — фиксация начала резервной копии через быстрое подключение;
опция -R — создание файла standby.signal и запись параметра primary_conninfo в postgresql.auto.conf для автоматической настройки репликации.

Проверим содержимое созданного каталога.

[postgres@ServerName ~]$ ls rpl_pgdata/

backup_label           pg_hba.conf.orig  pg_quota.conf  PG_VERSION
backup_manifest        pg_ident.conf     pg_replslot    pg_wal
base                   pg_integrity      pg_serial      pg_xact
current_logfiles       pg_logical        pg_snapshots   postgresql.auto.conf
global                 pg_multixact      pg_stat        postgresql.conf
pg_commit_ts           pg_notify         pg_stat_tmp    postgresql.conf.bak
pg_dynshmem            pg_perf_insights  pg_subtrans    PRODUCT_VERSION
pg_hba.conf            pg_pp_cache       pg_tblspc      standby.signal
pg_hba.conf.bak        pg_prep_stats     pg_twophase    tracing

Каталог rpl_pgdata содержит полную копию данных мастера. Присутствие файла standby.signal подтверждает, что опция -R сработала корректно: при запуске сервер перейдет в режим реплики. В файле postgresql.auto.conf записана строка подключения к мастеру (primary_conninfo).

примечание

Если на мастере был создан слот репликации, к команде pg_basebackup необходимо добавить опцию -S <имя_слота>. Тогда в postgresql.auto.conf будет записан также параметр primary_slot_name. Использование слота репликации гарантирует, что мастер не удаляет сегменты WAL, необходимые реплике.

Настройка реплики

Каталог данных реплики, созданный утилитой pg_basebackup, содержит копию файлов конфигурации мастера. Если реплика запускается на том же хосте, что и мастер, необходимо изменить параметры, конфликтующие с мастер-сервером: номер TCP-порта и пути к журналам.

Для запуска экземпляра сервера права на каталог PGDATA должны быть 700 (drwx------) или 750 (drwxr-x---). Установим корректные права рекурсивно и перейдем в каталог реплики.

[postgres@ServerName ~]$ chmod -R go= rpl_pgdata/; cd rpl_pgdata/

Разбор командыы

chmod -R go= — рекурсивное удаление всех прав для группы (g) и остальных пользователей (o), оставляя права только владельцу;
cd rpl_pgdata/ — переход в каталог данных реплики для выполнения последующих операций.

Реплика по умолчанию прослушивает порт TCP 5432 — тот же, что и мастер. Для одновременной работы двух экземпляров на одном хосте назначим реплике порт 6432. Добавим настройку в файл postgresql.auto.conf.

[postgres@ServerName rpl_pgdata]$ echo 'port = 6432' >> postgresql.auto.conf

Каталог данных реплики является копией мастера, поэтому содержит те же настройки сборщика журналов отчета. На реплике сборщик не требуется — удалим соответствующие строки из postgresql.auto.conf. Строки настроек сборщика идентифицируются по префиксу #log.

[postgres@ServerName rpl_pgdata]$ sed -i '/#log/d' postgresql.auto.conf

Разбор команды

sed — потоковый редактор текста;
опция -i — изменение файла на месте (без создания резервной копии);
регулярное выражение /#log/d — удаление всех строк, содержащих подстроку #log (настройки сборщика журналов отчета).

Проверим итоговое содержимое файла postgresql.auto.conf.

[postgres@ServerName rpl_pgdata]$ cat postgresql.auto.conf

# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
primary_conninfo = 'user=postgres passfile=''/var/lib/postgres/.pgpass'' channel_binding=prefer port=5432 client_encoding=UTF8 sslmode=prefer sslcompression=0 sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'
port = 6432

В файле postgresql.auto.conf записаны два параметра: primary_conninfo (строка подключения к мастеру, созданная автоматически опцией -R утилиты pg_basebackup) и port = 6432 (порт реплики, добавленный вручную). Настройки сборщика журналов отчета успешно удалены.

Запуск реплики

Мастер-сервер запущен через systemctl, репликацию запускаем вручную утилитой pg_ctl. Опция -D указывает каталог данных PGDATA, опция -l — файл журнала отчета.

[postgres@ServerName ~]$ pg_ctl start -D ~/rpl_pgdata/ -l ~/rpl.log

waiting for server to start.... done
server started

Сервер реплики успешно запущен. Проверим журнал отчета для подтверждения корректности запуска.

[postgres@ServerName ~]$ tail -14 ~/rpl.log

2024-11-03 10:15:21.190 MSK [19263] LOG: listening on IPv4 address "0.0.0.0", port 6432
2024-11-03 10:15:21.190 MSK [19263] LOG: listening on IPv6 address "::", port 6432
2024-11-03 10:15:21.196 MSK [19263] LOG: listening on Unix socket "/tmp/.s.PGSQL.6432"
2024-11-03 10:15:21.207 MSK [19267] LOG: database system was shut down in recovery at 2024-11-03 10:13:2 2024-11-03 10:15:21.208 MSK [19268] LOG: idle terminator started
2024-11-03 10:15:21.208 MSK [19267] LOG: entering standby mode
2024-11-03 10:15:21.233 MSK [19267] LOG: redo starts at 0/C000070
2024-11-03 10:15:21.233 MSK [19267] LOG: consistent recovery state reached at 0/C000150
2024-11-03 10:15:21.233 MSK [19267] LOG: invalid record length at 0/C000198: wanted 26, got 0 2024-11-03 10:15:21.233 MSK [19263] LOG: database system is ready to accept read-only connections 2024-11-03 10:15:21.238 MSK [19263] LOG: Start integrity check launcher
2024-11-03 10:15:21.239 MSK [19270] LOG: Start of integrity check
2024-11-03 10:15:21.239 MSK [19271] LOG: License checker started
2024-11-03 10:15:21.248 MSK [19269] LOG: started streaming WAL from primary at 0/C000000 on timeline 1

В журнале отчета зафиксированы ключевые события запуска

реплика прослушивает порт TCP 6432 (listening on IPv4 address "0.0.0.0", port 6432);
сервер перешел в режим ожидания (entering standby mode);
начато применение WAL-записей (redo starts at 0/C000070);
достигнуто согласованное состояние восстановления (consistent recovery state reached at 0/C000150);
сервер готов принимать только читающие подключения (database system is ready to accept read-only connections);
начата потоковая передача WAL с мастера (started streaming WAL from primary at 0/C000000 on timeline 1).

Убедиться, что мастер и реплика работают корректно, позволяет вывод дерева процессов.

[postgres@ServerName ~]$ ps f -C postgres

  PID TTY  STAT  TIME  COMMAND
?    Ss    0:00  /usr/pangolin-{pangolin_version}/bin/postgres -D /var/lib/postgres/rpl_pgdata
?    Ss    0:00  \_ postgres: checkpointer
?    Ss    0:00  \_ postgres: background writer
?    Ss    0:00  \_ postgres: startup recovering 00000001000000000000000C
?    Ss    0:00  \_ postgres: idle sessions terminator
?    Ss    0:00  \_ postgres: walreceiver
?    Ss    0:00  \_ postgres: integrity check launcher
?    Ss    0:00  \_ postgres: license checker
?    Ss    0:19  /usr/pangolin-{pangolin_version}/bin/postgres -D /pgdata/06/data
?    Ss    0:00  \_ postgres: logger
?    Ss    0:00  \_ postgres: checkpointer
?    Ss    0:00  \_ postgres: background writer
?    Ss    0:00  \_ postgres: idle sessions terminator
?    Ss    0:00  \_ postgres: walwriter
?    Ss    0:00  \_ postgres: license checker
?    Ss    0:00  \_ postgres: autovacuum launcher
?    Ss    0:00  \_ postgres: autounite launcher
?    Ss    0:00  \_ postgres: integrity check launcher
?    Ss    0:00  \_ postgres: logical replication launcher
?    Ss    0:00  \_ postgres: walsender postgres [local] streaming 0/C000198

В выводе дерева процессов подтверждается корректная работа обоих экземпляров. На реплике (-D /var/lib/postgres/rpl_pgdata) запущены процессы startup (непрерывное восстановление) и walreceiver (прием WAL из потока). На мастере (-D /pgdata/06/data) работают процессы walwriter, autovacuum launcher и walsender (передача WAL реплике).

Мониторинг репликации

Вывод дерева процессов подтверждает факт запуска обоих экземпляров, однако для системного контроля работы репликации этого недостаточно. Для своевременного обнаружения рассинхронизации, накопления задержек WAL и сбоев потока репликации необходим мониторинг. Он осуществляется с помощью встроенных функций и системных представлений: функция pg_is_in_recovery() определяет роль сервера, представление pg_stat_activity отражает набор запущенных процессов (walsender на мастере, walreceiver и startup на реплике, а также walwriter, autovacuum launcher и остальных), а представление pg_stat_replication предоставляет детальную информацию о состоянии потока — текущий LSN, задержки, режим синхронизации.

Состояние мастера

Для мониторинга состояния репликации проверим роль сервера (мастер или реплика) и набор запущенных процессов. Подключимся к мастер-серверу в режиме без вывода приветственного сообщения (-q).

[postgres@ServerName ~]$ psql -q

Функция pg_is_in_recovery() возвращает true, если сервер находится в режиме восстановления (реплика), и false, если сервер работает в обычном режиме (мастер).

postgres@postgres=# SELECT pg_is_in_recovery();

 pg_is_in_recovery
-------------------
 f
(1 row)

Функция вернула false — сервер работает в роли мастера и может выполнять пишущие запросы.

Просмотрим набор процессов сервера через системное представление pg_stat_activity.

postgres@postgres=# SELECT pid, backend_type FROM pg_stat_activity;

 pid   | backend_type
-------+------------------------------
 | autovacuum launcher
 | autounite launcher
 | integrity check launcher
 | logical replication launcher
| walsender
| client backend
 | background writer
 | checkpointer
 | walwriter
(9 rows)

На мастер-сервере запущены процессы, недоступные на реплике:

autovacuum launcher — запуск автоочистки;
walsender — передача потока репликации на реплику;
walwriter — запись WAL из кеша в файлы сегментов.

Процесс walsender может запускаться и на реплике, но только в топологии каскадной репликации, когда реплика передает WAL другой реплике.

Состояние реплики

Подключимся к реплике, указав номер порта 6432.

[postgres@ServerName ~]$ psql -q -p 6432

Проверим роль сервера — реплика должна находиться в режиме восстановления.

postgres@postgres=# SELECT pg_is_in_recovery();

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

Функция вернула true — сервер работает в режиме постоянного восстановления и является репликой.

Просмотрим набор процессов реплики.

postgres@postgres=# SELECT pid, backend_type FROM pg_stat_activity;

 pid   | backend_type
-------+--------------------------
 19270 | integrity check launcher
 19881 | client backend
 19267 | startup
 19266 | background writer
 19265 | checkpointer
 19269 | walreceiver
(6 rows)

На реплике присутствуют характерные процессы:

startup — непрерывное применение WAL-записей в режиме восстановления;
walreceiver — прием записей WAL из потока репликации с мастера.

Процессы walwriter и autovacuum launcher отсутствуют — на реплике они не запускаются.

Попробуем выполнить пишущий запрос.

postgres@postgres=# CREATE TABLE t();

ERROR: cannot execute CREATE TABLE in a read-only transaction

Операция завершена ошибкой: реплика не поддерживает пишущие запросы.

При включенном параметре hot_standby на реплике разрешены читающие запросы. Проверим значение параметра.

postgres@postgres=# \dconfig+ hot_standby

              List of configuration parameters
  Parameter  | Value | Type |  Context   | Access privileges
-------------+-------+------+------------+-------------------
 hot_standby | on    | bool | postmaster |
(1 row)

Параметр hot_standby включен (on), что позволяет выполнять читающие запросы на реплике.

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

Для подтверждения корректной работы репликации выполним пишущие операции на мастере и проверим, что данные отобразились на реплике.

Подключимся к мастеру на порту 5432. Метакоманда \c изменяет параметры текущего подключения: первые два дефиса оставляют неизменными базу данных и роль, последний параметр задает новый порт.

postgres@postgres=# \c - - - 5432

You are now connected to database "postgres" as user "postgres" via socket in "/tmp" at port "5432".

Создадим тестовую базу данных repbase.

postgres@postgres=# CREATE DATABASE repbase;

CREATE DATABASE

Подключимся к созданной базе данных.

postgres@postgres=# \c repbase

You are now connected to database "repbase" as user "postgres".

Создадим таблицу nt со столбцами с типами данных времени и текстового сообщения, затем вставим тестовую строку.

postgres@repbase=# CREATE TABLE nt (dt timestamp DEFAULT now(), msg text);

CREATE TABLE

postgres@repbase=# INSERT INTO nt(msg) VALUES ('Проверка связи...');

INSERT 0 1

Переключимся на реплику, указав порт 6432.

postgres@repbase=# \c - - - 6432

You are now connected to database "repbase" as user "postgres" via socket in "/tmp" at port "6432".

Сеанс подключен к базе repbase на порту 6432 — это реплика. Выполним выборку из таблицы nt, созданной на мастере.

postgres@repbase=# SELECT * FROM nt;

                         dt | msg
----------------------------+-------------------
 2024-11-26 06:49:41.851134 | Проверка связи...
(1 row)

Данные, записанные на мастере, отобразились на реплике. Реплика не выполняла интерпретацию или планирование запросов — процесс startup применил записи WAL, полученные по протоколу репликации, воспроизведя все действия мастера.

Состояние репликации на мастере

Переключимся на мастер и проверим статус активного потока репликации через системное представление pg_stat_replication. Опция \gx переключает формат вывода в режим «одна запись — одна колонка».

postgres@repbase=# \c - - - 5432

You are now connected to database "repbase" as user "postgres" via socket in "/tmp" at port "5432".

postgres@repbase=# SELECT * FROM pg_stat_replication \gx

-[ RECORD 1 ]----+------------------------------
pid              | 2971
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      |
client_hostname  |
client_port      | -1
backend_start    | 2024-11-26 06:51:42.717722+03
backend_xmin     |
state            | streaming
sent_lsn         | 0/D6B0FE8
write_lsn        | 0/D6B0FE8
flush_lsn        | 0/D6B0FE8
replay_lsn       | 0/D6B0FE8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async
reply_time       | 2024-11-26 06:51:42.717722+03

Ключевые поля представления pg_stat_replication:

state — текущее состояние потока репликации (значение streaming означает активную потоковую передачу WAL);
sync_state — режим синхронизации (значение async указывает на асинхронную репликацию);
sent_lsn / write_lsn / flush_lsn / replay_lsn — контрольные точки (LSN — Log Sequence Number) на этапах обработки WAL: отправка, запись, фиксация и применение;
write_lag / flush_lag / replay_lag — задержки между мастером и репликой (пустые значения означают отсутствие измеримой задержки);
application_name — имя приложения на стороне реплики (walreceiver);
backend_start — время начала сессии репликации.

Репликация работает в режиме потоковой передачи (state = streaming) и асинхронном режиме (sync_state = async). Задержки отсутствуют — реплика синхронизирована с мастером.

Изменение роли реплики

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

Процесс повышения роли включает следующие этапы:

применение всех полученных, но еще не примененных записей WAL;
разрыв потока репликации, остановка процесса walreceiver;
завершение работы процесса startup;
запуск процессов, необходимых для работы мастера;
перевод сервера в обычный режим и начало обслуживания читающих и пишущих транзакций.

Для повышения роли в PostgreSQL предусмотрено три способа:

вызов функции pg_promote();
выполнение команды pg_ctl promote;
создание триггерного файла, имя которого задается параметром конфигурации promote_trigger_file.

Важно

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

Повышение роли

Подключимся к реплике на порту 6432.

postgres@postgres=# \c repbase - - 6432

You are now connected to database "repbase" as user "postgres" via socket in "/tmp" at port "6432".

Подтвердим, что сервер находится в режиме восстановления (реплика).

postgres@repbase=# SELECT pg_is_in_recovery();

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

Функция вернула true — сервер работает в роли реплики.

Вызовем функцию pg_promote() для повышения роли реплики до мастера. Функция возвращает true, если повышение инициировано успешно, и false, если сервер уже является мастером.

postgres@repbase=# SELECT pg_promote();

 pg_promote
------------
 t
(1 row)

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

postgres@repbase=# INSERT INTO nt(msg) VALUES ('Теперь у нас два мастера.');

INSERT 0 1

Запрос выполнен успешно — сервер принял пишущую транзакцию. Проверим содержимое таблицы.

postgres@repbase=# SELECT * FROM nt;

                         dt | msg
----------------------------+---------------------------
 2024-11-26 06:49:41.851134 | Проверка связи...
 2024-11-26 06:54:50.550615 | Теперь у нас два мастера.
(2 rows)

В таблице присутствуют обе строки: исходная (созданная на старом мастере) и новая (созданная на бывшей реплике после повышения роли).

Просмотрим набор процессов на новом мастере.

postgres@repbase=# SELECT pid, backend_type FROM pg_stat_activity;

  pid  |         backend_type
-------+------------------------------
| autovacuum launcher
| integrity check launcher
| client backend
| logical replication launcher
| autounite launcher
| background writer
| checkpointer
| walwriter
(8 rows)

Сравнение с набором процессов реплики показывает изменения: запускаются новые процессы, включая autovacuum launcher для автоочистки, walwriter для записи WAL из кеша в сегменты журнала и logical replication launcher для управления логической репликацией. Одновременно останавливаются процессы, характерные для реплики, — startup, отвечающий за непрерывное восстановление, и walreceiver, принимающий записи WAL по протоколу репликации.

Файловая репликация

Файловая репликация основана на организации архива сегментов журнала предзаписи (WAL). Она может использоваться самостоятельно или в сочетании с потоковой репликацией.

Файловая репликация применяется в двух сценариях:

Самостоятельная — сегменты WAL попадают в архив после полного заполнения или при вызове функции pg_switch_wal(). Это создает значительную задержку применения записей на реплике, так как данные становятся доступны только после ротации сегмента;
Дополнение к потоковой — файловый архив повышает надежность потоковой репликации и позволяет выполнять восстановление на произвольный момент времени в прошлом (Point-In-Time Recovery — PITR).

Реплика автоматически извлекает из архива необходимые сегменты WAL с помощью команды, заданной параметром restore_command.

Поместить сегменты WAL в архив можно двумя способами:

включить режим архивирования на мастере параметром archive_mode = on и настроить команду архивирования archive_command, которая будет копировать заполненные сегменты в архив после ротации;
использовать отдельную программу, подключающуюся к мастеру по протоколу репликации для получения потока WAL и размещения сегментов в архиве.

Итоги

Реплика создается командой pg_basebackup -D <каталог> -R — опция -R создает standby.signal и primary_conninfo;
Файл standby.signal указывает серверу перейти в режим реплики при запуске;
На мастере работает walsender, на реплике — walreceiver (прием WAL) и startup (применение WAL);
На реплике отключены walwriter и autovacuum launcher — реплика работает в режиме непрерывного восстановления;
Функция pg_is_in_recovery() возвращает true на реплике и false на мастере;
Параметр hot_standby = on (по умолчанию) разрешает читающие запросы на реплике;
Представление pg_stat_replication на мастере показывает статус потока: LSN, задержки, режим синхронизации;
Повышение реплики до роли мастера выполняется функцией pg_promote() или сигнальным файлом promote.signal;
Файловая репликация использует архив WAL с параметрами archive_mode, archive_command и restore_command для PITR.

Физическая репликация

Операции на реплики

Процессы на мастере и реплике

Настройка мастера

Подготовка реплики

Настройка реплики

Запуск реплики

Мониторинг репликации

Состояние мастера

Состояние реплики

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

Состояние репликации на мастере

Изменение роли реплики

Повышение роли

Файловая репликация

Итоги

Самопроверка

Вопрос 1

Вопрос 2

Вопрос 3

Вопрос 4

Вопрос 5

Вопрос 6

Вопрос 7

Вопрос 8

Вопрос 9

Операции на реплики​

Процессы на мастере и реплике​

Настройка мастера​

Подготовка реплики​

Настройка реплики​

Запуск реплики​

Мониторинг репликации​

Состояние мастера​

Состояние реплики​

Проверка репликации​

Состояние репликации на мастере​

Изменение роли реплики​

Повышение роли​

Файловая репликация​

Итоги​

Самопроверка​

Вопрос 1

Вопрос 2

Вопрос 3

Вопрос 4

Вопрос 5

Вопрос 6

Вопрос 7

Вопрос 8

Вопрос 9

Операции на реплики

Процессы на мастере и реплике

Настройка мастера

Подготовка реплики

Настройка реплики

Запуск реплики

Мониторинг репликации

Состояние мастера

Состояние реплики

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

Состояние репликации на мастере

Изменение роли реплики

Повышение роли

Файловая репликация

Итоги

Самопроверка