PostgreSQL Streaming Replication¶

PostgreSQL Streaming Replication — это механизм асинхронной или синхронной репликации данных в системе управления базами данных PostgreSQL, основанный на передаче журнала предзаписи (WAL, Write-Ahead Log) от основного сервера (primary) к одному или нескольким резервным серверам (standby) в режиме реального времени. Данная технология обеспечивает высокую доступность, отказоустойчивость и масштабирование чтения, позволяя резервным серверам поддерживать актуальную копию базы данных с минимальной задержкой.

¶История

До появления встроенной потоковой репликации в PostgreSQL использовались сторонние решения, такие как Slony-I, Londiste (часть SkyTools) и Bucardo, которые реализовывали репликацию на уровне триггеров или логических изменений. Эти подходы были сложны в настройке и не обеспечивали полной согласованности данных.

Потоковая репликация на основе WAL была впервые представлена в PostgreSQL 9.0 (выпущен в сентябре 2010 года). Эта версия ввела концепцию резервного сервера в режиме «горячего резерва» (Hot Standby), который мог принимать запросы на чтение, оставаясь синхронизированным с основным сервером. В последующих версиях механизм был значительно расширен:

• PostgreSQL 9.1 (2011): добавлена поддержка синхронной репликации, гарантирующая, что транзакция считается завершённой только после записи на резервный сервер.
• PostgreSQL 9.2 (2012): введены каскадные реплики (cascading replication), позволяющие резервным серверам реплицировать данные друг другу.
• PostgreSQL 9.3 (2013): добавлена поддержка быстрого переключения на резервный сервер (fast failover) и улучшена работа с несколькими резервными серверами.
• PostgreSQL 9.5 (2016): добавлена функция pg_rewind, позволяющая быстро переподключить бывший основной сервер после сбоя.
• PostgreSQL 10 (2017): введена логическая репликация (logical replication), которая, в отличие от потоковой, работает на уровне отдельных таблиц и поддерживает разнородные версии PostgreSQL.
• PostgreSQL 12 (2019): улучшена производительность репликации, добавлена возможность репликации с несколькими процессами WAL sender.

¶Архитектура и принцип работы

¶Основные компоненты

1. Основной сервер (Primary): сервер, который принимает все операции записи (INSERT, UPDATE, DELETE). Он генерирует записи WAL, которые затем передаются резервным серверам.
2. Резервный сервер (Standby): сервер, который получает и применяет записи WAL от основного сервера. Он может работать в режиме «горячего резерва» (Hot Standby), принимая запросы на чтение, или в режиме «холодного резерва» (Cold Standby), не принимая запросы до момента переключения.
3. WAL (Write-Ahead Log): журнал предзаписи, в который PostgreSQL записывает все изменения данных до их применения к основной базе данных. Каждая запись WAL имеет уникальный номер (LSN, Log Sequence Number), который используется для синхронизации.
4. Процесс WAL Sender: на основном сервере запускается отдельный процесс для каждого подключённого резервного сервера. Он читает записи WAL и отправляет их по сети.
5. Процесс WAL Receiver: на резервном сервере запускается процесс, который принимает записи WAL от основного сервера и записывает их в локальный журнал WAL.
6. Процесс Startup: на резервном сервере процесс применяет записи WAL к базе данных, воспроизводя изменения.

¶Процесс репликации

1. Основной сервер записывает изменения в WAL-буфер и затем сбрасывает их на диск в WAL-сегменты.
2. Процесс WAL Sender на основном сервере отправляет новые записи WAL резервному серверу по TCP-соединению.
3. Процесс WAL Receiver на резервном сервере принимает записи и записывает их в локальный WAL-журнал.
4. Процесс Startup на резервном сервере применяет записи WAL к своей копии базы данных, поддерживая её в актуальном состоянии.

¶Режимы репликации

• Асинхронная репликация (Asynchronous Replication): транзакция на основном сервере считается завершённой сразу после записи в локальный WAL, без ожидания подтверждения от резервного сервера. Это обеспечивает минимальную задержку на основном сервере, но существует риск потери данных в случае сбоя основного сервера до передачи записей.
• Синхронная репликация (Synchronous Replication): транзакция считается завершённой только после того, как запись WAL будет записана как на основной, так и на указанный резервный сервер. Это гарантирует нулевую потерю данных, но увеличивает время отклика на основном сервере. В PostgreSQL можно настроить один или несколько синхронных резервных серверов.

¶Настройка и конфигурация

¶Основные параметры конфигурации

Настройка потоковой репликации требует изменения файла postgresql.conf на основном сервере и файла recovery.conf (или standby.signal в PostgreSQL 12+) на резервном сервере.

Основной сервер (primary):

• wal_level = replica (или logical для логической репликации) — определяет уровень детализации WAL.
• max_wal_senders = 5 (или больше) — максимальное количество процессов WAL Sender.
• wal_keep_size = 1024 (в PostgreSQL 13+) или wal_keep_segments (в более старых версиях) — количество WAL-сегментов, которые хранятся на основном сервере для отстающих резервных серверов.
• hot_standby = on — разрешает запросы на чтение на резервном сервере.

Резервный сервер (standby):

• hot_standby = on — включает режим горячего резерва.
• primary_conninfo = 'host=primary_host port=5432 user=replication_user password=password' — строка подключения к основному серверу.
• primary_slot_name = 'standby1' — имя слота репликации (опционально, но рекомендуется для предотвращения удаления WAL-сегментов).

¶Слоты репликации

Слоты репликации (Replication Slots) — это механизм, который гарантирует, что основной сервер не удалит WAL-сегменты, необходимые резервным серверам, даже если они временно отстают. Слоты создаются на основном сервере с помощью команды SELECT * FROM pg_create_physical_replication_slot('slot_name');. Использование слотов предотвращает потерю данных при сбое сети или отключении резервного сервера.

¶Каскадная репликация

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

¶Применение

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

Потоковая репликация является основой для построения кластеров высокой доступности (HA). В случае сбоя основного сервера администратор может выполнить переключение на резервный сервер (failover), сделав его новым основным. Для автоматизации этого процесса используются менеджеры кластеров, такие как Patroni, pg_auto_failover, repmgr и Pacemaker.

¶Масштабирование чтения

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

¶Резервное копирование и восстановление

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

¶Тестирование и разработка

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

¶Преимущества и недостатки

¶Преимущества

• Встроенная поддержка: не требует установки дополнительного программного обеспечения.
• Простота настройки: базовая конфигурация выполняется несколькими параметрами.
• Минимальная задержка: асинхронная репликация обеспечивает практически реальное время.
• Горячий резерв: резервные серверы могут обслуживать запросы на чтение.
• Каскадная репликация: позволяет строить сложные топологии.

¶Недостатки

• Ограниченная гибкость: реплицируется вся база данных целиком, нельзя выборочно реплицировать отдельные таблицы (для этого используется логическая репликация).
• Зависимость от версии: основной и резервный серверы должны быть одной версии PostgreSQL (для физической репликации).
• Нагрузка на основной сервер: каждый резервный сервер требует отдельного процесса WAL Sender и потребляет сетевые ресурсы.
• Сложность управления: при большом количестве резервных серверов требуется тщательное планирование и мониторинг.

¶Сравнение с другими методами репликации

¶Мониторинг и управление

Для мониторинга состояния репликации используются системные представления:

• pg_stat_replication — показывает состояние процессов WAL Sender на основном сервере (задержку, отправленные байты, состояние).
• pg_stat_wal_receiver — показывает состояние процесса WAL Receiver на резервном сервере.
• pg_replication_slots — отображает информацию о слотах репликации.

Задержка репликации измеряется как разница в LSN (Log Sequence Number) между основным и резервным серверами. В PostgreSQL 10+ добавлена функция pg_wal_lsn_diff() для вычисления этой разницы.

¶Безопасность

Для подключения резервного сервера к основному требуется специальная учётная запись с привилегией REPLICATION. Рекомендуется использовать SSL-соединение для шифрования трафика репликации. В файле pg_hba.conf на основном сервере необходимо добавить строку:

`` host replication replication_user standby_ip/32 md5 ``

¶Источники

• PostgreSQL Documentation: Chapter 26. High Availability, Load Balancing, and Replication
• PostgreSQL Documentation: Chapter 27. Monitoring Database Activity (pg_stat_replication, pg_stat_wal_receiver)
• PostgreSQL Documentation: Chapter 28. Reliability and the Write-Ahead Log
• PostgreSQL Documentation: Replication Slots
• PostgreSQL Documentation: Hot Standby
• PostgreSQL Documentation: Synchronous Replication
• PostgreSQL Documentation: Cascading Replication
• PostgreSQL Documentation: pg_rewind
• PostgreSQL Documentation: Logical Replication
• PostgreSQL Documentation: Patroni — A Template for High Availability PostgreSQL
• PostgreSQL Documentation: repmgr — Replication Manager for PostgreSQL