Как работает репликация в PostgreSQL?

Question

Accepted Answer

**Репликация** копирует данные из **основной** базы данных на один или несколько **реплика** (резервные) серверы — для высокой доступности (отказоустойчивость при сбое основного сервера) и масштабирования чтения (распределение запросов чтения). PostgreSQL в основном использует **потоковую репликацию** (физическую) на основе журнала упреждающей записи (WAL).

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

```text
Primary  ──(streams WAL: the write-ahead log of changes)──▶  Replica(s)
  ✓ The primary handles all WRITES
  ✓ Replicas continuously apply the primary's WAL → stay in sync (near-real-time)
  ✓ Replicas can serve READ queries ("hot standby") → scale reads
```

Основной сервер передает свой **WAL** (журнал упреждающей записи — запись каждого изменения) репликам, которые применяют его для синхронизации. Реплики — это доступные только для чтения копии, которые могут обслуживать запросы чтения.

## Преимущества: HA и масштабирование чтения

```text
HIGH AVAILABILITY → if the primary fails, a replica can be PROMOTED to primary (failover)
  → minimal downtime, no data loss (with synchronous replication)
READ SCALING → route read-only queries to replicas → offload the primary
  → handle more read traffic (great for read-heavy workloads)
BACKUPS → take backups from a replica without loading the primary
```

## Синхронная и асинхронная репликация

```text
ASYNCHRONOUS (default) → the primary commits without waiting for replicas
  ✓ faster writes (no wait)   ✗ a tiny window of potential data loss on failover
SYNCHRONOUS → the primary waits for a replica to confirm before committing
  ✓ no data loss on failover  ✗ slower writes (waits for the replica)
→ Choose based on the durability vs performance trade-off.
```

## Логическая репликация (другая модель)

```text
LOGICAL replication → replicates specific TABLES/changes (not the whole cluster), based
on a publish/subscribe model. Enables: selective replication, cross-version, and
replicating to different schemas → good for migrations, integrations, partial replication.
```

## Высокая доступность на практике

```text
Tools like Patroni, repmgr, or cloud-managed Postgres automate FAILOVER (detecting
primary failure and promoting a replica) → near-automatic high availability.
A load balancer / connection router directs writes to the primary, reads to replicas.
```

## Почему это важно

Репликация важна для построения **высокодоступных и масштабируемых** развертываний PostgreSQL, поэтому понимание её — это ценные знания уровня опытного специалиста для архитектуры production-базы данных.

Два основных преимущества критичны для серьёзных приложений: **высокая доступность** (если основная база данных выходит из строя, реплика может быть повышена для замены, минимизируя время простоя — необходимо для систем, которые должны оставаться доступными) и **масштабирование чтения** (маршрутизация запросов только для чтения на реплики разгружает основной сервер, позволяя системе обрабатывать гораздо больший трафик чтения — ценно для рабочих нагрузок с интенсивным чтением).

Понимание **потоковой репликации** (основной сервер передает свой WAL репликам, которые остаются синхронизированными и могут обслуживать чтение) — это основа.

Знание компромисса **синхронная или асинхронная** важно: асинхронная (по умолчанию — более быстрая запись, но небольшое окно потенциальной потери данных при отказоустойчивости) в сравнении с синхронной (отсутствие потери данных, но более медленная запись) — решение о долговечности vs производительности, влияющее на надежность.

Понимание **логической репликации** (репликация конкретных таблиц через pub/sub, полезно для миграций, кроссверсий и частичной/выборочной репликации) расширяет опции.

Знание того, что **инструменты HA** (Patroni, repmgr, управляемый облачный Postgres) автоматизируют отказоустойчивость, и что маршрутизация чтения/записи направляет трафик надлежащим образом — это практические знания архитектуры.

Поскольку высокая доступность и масштабируемость — это основные требования для production-систем баз данных, а репликация (со своей отказоустойчивостью HA, масштабированием чтения, компромиссом синхронная/асинхронная долговечность и логической репликацией для гибкости) — это основной механизм, предоставляемый PostgreSQL для их достижения, понимание репликации — это важные знания уровня опытного специалиста для проектирования надежных, масштабируемых развертываний Postgres — часто актуальная задача для production-систем и тема, демонстрирующая понимание доступности и масштабирования баз данных, ожидаемое для опытных специалистов по базам данных и backend-разработчиков.