Database Replication Deep Dive

Зачем

Базовый replication показывает три топологии (single-leader / multi-leader / leaderless) и три режима (sync / async / semi-sync) на пальцах. В реальной эксплуатации этого не хватает: на проде ломается не «концепция», а детали реализации конкретной СУБД. Semi-sync под нагрузкой тихо деградирует в async. Cascading replicas копят lag на каждом hop. Async replica отдаёт пользователю «своё же» сообщение, которого он не видит. Delayed replica спасает после DELETE без WHERE, но только если её настроили заранее.

Этот гайд — для DBA / SRE, который уже несколько раз делал failover и теперь решает:

• какой synchronous_commit ставить для платёжного кластера vs ленты постов,
• как поймать silent degrade semi-sync до того, как leader упадёт,
• как читать с replicas без stale read'ов,
• зачем держать один delayed replica помимо PITR-бэкапов.

Mental model

Репликация — это не «sync vs async», а матрица из четырёх вопросов:

1. Чего ждёт COMMIT перед ACK клиенту?
2. Что считается «ack» от replica (получил WAL / записал в OS buffer / fsync / apply)?
3. Что происходит при таймауте ack — failure или silent fallback в async?
4. Как читатель узнаёт, что replica догнала его собственный write?

Любая СУБД отвечает на эти вопросы по-своему. Различия в ответах определяют RPO, p99 commit latency и поведение в incident'е. Поэтому единственное «правильное» решение — per-workload: ledger и timeline не могут жить в одном режиме.

Replication lag — это не «3ms», это распределение с длинным хвостом: медианно может быть 1ms, p99 — 200ms, p99.9 — 5s (vacuum, WAL flood, cross-region blip). Любая стратегия, которая молча предполагает «replica догонит к моменту запроса», обязательно сломается на хвосте.

Что на диаграмме

Сцена — Postgres-кластер в DC-A плюс DR / cascading-плечо в DC-B:

• Application Tier — app-writer (INSERT/UPDATE) и app-reader (read query). Разделены умышленно: пишущий путь и читающий путь имеют разные SLA.
• Postgres Cluster (DC-A) — leader (WAL writer), replica-sync (synchronous_standby_names, режим remote_apply), две replica-async-* для read-scaling.
• DR & Cascading (DC-B) — intermediate replica подписана на leader, а уже от неё расходятся cascade-1 / cascade-2 (cascading) и replica-delayed (recovery_min_apply_delay = '1h').

Edges соответствуют физическим связям: WAL-стрим от leader → каждая прямая replica, дальше от intermediate ветвление в DC-B. Reads-edges от app-reader идут к leader (для RYW) и к async replicas (для масштабирования). Ответы на запросы анимируются обратно по тем же edges — отдельных reverse-edges не создаём (см. CLAUDE.md, раздел про edges vs animation).

Слой cascading включает DR-плечо; в base-слое его видно как затемнённую зону, чтобы сначала разобраться с основным кластером.

Сценарии

sync-commit — что значит «zero loss». Write идёт app-writer → leader, leader делает локальный WAL fsync, шлёт запись в replica-sync, ждёт ACK уровня remote_apply (запись уже применена на replica, не просто получена), и только после этого возвращает клиенту 200. Цена — local_fsync + 1 × RTT. Выгода — RPO = 0 на failover в пределах кластера. Это режим для ledger / billing.

async-stale — где ловится stale read. Leader коммитит локально, моментально отвечает клиенту, WAL уходит на async replicas в фоне. Через 250ms app-reader спрашивает replica-async-1 про только что вставленный пост #999 — и получает 404. Это нарушение read-your-writes, классическая жалоба «я написал, но в ленте не вижу». Лечится либо sticky-to-leader, либо передачей LSN с клиента (см. сценарий 4).

semi-sync-degrade — silent fallback, на который не алертит никто. MySQL rpl_semi_sync_master_timeout (default 10s) при недоступной sync replica молча переводит leader в async. Клиенты продолжают получать ACK'и, но WAL никто не подтверждает. Если leader упадёт в этом окне — все эти writes потеряны, хотя приложение видело успешный commit. Postgres ведёт себя аналогично: если в synchronous_standby_names = 'ANY 1 (...)' все standby недоступны, поведение зависит от synchronous_commit_timeout / oversight оператора. Обязательное правило: алерт на Rpl_semi_sync_status=OFF (MySQL) или pg_stat_replication.sync_state != 'sync' (Postgres) с пейджингом, не email'ом.

read-your-writes — как читать с replicas без вранья. После commit leader возвращает LSN (0/16A3F8 в сценарии). Клиент кладёт LSN в session / cookie / sticky-route. Следующий read в окне (обычно 5-10s) роутится либо на leader, либо на replica, у которой pg_last_wal_replay_lsn() >= 0/16A3F8. После окна — обычные reads на любую replica. Альтернативы: hybrid logical clock (CockroachDB), bounded staleness reads (Spanner).

delayed-dr — единственный реальный сценарий, где recovery_min_apply_delay спасает. Junior выполняет DELETE FROM users; без WHERE. Через секунды это применилось на leader, async replicas, intermediate, обоих cascade replicas. На replica-delayed WAL уже принят и лежит на диске — но apply отложен на час. У ops есть 60 минут, чтобы остановить replica, снять pg_dump нужных таблиц и восстановить в leader. PITR из backup'ов сделает то же самое, но медленнее (15-60 минут vs минута) и тяжелее по ресурсам.

Trade-offs (ADR-001: режим репликации primary-кластера)

Context. При построении HA нужно выбрать режим репликации между primary и standby. Этот выбор управляет тремя осями одновременно: durability (сколько данных теряется при отказе leader), commit latency (сколько ждёт клиент), availability (что происходит при медленной/недоступной replica).

Decision matrix.

Forces.

• Durability vs latency. Sync = 0 loss, но добавляет 1×RTT. Cross-region replica с RTT 80ms превратит p99 commit с 5ms в 90ms — пользователи это заметят.
• Availability «full sync»-mode. remote_apply ко всем standby = любая медленная replica становится SPOF. Решение — quorum (ANY 1 (r1, r2, r3)), который ждёт ack от любого одного из N.
• Semi-sync silent degrade. Без алерта на semi_sync_status ваш «semi-sync кластер» — это async со штампом «sync» на схеме. Это бомба замедленного действия, которая выстрелит ровно при failover, когда хочется иметь zero loss.
• Read replicas. Async для read-scaling — норма, но требует RYW-механизма (sticky, LSN-tracking, HLC). Иначе пользователь видит «своё» сообщение спустя 30s.

Decision (default для новых кластеров).

1. Финансовые / ordering данные → sync с quorum: synchronous_standby_names = 'ANY 1 (r1, r2, r3)', synchronous_commit = remote_apply. Минимум 3 standby, чтобы потеря одного не делала кластер degraded.
2. Application data (default) → semi-sync (ANY 1) с обязательным алертом на degrade. synchronous_commit = remote_write (быстрее remote_apply, но WAL гарантированно в OS buffer standby — этого достаточно для большинства failover-сценариев).
3. Logs / metrics / cache-like → fully async (synchronous_commit = local). Loss window ≤ replication lag = acceptable.
4. Read scaling → async cascading (leader → intermediate → N × read-replicas). Один WAL stream от leader, fanout в cascading layer.
5. DR insurance → всегда один delayed replica (recovery_min_apply_delay = '1h') плюс PITR backup window. Не «или». Delayed ловит human error быстро; PITR ловит то, что заметили через сутки.

Consequences (positive). Per-workload tuning — нет «единственно правильного» режима. Quorum предотвращает SPOF на медленной replica. Delayed replica ловит human error в первый час без участия backup-системы.

Consequences (negative). Sync mode добавляет latency, видимый в p99 → нужен capacity headroom на standby (медленный standby = медленный leader). Semi-sync обязывает к мониторингу — без него кластер незаметно превращается в async-кластер с «sync»-этикеткой. Cascading увеличивает end-to-end lag (сумма по hop'ам) и требует мониторинга lag на каждом уровне дерева.

Alternatives considered.

• Group replication / Galera (multi-primary). Устраняет failover как процесс, но требует certify-каждый-write, conflict resolution на коммите и плохо переживает long transactions. Подходит для append-only / write-once workloads.
• Raft-based (Spanner / CockroachDB / Yugabyte). Strong consistency без per-cluster tuning, но цена — write latency ≥ majority RTT и операционная сложность. Берём, если SQL-кластер на Postgres/MySQL уже не справляется горизонтально.
• Async-only + PITR. Дешевле в эксплуатации, но RPO = lag, и при leader crash теряем всё неreplicated. Категорически не подходит для финансов; ок для аналитики.

Реальные системы

• Postgres. Streaming replication (physical, page-level), logical replication (CREATE PUBLICATION / SUBSCRIPTION, можно подмножество таблиц), cascading через primary_conninfo указывающий на upstream replica. HA: Patroni (etcd/Consul/ZK) — лидер в проде, ~10-30s failover. Aurora Postgres — кастомный shared-storage layer, replica «promote» near-instant.
• MySQL. Async (default), semi-sync через rpl_semi_sync_* плагины, Group Replication (Paxos, multi-primary опционально). HA: Orchestrator для обнаружения и автоматического failover + ProxySQL для routing, InnoDB Cluster как «батарейки». Sharding — Vitess (используется YouTube / Slack / GitHub).
• MongoDB. Replica set с Raft-like election, ~10s failover. writeConcern: {w: "majority", wtimeout: ...} — но wtimeout означает «commit локально успешен, но не реплицирован» (та же ловушка, что у semi-sync).
• CockroachDB / YugabyteDB. Raft per range. Strong consistency по умолчанию, цена — write latency ≥ majority RTT.
• Spanner. Paxos per shard + TrueTime (атомные часы + GPS) для глобального ordering. External consistency без обмена координационными сообщениями.
• Cassandra / ScyllaDB. Leaderless, tunable consistency на запрос (ANY / ONE / QUORUM / ALL). RYW реализуется выбором R + W > N.

Anti-patterns

1. Semi-sync без мониторинга. Silent fallback в async, потеря writes при первом серьёзном incident'е. Алерт на semi_sync_status обязателен, страница — не email.
2. Multi-source replication с конфликтующими PK. Two sources пишут row с одним id — last-write-wins или ошибка применения, merge неполный. Решение — PK-префиксы по источнику или CRDT.
3. Cascading без планирования failover. Intermediate упал — дети «orphan», не знают про leader. Patroni / координация обязательны для cascading-топологий.
4. Delayed replica как единственный DR. Окно фиксировано (1h), после — потеряли. Нужен и delayed (быстрый rescue), и PITR (deep history).
5. Logical replication без мониторинга lag и slot retention. Slot копит WAL у leader. Subscriber отстал на сутки — у leader заполняется pg_wal. Конец — read-only mode или crash.
6. Async на финансовых данных. При failover теряются успешные транзакции, которые приложение и пользователь считали committed.
7. Failover без fencing (STONITH / lease + epoch). Split-brain: старый leader и новый одновременно принимают writes. Восстановление — ручной merge, часто без полной победы.
8. Sync на geo-replica. Каждый commit ждёт cross-region RTT (60-200ms). p99 убит, throughput — десятки RPS на connection.
9. Удалили standby — не дропнули replication slot. Leader продолжает копить WAL «для отсутствующей replica». Заканчивается переполнением диска и аварийным остановом.
10. Read-after-write на async replica без RYW. Пользователь видит «своё» сообщение спустя секунды; саппорт ловит «у меня всё сломано» во время которое уже всё ок.

Когда НЕ использовать

Тонкости из этого гайда — для production-кластера с реальными SLA. Они избыточны и вредны, если:

• Прототип / staging / hackathon. Async-репликация (или одиночный node + бэкапы) экономит время. Per-workload tuning, semi-sync с алертами, delayed replica — overhead без выгоды.
• БД целиком в managed-облаке (RDS Multi-AZ, Cloud SQL, Aurora). Провайдер уже выбрал режим за вас и обернул это SLA. Влезание в synchronous_commit руками может конфликтовать с automation. Сначала проверьте, что provider'ского режима не хватает.
• Append-only / immutable workload без read-your-writes требований. Метрики, логи, click-stream — async и lag в секунды нормальны, RYW не нужен.
• Однодатацентровая система без HA-требований. Простой repmgr / streaming replica + nightly базовый бэкап = достаточно. Cascading и delayed только усложнят runbook.
• Multi-region active-active. Эта тема — это про single-leader. Для active-active смотрите Raft-БД (Cockroach / Yugabyte / Spanner) или CRDT-БД (Riak, Redis CRDB), там другие trade-off'ы.

Дальше читать

• DDIA Ch.5 «Replication» — Kleppmann, фундамент. Mental models для всех режимов.
• Postgres docs: High Availability, Load Balancing, and Replication, Logical Replication, synchronous_commit reference.
• MySQL: Semi-Synchronous Replication, Multi-Source Replication, Group Replication.
• MongoDB: Write Concern — особенно секция про wtimeout и почему это не «отказ записи».
• Patroni: github.com/patroni/patroni — де-факто HA для Postgres. Прочитать docs/SETTINGS.rst и watchdog-секцию.
• Jepsen (Kyle Kingsbury): jepsen.io — independent correctness analyses. Reports на MongoDB, MySQL, Cassandra, Cockroach, etcd — must-read для понимания, где написанное в доках расходится с реальностью.
• Marc Shapiro et al. «Conflict-free Replicated Data Types» (2011) — оригинальная статья по CRDT.
• CloudArch concepts: ::concept{slug="replication"} (базовая теория), ::concept{slug="wal-write-ahead-log"} (откуда WAL), ::concept{slug="change-data-capture"} (logical decoding в CDC pipeline), ::case{slug="payment-system"} (где sync обязателен), ::case{slug="disaster-recovery"} (delayed + PITR на практике).