Синхронная репликация
Синхронная репликация — это метод обеспечения идентичности данных на нескольких узлах распределённой системы, при котором операция записи считается успешной только после того, как данные будут подтверждены как записанные на всех (или на заданном кворуме) репликах. Данный подход гарантирует строгую согласованность данных (strong consistency) в любой момент времени, но вносит задержки, пропорциональные времени отклика самого медленного узла в группе репликации.
Принцип работы
Основное отличие синхронной репликации от асинхронной заключается в том, что клиент, инициирующий операцию записи, блокируется до получения подтверждения от всех участников репликационной группы. Алгоритм работы в общем виде состоит из следующих этапов:
- Клиент отправляет запрос на изменение данных (запись, обновление, удаление) на первичный узел (лидер, мастер).
- Первичный узел фиксирует изменение в своём локальном журнале транзакций или хранилище и отправляет копию изменения всем вторичным узлам (репликам).
- Каждый вторичный узел получает данные, применяет их к своей локальной копии и отправляет подтверждение (acknowledgement) обратно первичному узлу.
- Первичный узел, дождавшись подтверждения от всех узлов (или от заданного кворума, например, большинства), отправляет клиенту ответ об успешном завершении операции.
Если хотя бы один из узлов не отвечает в течение установленного тайм-аута или отвечает ошибкой, операция записи может быть отменена (откат), а узел, не ответивший вовремя, может быть исключён из группы репликации до восстановления его работоспособности.
Виды синхронной репликации
В зависимости от количества узлов, от которых требуется подтверждение, выделяют несколько конфигураций:
Полная синхронная репликация (Full synchronous replication)
Требует подтверждения от всех узлов в группе репликации. Обеспечивает максимальную надёжность и согласованность, но имеет наименьшую производительность и доступность. Отказ одного узла делает невозможной запись до его восстановления или ручного переконфигурирования группы.
Кворумная синхронная репликация (Quorum-based synchronous replication)
Требует подтверждения от большинства узлов (кворума). Например, в группе из 5 узлов достаточно получить подтверждение от 3. Этот подход является компромиссом между надёжностью и производительностью. Система может продолжать запись даже при отказе меньшинства узлов. Формула для расчёта кворума: N/2 + 1, где N — общее количество узлов.
Репликация с подтверждением от одного узла (Synchronous commit to one replica)
В некоторых системах (например, в PostgreSQL) существует режим, при котором первичный узел ожидает подтверждения только от одной выделенной синхронной реплики. Это быстрее, чем полная репликация, но всё равно медленнее асинхронной. При отказе первичного узла, синхронная реплика гарантированно содержит все последние изменения.
Преимущества и недостатки
Преимущества
- Строгая согласованность (Strong consistency): Все клиенты всегда видят одну и ту же версию данных. Нет состояния «грязного чтения» или чтения устаревших данных.
- Нулевые потери данных (Zero data loss): При корректной настройке и отказе первичного узла, данные не теряются, так как все изменения уже сохранены на репликах.
- Простота логики приложений: Разработчикам не нужно беспокоиться о конфликтах данных или временных несоответствиях.
Недостатки
- Высокая задержка (Latency): Время отклика на запись определяется самым медленным узлом в группе. Географически распределённые реплики (между дата-центрами) могут приводить к задержкам в сотни миллисекунд.
- Сниженная доступность (Availability): При отказе одного или нескольких узлов (в зависимости от конфигурации) система может полностью прекратить приём операций записи.
- Сложность масштабирования: Добавление новых реплик увеличивает задержку и снижает отказоустойчивость системы на запись.
Применение
Синхронная репликация применяется в системах, где потеря данных или нарушение согласованности недопустимы:
- Финансовые системы: банковские транзакции, биржевые операции, системы расчётов.
- Системы управления базами данных (СУБД): кластеры PostgreSQL (синхронный режим коммита), MySQL Group Replication, кластеры на базе Galera.
- Распределённые файловые системы: системы, требующие строгой целостности метаданных (например, HDFS при записи блока данных).
- Системы управления конфигурациями: хранилища ключей и сертификатов (etcd, Consul, ZooKeeper), где согласованность критична для координации распределённых сервисов.
Отличие от асинхронной репликации
| Характеристика | Синхронная репликация | Асинхронная репликация |
|---|---|---|
| Подтверждение записи | После записи на все реплики (или кворум) | Сразу после записи на первичный узел |
| Согласованность | Строгая (Strong) | Конечная (Eventual) |
| Потери данных при сбое | Отсутствуют (при корректной настройке) | Возможны (потеря неотреплицированных данных) |
| Задержка записи | Высокая (зависит от самого медленного узла) | Низкая (зависит только от первичного узла) |
| Доступность записи | Ниже (зависит от всех узлов) | Выше (зависит только от первичного узла) |
Пример реализации: PostgreSQL
В СУБД PostgreSQL синхронная репликация настраивается через параметры конфигурации synchronous_commit и synchronous_standby_names. Администратор может указать список синхронных реплик (например, FIRST 1 (standby1, standby2) или ANY 2 (standby1, standby2, standby3)). Первичный сервер (мастер) не подтверждает транзакцию клиенту до тех пор, пока указанные реплики не запишут данные в свой журнал предзаписи (WAL) и не отправят подтверждение. Если все синхронные реплики выходят из строя, мастер перестаёт принимать записи, чтобы избежать потери данных.
Источники
- Клеппман М. «Высоконагруженные приложения. Программирование, масштабирование, поддержка» (Глава 5: Репликация).
- Gray J., Reuter A. «Transaction Processing: Concepts and Techniques».
- Документация PostgreSQL: глава «Replication, Backup, and High Availability».
- Документация MySQL: глава «Group Replication».
- Официальная документация etcd: раздел «Fault Tolerance».
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →