Открыть сервис

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

Синхронная репликация — это метод обеспечения идентичности данных на нескольких узлах распределённой системы, при котором операция записи считается успешной только после того, как данные будут подтверждены как записанные на всех (или на заданном кворуме) репликах. Данный подход гарантирует строгую согласованность данных (strong consistency) в любой момент времени, но вносит задержки, пропорциональные времени отклика самого медленного узла в группе репликации.

Принцип работы

Основное отличие синхронной репликации от асинхронной заключается в том, что клиент, инициирующий операцию записи, блокируется до получения подтверждения от всех участников репликационной группы. Алгоритм работы в общем виде состоит из следующих этапов:

  1. Клиент отправляет запрос на изменение данных (запись, обновление, удаление) на первичный узел (лидер, мастер).
  2. Первичный узел фиксирует изменение в своём локальном журнале транзакций или хранилище и отправляет копию изменения всем вторичным узлам (репликам).
  3. Каждый вторичный узел получает данные, применяет их к своей локальной копии и отправляет подтверждение (acknowledgement) обратно первичному узлу.
  4. Первичный узел, дождавшись подтверждения от всех узлов (или от заданного кворума, например, большинства), отправляет клиенту ответ об успешном завершении операции.

Если хотя бы один из узлов не отвечает в течение установленного тайм-аута или отвечает ошибкой, операция записи может быть отменена (откат), а узел, не ответивший вовремя, может быть исключён из группы репликации до восстановления его работоспособности.

Виды синхронной репликации

В зависимости от количества узлов, от которых требуется подтверждение, выделяют несколько конфигураций:

Полная синхронная репликация (Full synchronous replication)

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

Кворумная синхронная репликация (Quorum-based synchronous replication)

Требует подтверждения от большинства узлов (кворума). Например, в группе из 5 узлов достаточно получить подтверждение от 3. Этот подход является компромиссом между надёжностью и производительностью. Система может продолжать запись даже при отказе меньшинства узлов. Формула для расчёта кворума: N/2 + 1, где N — общее количество узлов.

Репликация с подтверждением от одного узла (Synchronous commit to one replica)

В некоторых системах (например, в PostgreSQL) существует режим, при котором первичный узел ожидает подтверждения только от одной выделенной синхронной реплики. Это быстрее, чем полная репликация, но всё равно медленнее асинхронной. При отказе первичного узла, синхронная реплика гарантированно содержит все последние изменения.

Преимущества и недостатки

Преимущества

Недостатки

Применение

Синхронная репликация применяется в системах, где потеря данных или нарушение согласованности недопустимы:

Отличие от асинхронной репликации

ХарактеристикаСинхронная репликацияАсинхронная репликация
Подтверждение записиПосле записи на все реплики (или кворум)Сразу после записи на первичный узел
СогласованностьСтрогая (Strong)Конечная (Eventual)
Потери данных при сбоеОтсутствуют (при корректной настройке)Возможны (потеря неотреплицированных данных)
Задержка записиВысокая (зависит от самого медленного узла)Низкая (зависит только от первичного узла)
Доступность записиНиже (зависит от всех узлов)Выше (зависит только от первичного узла)

Пример реализации: PostgreSQL

В СУБД PostgreSQL синхронная репликация настраивается через параметры конфигурации synchronous_commit и synchronous_standby_names. Администратор может указать список синхронных реплик (например, FIRST 1 (standby1, standby2) или ANY 2 (standby1, standby2, standby3)). Первичный сервер (мастер) не подтверждает транзакцию клиенту до тех пор, пока указанные реплики не запишут данные в свой журнал предзаписи (WAL) и не отправят подтверждение. Если все синхронные реплики выходят из строя, мастер перестаёт принимать записи, чтобы избежать потери данных.

Источники

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →