Физическая (потоковая) репликация

Начнём с модели, а не с конфигов. Вспомни crash recovery: сервер берёт последнюю контрольную точку (см. checkpoint) и проигрывает WAL вперёд до конца журнала, восстанавливая страницы. Что будет, если конец журнала не наступает - записи всё прибывают?

Сервер так и останется в режиме восстановления, вечно догоняя поток. Это и есть standby. Он не «копирует таблицы» - он применяет тот же журнал, который primary пишет у себя. Любое изменение, дошедшее до WAL на primary, рано или поздно проиграется на standby и ляжет в те же самые байты.

Отсюда сразу следуют свойства физической репликации:

• копия побайтовая: версия, схема, физическая раскладка - всё идентично, выбрать «только одну таблицу» нельзя;
• standby read-only: он в режиме recovery, писать туда нельзя в принципе, отвергается любой INSERT;
• один primary, его поток могут принимать много standby.

Поток журнала обслуживают три процесса. Запусти ps на обоих серверах - и ты их увидишь поимённо.

primary                          standby

┌──────────────┐                 ┌──────────────┐

│ backends     │  пишут WAL      │ walreceiver  │ принимает по TCP

│   ↓          │                 │   ↓          │

│ WAL на диск  │ ──walsender──▶  │ WAL на диск  │

│              │                 │   ↓          │

└──────────────┘                 │ startup      │ проигрывает (replay)

                                 └──────────────┘

• walsender на primary читает WAL и отдаёт его в сетевое соединение. По одному walsender на каждый подключённый standby.
• walreceiver на standby принимает поток и сбрасывает на диск.
• startup на standby проигрывает принятые записи в строгом порядке.

Разделение walreceiver и startup важно: принять журнал и применить его - разные задачи с разной скоростью. Именно отсюда возьмётся лаг.

Параметр hot_standby = on (по умолчанию включён) разрешает подключаться к standby и читать, пока тот применяет журнал. Без него standby - чёрный ящик до самого failover.

Чтение с реплики - частый способ разгрузить primary от отчётов. Но запросы на standby конкурируют со startup-процессом за те же страницы, и тут рождается конфликт восстановления: startup хочет проиграть очистку строк, которые читает твой запрос (про горизонт уборки см. transaction-horizon). Об этом - hot-standby-feedback и врезка 38.5 ниже.

LSN (Log Sequence Number) - это позиция в журнале. Монотонно растущее число, которое можно прочитать как «сколько байт WAL сервер уже произвёл». Любую точку репликации выражают в LSN.

SELECT pg_current_wal_lsn();      -- докуда primary записал

SELECT pg_last_wal_replay_lsn();  -- докуда standby проиграл

Поскольку LSN растёт линейно, разница двух LSN - это объём журнала между ними в байтах. Функция pg_wal_lsn_diff(a, b) считает эту разницу. На ней строится всё измерение лага: лаг репликации - это pg_current_wal_lsn() на primary минус то, докуда добрался standby.

Прежде чем читать дальше, предскажи: если на standby полностью остановить применение журнала, а на primary продолжать писать - что будет с разницей этих двух LSN? Проверишь в лабе.

На primary есть представление pg_stat_replication - по строке на каждый подключённый standby. В нём три LSN, и они не совпадают не случайно:

• sent_lsn - досюда primary отправил журнал;
• flush_lsn - досюда standby сбросил на диск;
• replay_lsn - досюда standby проиграл (это видно на чтении).

Порядок всегда такой: sent >= flush >= replay. Разрыв между flush и replay - это «журнал уже принят и надёжно лежит, но ещё не применён». Под нагрузкой первым отстаёт именно replay: записать сегмент на диск дёшево, а проиграть его - значит конкурировать с читающими запросами на standby.

SELECT application_name, state,

       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replay_behind_bytes,

       write_lag, flush_lag, replay_lag

FROM pg_stat_replication;

Колонки *_lag показывают то же отставание, но во времени, а не в байтах - удобно для алертов «реплика отстаёт больше N секунд».

Primary не хранит WAL вечно. Он удаляет старые сегменты по своим правилам (max_wal_size, контрольные точки), как только они больше не нужны для его собственного восстановления. Про standby он по умолчанию ничего не знает.

Сценарий аварии: standby отключился на обслуживание на час. За этот час primary под нагрузкой переехал контрольную точку и удалил сегменты, которые standby ещё не получил. Standby возвращается, просит нужный сегмент - а его уже нет. Репликация рвётся: requested WAL segment ... has already been removed.

Чинит это слот репликации (pg_create_physical_replication_slot). Слот - это запись на primary «вот этот потребитель дочитал до restart_lsn»: primary держит WAL до этой границы и не удаляет раньше.

Но у слота есть обратная сторона, и она опаснее. Забытый неактивный слот удерживает WAL навсегда - primary не удаляет журнал, которого ждёт давно мёртвый потребитель, и диск primary забивается под ноль. Поэтому слоты надо мониторить:

SELECT slot_name, active, wal_status,

       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained

FROM pg_replication_slots;

active = false на слоте, который копит retained - это будущий инцидент «диск кончился на primary».

По умолчанию репликация асинхронная. COMMIT на primary возвращает управление, не дожидаясь, пока изменение уедет на standby. Это быстро: клиент не платит за сеть до реплики. Цена - окно потери: если primary умрёт прямо после COMMIT, последние транзакции могли не успеть отправиться, и при переключении на standby они пропадут.

Синхронная репликация закрывает это окно. С synchronous_standby_names и synchronous_commit = on COMMIT не вернётся, пока standby не подтвердит запись. Потерь при failover нет. Платит каждый COMMIT - задержкой в один сетевой круг до реплики.

Это не «как лучше», а честный выбор. Финансовая запись, которую нельзя потерять - синхронно, смиряемся с задержкой. Поток событий, где потеря секунды некритична - асинхронно, бережём latency. Тот же компромисс между задержкой и согласованностью разберём строго в главе про распределённые ловушки.

Когда primary умирает, standby повышают до нового primary (pg_promote()). С этого момента он выходит из recovery и начинает писать собственный WAL. Чтобы новый поток не спутали со старым, PostgreSQL увеличивает номер таймлайна - это «ветка истории» журнала.

Таймлайн отвечает на вопрос «чей это WAL»: до промоушена сегменты шли по таймлайну 1, после - по таймлайну 2. Старые standby, которые хотят последовать за новым primary, должны переключиться на новый таймлайн. Без этого механизма два сервера, разошедшихся после аварии, писали бы конфликтующий журнал с одинаковыми LSN.

Полная настройка standby - это, по сути, четыре шага, и каждый опирается на уже знакомый механизм:

1. на primary разрешить репликационные подключения (роль с REPLICATION, строка в pg_hba.conf);
2. снять базовую копию primary - pg_basebackup делает физический слепок работающего кластера;
3. положить рядом файл-признак standby.signal, чтобы сервер поднялся в режиме standby, а не как обычный primary;
4. указать в primary_conninfo, к кому подключаться, и (желательно) имя слота.

Дальше standby сам подключится, walreceiver начнёт принимать поток, а startup - проигрывать. В лабе мы соберём то, что можно собрать на одном сервере: создадим слот, посмотрим, как он держит WAL, и измерим продвижение LSN. Полную пару primary плюс standby даёт отдельная топология сэндбокса.