Question 1

Как работает потоковая репликация? Что передаётся между узлами?

Accepted Answer

Потоковая (физическая) репликация передаёт поток WAL. На мастере процесс
walsender отдаёт записи журнала по мере их появления, на реплике процесс
walreceiver их принимает и применяет, проигрывая те же изменения
страниц. Реплика это побайтовая копия кластера: те же файлы, те же LSN.
Standby может быть hot standby - принимать запросы только на чтение,
продолжая накатывать WAL. Применение идёт по тем же правилам redo, что и
восстановление после сбоя, поэтому реплика всегда «доигрывает» журнал до
позиции, которую успела получить. Расхождение между позицией мастера и
реплики и есть лаг.

Question 2

Синхронная и асинхронная репликация: чем расплачиваешься за каждую?

Accepted Answer

При асинхронной репликации коммит на мастере подтверждается сразу, не
дожидаясь реплики. Быстро, но при внезапной потере мастера последние
транзакции, не успевшие уехать на реплику, теряются. При синхронной
(`synchronous_commit = on` плюс `synchronous_standby_names`) коммит ждёт,
пока хотя бы одна реплика подтвердит запись WAL. Нулевая потеря данных,
но цена - задержка каждого коммита на сетевой round-trip, и если
синхронная реплика отвалилась, коммиты на мастере встают. Промежуточные
уровни `remote_write`/`remote_apply` тонко настраивают, чего именно
ждать: записи в журнал реплики или применения. Выбор - это явный
компромисс между потерей данных и задержкой.

Question 3

Что такое лаг репликации, как его измерять и откуда он берётся?

Accepted Answer

Лаг - отставание реплики от мастера. Его измеряют двояко: по объёму
(разница LSN между тем, что мастер записал, и тем, что реплика приняла и
применила) и по времени (`replay лаг` - на сколько секунд устарели данные
на реплике). Причины: узкая сеть не успевает прокачать WAL; реплика не
успевает применять журнал, потому что redo однопоточный и упирается в
диск или в конфликты с читающими запросами; всплеск записи на мастере.
Смотрят через `pg_stat_replication` на мастере (`sent`/`write`/`flush`/
`replay` LSN) и `pg_last_wal_replay_lsn` на реплике. Большой лаг означает,
что чтения с реплики отдают устаревшие данные, а failover потеряет хвост.

Question 4

Зачем нужен hot_standby_feedback и какой конфликт он решает?

Accepted Answer

На hot standby выполняются длинные читающие запросы, и им нужны старые
версии строк. А мастер тем временем вакуумит и может удалить версии,
которые реплика ещё показывает своему запросу. Когда применение redo
доходит до такого удаления, возникает конфликт: реплика либо отменяет
запрос (`ERROR: canceling statement due to conflict with recovery`),
либо тормозит применение. `hot_standby_feedback = on` решает это так:
реплика сообщает мастеру свой горизонт, и мастер не чистит версии,
нужные репликовым запросам. Цена платится на мастере: его горизонт
теперь держит ещё и реплика, поэтому долгий запрос на standby тормозит
очистку и копит мусор на мастере.

Question 5

Чем логическая репликация отличается от физической и когда она нужна?

Accepted Answer

Физическая репликация копирует кластер целиком на уровне страниц: всё или
ничего, одинаковая версия, только чтение на реплике. Логическая работает
на уровне строк через publication/subscription: WAL декодируется в
логические изменения (INSERT/UPDATE/DELETE конкретных таблиц) и
применяется на подписчике обычными командами. Это даёт то, чего физическая
не умеет: реплицировать выборочные таблицы, между разными мажорными
версиями (полезно при апгрейде с минимальным простоем), в базу, где
подписчик может иметь свои таблицы и принимать запись. Требует
`wal_level = logical`, у таблиц нужен способ идентифицировать строку
(REPLICA IDENTITY, обычно первичный ключ). DDL логически не реплицируется.

Question 6

Что такое слот репликации и чем опасен заброшенный слот?

Accepted Answer

Слот репликации - запись на мастере, которая помнит, до какой позиции
WAL дочитал конкретный потребитель (реплика или логическая подписка).
Пока слот существует, мастер обязан хранить WAL до этой позиции и (для
логических слотов) не вычищать версии строк, нужные для декодирования.
Это спасает реплику, которая на время отвалилась: вернувшись, она
догонит, потому что нужный WAL сохранён. Но обратная сторона опасна: если
потребитель исчез навсегда, а слот не удалили, мастер копит WAL до тех
пор, пока не кончится место на диске и сервер не встанет. Заброшенный
слот - классическая причина внезапно заполнившегося `pg_wal`.

Question 7

Что такое failover и split-brain? Почему автоматическое переключение опасно?

Accepted Answer

Failover - повышение реплики до мастера, когда прежний мастер отказал.
Технически это `promote`: standby перестаёт быть только для чтения и
начинает принимать запись. Опасность - split-brain: если старый мастер на
самом деле жив (а недоступен была лишь сеть), и мы повысили реплику, в
кластере оказывается два мастера, оба принимают запись, данные расходятся
безвозвратно. Поэтому надёжный автоматический failover требует
кворума-арбитра и механизма fencing (гарантированно отключить старый
мастер - STONITH), а не просто пинга. Инструменты вроде Patroni строят
это поверх распределённого консенсуса. Наивный авто-failover по таймауту
пинга - прямой путь к split-brain.

Question 8

Реплика - это бэкап? Какие подводные камни у распределённой работы с данными?

Accepted Answer

Реплика - не бэкап. Она верно копирует и ошибки тоже: `DROP TABLE` или
порченое приложением значение мгновенно уедет на все реплики. Бэкап
нужен отдельный (базовый бэкап плюс архив WAL для PITR), чтобы можно было
откатиться на момент до ошибки. Другие грабли распределённой работы:
чтение с асинхронной реплики возвращает устаревшие данные (read-your-
writes ломается, если записал в мастер и сразу читаешь с реплики);
синхронная репликация добавляет задержку коммита; failover теряет хвост
при асинхронном режиме; распределённые транзакции между узлами требуют
двухфазного коммита и не бесплатны. Главное правило: репликация про
доступность, бэкап про сохранность, это разные задачи.

Потоковая и логическая репликация, отказоустойчивость