Запуск потоковой репликации в PostgreSQL
Чтобы понять, как работает потоковая репликация, давайте рассмотрим последовательность запуска и установления соединения между основным и резервным серверами. Следующие шаги описывают этот процесс в общих чертах:
Задействованные процессы:
При потоковой репликации три процесса взаимодействуют для облегчения передачи данных: процесс walsender на основном сервере, процесс walreceiver и процесс startup на резервном сервере. Эти процессы взаимодействуют, используя одно TCP-соединение.
Последовательность запуска:
Последовательность запуска потоковой репликации разворачивается следующим образом:
- Запустите основной и резервный серверы;
- Резервный сервер инициирует процесс запуска;
- Резервный сервер запускает процесс walreceiver;
- Walreceiver отправляет запрос на подключение к основному серверу, периодически повторяя попытку, если основной сервер не работает;
- Получив запрос на подключение, основной сервер запускает процесс walsender, устанавливая TCP-соединение с walreceiver;
- Walreceiver отправляет последний порядковый номер журнала (LSN) резервного кластера базы данных, инициируя фазу установления связи;
- Если номер LSN резервного сервера находится за номером LSN основного сервера, walsender отправляет соответствующие данные WAL из каталога сегментов WAL основного сервера (pg_xlog или pg_wal) резервному серверу. Эта фаза наверстывания обеспечивает синхронизацию между основным и резервным;
- Начинается потоковая репликация, а процесс walsender сохраняет состояние, соответствующее рабочей фазе (запуск, наверстывание или потоковая передача).
В режиме walsender можно использовать только протокол простых запросов. Команды репликации будут записываться в журнал сообщений сервера, если включён режим log_replication_commands. Если этот параметр имеет значение database, процесс walsender должен подключиться к базе данных, указанной в параметре dbname, что позволит использовать это подключение для логической репликации с указанной базой данных.
Динамическое статистическое представление pg_stat_replication view отображает состояние всех работающих walsender. Пример:
testdb=# SELECT application_name,state FROM pg_stat_replication; application_name | state ------------------+----------- standby1 | streaming standby2 | streaming pg_basebackup | backup (3 rows)
Итак, два walsender работают для отправки WAL-данных для подключенных резервных серверов, а еще один - для отправки всех файлов кластера баз данных для утилиты pg_basebackup.
Примечание: Что произойдет, если резервный сервер перезапустится после длительного периода остановки?
Поведение зависит от версии PostgreSQL:
Версия 9.3 и более ранние версии:
В более старых версиях, если сегменты WAL основного сервера, необходимые для резервного сервера, уже были переработаны, резервный сервер не может догнать основной сервер. Чтобы устранить эту проблему, можно установить большое значение для параметра конфигурации wal_keep_segments, что уменьшит вероятность возникновения. Однако это решение является лишь временной мерой.
Версия 9.4 и новее:
Начиная с версии 9.4, для решения этой проблемы в PostgreSQL появились слоты репликации. Слоты репликации повышают гибкость отправки данных WAL, особенно для логической репликации. Они позволяют сохранять неотправленные файлы сегментов WAL в слоте репликации, приостанавливая процесс повторного использования. Для получения более подробной информации обратитесь к официальной документации.
