Как работает репликация в PostgreSQL? Чем отличается синхронная от асинхронной?

Механизм репликации в PostgreSQL

В PostgreSQL репликация реализуется через механизм Write-Ahead Logging (WAL), где изменения сначала записываются в журнал транзакций (WAL-сегменты), а затем применяются к данным. Репликация использует эти WAL-записи для передачи изменений на реплики.

Основной процесс выглядит так:

1. На мастере (primary) при фиксации транзакции генерируются WAL-записи
2. Отправитель WAL (wal sender) на мастере передает записи приемнику WAL (wal receiver) на реплике
3. На реплике (standby) записи применяются процессом startup или walreceiver

Пример настройки базовой репликации в postgresql.conf:

# На мастере
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10

# На реплике
hot_standby = on

И в pg_hba.conf:

host replication replica_user 192.168.1.0/24 md5

Синхронная vs Асинхронная репликация

Асинхронная репликация

Асинхронная репликация — режим по умолчанию, где мастер не ждет подтверждения от реплики перед фиксацией транзакции:

• Мастер отправляет WAL-записи и сразу подтверждает клиенту успешную запись
• Задержка минимальна, производительность максимальна
• Риск потери данных при сбое мастера (последние транзакции могут не успеть на реплику)

Настройка асинхронной репликации (режим по умолчанию):

-- Создание репликационного слота
SELECT pg_create_physical_replication_slot('standby_slot');

-- На реплике в recovery.conf (PostgreSQL 12 и ниже) или postgresql.auto.conf
primary_conninfo = 'host=master_host port=5432 user=replica_user password=secret'
primary_slot_name = 'standby_slot'

Синхронная репликация

Синхронная репликация обеспечивает гарантию записи: мастер ждет подтверждения от одной или нескольких реплик:

• Транзакция фиксируется только после подтверждения от синхронных реплик
• Гарантия отсутствия потери данных (до уровня выбранной конфигурации)
• Увеличение задержки записи, снижение производительности

Настройка синхронной репликации:

-- На мастере в postgresql.conf
synchronous_standby_names = 'FIRST 1 (standby1, standby2)'

-- Проверка статуса
SELECT application_name, sync_state, sync_priority 
FROM pg_stat_replication;

Ключевые различия

• Гарантии данных: синхронная обеспечивает durability (прочность), асинхронная — нет
• Производительность: асинхронная быстрее, синхронная добавляет задержку RTT
• Доступность: при сбое синхронной реплики мастер может заблокировать запись
• Конфигурация: синхронную нужно явно настраивать, асинхронная работает по умолчанию

Практические аспекты

Для управления синхронной репликацией можно динамически изменять настройки:

-- Временное переключение в асинхронный режим при проблемах
ALTER SYSTEM SET synchronous_standby_names TO '';
SELECT pg_reload_conf();

-- Мониторинг репликации
SELECT 
    client_addr,
    state,
    sync_state,
    write_lag,
    flush_lag,
    replay_lag
FROM pg_stat_replication;

Компромиссное решение — использование кворумной синхронной репликации, доступной с PostgreSQL 14:

synchronous_standby_names = 'ANY 2 (node1, node2, node3)'

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

Выбор стратегии

Выбор зависит от требований RPO (Recovery Point Objective) и RTO (Recovery Time Objective):

• Финансовые системы: синхронная репликация для нулевой потери данных
• Веб-приложения: асинхронная с несколькими репликами для балансировки чтения
• Гибридный подход: синхронная для критичных данных + асинхронная для остальных

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