Какие виды репликаций существуют

Что проверяют

Понимаете ли вы, чем платите за копии данных: задержкой записи, риском потерять транзакции или конфликтами. Для Go-разработчика следом почти всегда идёт практический вопрос: пользователь сохранил профиль, обновил страницу и не видит изменений. Почему?

Как отвечать

Разложите виды по трём осям, а не одним списком:

• по моменту подтверждения: синхронная отвечает клиенту после того, как запись приняла реплика, асинхронная сразу, а реплика догоняет позже, кворумная ждёт часть узлов. В PostgreSQL это synchronous_commit и synchronous_standby_names с FIRST n или ANY n, в Kafka аналог acks=all вместе с min.insync.replicas;
• по топологии: один лидер и реплики на чтение (самый частый вариант), несколько лидеров (multi-master, нужны правила разрешения конфликтов), схема без лидера с кворумом чтения и записи, как в Cassandra;
• по уровню: физическая передаёт журнал WAL, реплика это точная копия кластера той же мажорной версии; логическая (в PostgreSQL публикации и подписки с 10-й версии) передаёт изменения строк, умеет отдельные таблицы и работает между версиями.

Потоковая репликация в PostgreSQL не отдельный вид, а способ доставки физического WAL по соединению.

Дальше про Go. database/sql и pgx не маршрутизируют запросы сами, поэтому держат два пула: на мастер и на реплики. Чтение сразу после записи отправляют на мастер. Лаг смотрят в pg_stat_replication. Переключение при падении мастера делает внешний инструмент, например Patroni, и сервис должен переживать разрыв соединений и повторять запросы.

Где спотыкаются

Говорят, что синхронная репликация ждёт все узлы. Обычно ждут заданное число реплик, иначе одна упавшая останавливает всю запись.

Считают реплику бэкапом. Ошибочный DELETE реплицируется за миллисекунды, от него спасают резервные копии и восстановление на момент времени (PITR).

Отправляют все чтения на реплики и получают «пропадающие» данные у пользователя сразу после сохранения.