Репликация «ведущий-ведомый

Репликация «ведущий-ведомый» (англ. leader-follower replication, primary-replica replication) — это механизм синхронизации данных между несколькими узлами в распределённой системе, при котором один узел назначается «ведущим» (или «мастером», primary), а остальные — «ведомыми» (или «репликами», replicas). Ведущий узел принимает все операции записи и модификации данных, а затем передаёт эти изменения ведомым узлам, которые хранят копию данных и обслуживают запросы на чтение. Данная архитектура обеспечивает отказоустойчивость, масштабирование нагрузки на чтение и согласованность данных, хотя и имеет ограничения по производительности записи и устойчивости к сбоям ведущего узла.

История

Концепция репликации «ведущий-ведомый» восходит к ранним системам управления базами данных (СУБД) 1970-х годов, когда возникла необходимость в дублировании данных для обеспечения надёжности. Одним из первых коммерческих продуктов, реализовавших подобную схему, стала СУБД IBM IMS (Information Management System), использовавшаяся в банковских и авиационных системах. В 1980-х годах с развитием реляционных баз данных (например, Oracle, Sybase) репликация стала стандартным механизмом для создания резервных копий и распределения нагрузки.

В 1990-х годах, с распространением интернета и веб-приложений, репликация «ведущий-ведомый» получила широкое применение в системах управления контентом (CMS) и электронной коммерции. Крупные проекты, такие как MySQL и PostgreSQL, внедрили встроенную поддержку этой модели. В 2000-х годах, с ростом объёмов данных и требований к доступности, архитектура была адаптирована для NoSQL-баз данных (например, MongoDB, Redis) и систем распределённого кэширования.

В России репликация «ведущий-ведомый» активно используется в государственных информационных системах, таких как «Единый портал государственных услуг» (ЕПГУ) и «Госуслуги», где требуется высокая отказоустойчивость и согласованность данных. В 2010-х годах, с переходом на облачные технологии, эта модель стала основой для многих сервисов «Яндекса» (например, Яндекс.Почта, Яндекс.Карты) и Сбербанка (СберБанк Онлайн).

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

Архитектура

Система с репликацией «ведущий-ведомый» состоит из двух типов узлов:

Ведущий узел (мастер) — единственный узел, который принимает запросы на запись (INSERT, UPDATE, DELETE в реляционных СУБД). Он обрабатывает транзакции, генерирует журнал изменений (log) и передаёт его ведомым.
Ведомые узлы (реплики) — один или несколько узлов, которые получают изменения от ведущего и применяют их к своей копии данных. Ведомые обслуживают запросы на чтение (SELECT), что позволяет снизить нагрузку на ведущий узел.

Процесс репликации

Запись на ведущем узле: Клиент отправляет запрос на запись ведущему узлу. Ведущий выполняет операцию, фиксирует её в журнале транзакций (например, binary log в MySQL, WAL в PostgreSQL) и отправляет изменения ведомым.
Передача изменений: Ведущий передаёт ведомым данные через сетевой протокол (например, TCP/IP). В зависимости от реализации, передача может быть синхронной (ведомый подтверждает получение до завершения записи) или асинхронной (ведущий не ждёт подтверждения).
Применение изменений на ведомых: Ведомые узлы получают журнал изменений и применяют его к своей локальной копии данных. В результате ведомые становятся точными копиями ведущего на момент последней синхронизации.
Чтение с ведомых: Клиент может направлять запросы на чтение любому ведомому узлу, что распределяет нагрузку и повышает производительность системы.

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

Синхронная репликация: Ведущий узел ожидает подтверждения от всех ведомых (или от заданного числа) перед тем, как завершить транзакцию. Это гарантирует, что данные на ведомых всегда актуальны, но увеличивает задержку записи и снижает пропускную способность. Используется в системах, где важна согласованность (например, финансовые транзакции).
Асинхронная репликация: Ведущий узел завершает транзакцию сразу после локальной записи, не дожидаясь подтверждения от ведомых. Это обеспечивает высокую производительность записи, но при сбое ведущего часть данных может быть потеряна (если изменения не успели передаться). Применяется в системах, где допустима некоторая задержка (например, кэширование, аналитика).

Классификация

По типу передачи данных

Логическая репликация — передаются только изменения данных (например, SQL-команды или записи в журнале). Используется в PostgreSQL (логическая репликация) и MySQL (репликация на основе строк).
Физическая репликация — передаются блоки данных на уровне файловой системы или диска. Применяется в Oracle Data Guard и PostgreSQL (физическая репликация через WAL).

По количеству ведущих узлов

Один ведущий — классическая схема, где только один узел принимает записи. Это упрощает управление согласованностью, но создаёт единую точку отказа.
Множество ведущих (multi-master) — несколько узлов могут принимать записи, что повышает отказоустойчивость, но требует сложных механизмов разрешения конфликтов. Примеры: MySQL Group Replication, PostgreSQL BDR.

По способу выбора ведущего

Ручное назначение — администратор вручную назначает ведущий узел при настройке. Используется в небольших системах.
Автоматическое переключение (failover) — при сбое ведущего ведомые автоматически выбирают нового ведущего с помощью алгоритмов, таких как консенсус (например, Raft, Paxos) или голосование. Примеры: PostgreSQL Patroni, MySQL Orchestrator.

Применение

Базы данных

Репликация «ведущий-ведомый» является стандартом для реляционных СУБД:

MySQL: Встроенная репликация (асинхронная, полусинхронная) используется в веб-приложениях (например, WordPress, Facebook*).
PostgreSQL: Поддерживает как физическую (через WAL), так и логическую репликацию. Применяется в системах управления данными (например, в «1С:Предприятие»).
Oracle: Data Guard обеспечивает синхронную и асинхронную репликацию для корпоративных систем.
Microsoft SQL Server: Always On Availability Groups реализуют репликацию с автоматическим переключением.

NoSQL и кэширование

Redis: Репликация «ведущий-ведомый» используется для кэширования и очередей сообщений. Ведущий обрабатывает запись, ведомые — чтение.
MongoDB: Репликация через наборы реплик (replica sets), где один узел является первичным (primary), а остальные — вторичными (secondary).
Cassandra: Использует peer-to-peer архитектуру, но в некоторых конфигурациях применяет модель «ведущий-ведомый» для обеспечения согласованности.

Веб-сервисы и облачные платформы

Яндекс.Облако: Сервис Managed Database (например, Managed PostgreSQL) автоматически настраивает репликацию «ведущий-ведомый» для обеспечения отказоустойчивости.
СберТех: Платформа «СберБанк Онлайн» использует репликацию на базе Oracle Data Guard для обработки транзакций.
Госуслуги: ЕПГУ применяет репликацию PostgreSQL для дублирования данных в нескольких дата-центрах.

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

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

Простота реализации: Архитектура с одним ведущим упрощает управление согласованностью данных и разрешение конфликтов.
Масштабирование чтения: Ведомые узлы могут обслуживать большое количество запросов на чтение, что снижает нагрузку на ведущий.
Отказоустойчивость: При сбое ведущего ведомый может быть повышен до ведущего (failover), что минимизирует время простоя.
Резервное копирование: Ведомые узлы могут использоваться для создания резервных копий без остановки работы ведущего.

Недостатки

Единая точка отказа для записи: При сбое ведущего все операции записи блокируются до переключения на новый ведущий.
Задержка репликации: При асинхронной репликации ведомые могут отставать от ведущего, что приводит к чтению устаревших данных.
Ограниченная масштабируемость записи: Все записи проходят через один узел, что ограничивает пропускную способность системы.
Потеря данных при сбое: В асинхронном режиме при внезапном сбое ведущего часть непереданных изменений может быть утеряна.

Критика

Основная критика модели «ведущий-ведомый» связана с её ограниченной масштабируемостью и уязвимостью к сбоям ведущего узла. В высоконагруженных системах (например, социальные сети, биржевые платформы) единая точка записи становится узким местом. Альтернативные подходы, такие как peer-to-peer репликация (например, в Cassandra) или распределённые консенсусные протоколы (Raft, Paxos), предлагают более высокую отказоустойчивость и масштабируемость, но требуют более сложной реализации.

В России, в условиях импортозамещения, активно развиваются отечественные СУБД, такие как «Postgres Professional» (на базе PostgreSQL) и «СУБД Ред База Данных» (на базе Oracle-совместимых технологий). В этих системах репликация «ведущий-ведомый» остаётся ключевым механизмом, но дополняется автоматическим failover и поддержкой множества ведущих для повышения надёжности.

Интересные факты

В MySQL репликация «ведущий-ведомый» может быть настроена в цепочку (chain replication), где ведомый одновременно является ведущим для другого узла. Это позволяет создавать многоуровневые топологии.
В PostgreSQL репликация через WAL (Write-Ahead Log) позволяет передавать изменения с минимальной задержкой (менее 1 миллисекунды в локальной сети).
В 2020 году компания «Яндекс» внедрила репликацию «ведущий-ведомый» для сервиса Яндекс.Карты, что позволило обрабатывать до 1 миллиона запросов в секунду на чтение.

Источники

Клеппман М. «Высоконагруженные приложения. Программирование, масштабирование, поддержка». — СПб.: Питер, 2020.
Документация MySQL 8.0: «Replication». — Oracle Corporation, 2023.
Документация PostgreSQL 16: «Replication and Failover». — PostgreSQL Global Development Group, 2024.
Официальный сайт «Postgres Professional»: «Репликация в PostgreSQL». — 2023.
Федеральный закон «О персональных данных» № 152-ФЗ (в части требований к резервированию данных).

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

На главную BFOmetr →