kb/replication
Физическая (потоковая) репликация, слоты и измерение лага, влияние hot_standby_feedback на vacuum мастера, логическая репликация через публикации и подписки, распределённые ловушки.
Длинный запрос на standby читает старые версии строк. Если primary их уже почистил vacuum'ом, standby обязан либо отменить запрос (конфликт восстановления), либо отстать. hot_standby_feedback = on говорит primary не удалять то, что ещё нужно standby - ценой роста мусора на primary.
Логическая репликация шлёт не байты WAL, а декодированные изменения строк: INSERT/UPDATE/DELETE по конкретным таблицам. Источник объявляет PUBLICATION, приёмник создаёт SUBSCRIPTION. Требует wal_level = logical. Можно реплицировать часть таблиц между разными версиями и схемами.
Как только данные живут на нескольких серверах, появляются проблемы, которых не было на одном. 2PC даёт атомарность поверх узлов, но повисший prepared-транзакшн держит блокировки и горизонт. Самодельный multi-master ловит конфликты записи, которые некому разрешить. CAP/PACELC объясняют, чем именно приходится жертвовать.
Standby проигрывает у себя тот же WAL, что пишет primary, и получается побайтовая копия кластера. Primary отдаёт журнал процессом walsender, standby принимает walreceiver'ом и применяет startup-процессом. Лаг меряется в LSN: насколько replay на standby отстал от записи на primary.