Транзакционная репликация

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

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

Транзакционная репликация базируется на концепции «публикации» и «подписки». Издатель (источник) определяет набор объектов для репликации — таблицы, хранимые процедуры, представления. Эти объекты объединяются в публикацию. Подписчики (приёмники) оформляют подписку на эту публикацию, указывая, какие данные и с какой периодичностью они хотят получать.

Основные компоненты архитектуры

Издатель (Publisher) — сервер базы данных, который является источником изменений. Он отвечает за отслеживание модификаций данных и подготовку их к передаче.
Распространитель (Distributor) — сервер, который принимает изменения от издателя и отвечает за их доставку подписчикам. Распространитель может быть размещён на том же сервере, что и издатель, или на отдельном выделенном сервере.
Подписчик (Subscriber) — сервер базы данных, который получает и применяет изменения. Подписчики могут быть как одноранговыми, так и иерархическими (например, подписчик может сам выступать издателем для других подписчиков).
Агент снимка (Snapshot Agent) — компонент, который создаёт начальную копию данных (снимок) для синхронизации подписчика с издателем.
Агент чтения журнала (Log Reader Agent) — компонент, который непрерывно считывает журнал транзакций издателя и идентифицирует изменения, подлежащие репликации.
Агент распространения (Distribution Agent) — компонент, который перемещает изменения от распространителя к подписчикам.

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

Начальная синхронизация: Перед началом репликации подписчик должен получить актуальную копию данных. Для этого агент снимка создаёт полный снимок публикуемых объектов (все строки таблиц, схемы) и передаёт его подписчику. После применения снимка подписчик синхронизируется с издателем на момент создания снимка.
Отслеживание изменений: После начальной синхронизации агент чтения журнала постоянно мониторит журнал транзакций издателя. Каждый раз, когда в журнале фиксируется транзакция, затрагивающая объекты публикации, агент извлекает из журнала только изменённые строки и их метаданные (тип операции: вставка, обновление, удаление; идентификатор строки; время транзакции).
Передача изменений: Агент чтения журнала помещает извлечённые изменения в очередь на распространителе. Распространитель хранит эти изменения в специальной базе данных (база данных распространения).
Применение изменений: Агент распространения, работающий на стороне распространителя или подписчика, периодически (или непрерывно) забирает изменения из базы данных распространения и применяет их к базе данных подписчика. Применение происходит в порядке, соответствующем порядку исходных транзакций на издателе, что гарантирует согласованность данных.

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

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

По синхронности

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

По топологии

Однонаправленная (Master-Slave): Издатель является единственным источником изменений. Подписчики только читают данные. Это классическая архитектура для масштабирования нагрузки на чтение.
Двунаправленная (Peer-to-Peer): Несколько серверов одновременно выступают и издателями, и подписчиками. Изменения, внесённые на любом из узлов, реплицируются на все остальные. Требует сложных механизмов разрешения конфликтов (например, на основе временных меток или приоритетов узлов). Используется в географически распределённых системах для обеспечения локальной доступности данных.
Обновляемая подписка (Updatable Subscription): Подписчик может не только читать, но и вносить изменения в реплицированные данные. Эти изменения затем передаются обратно на издатель и далее на другие подписчики. Реализуется через механизмы очередей или триггеров.

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

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

Высокая производительность чтения: Нагрузка на чтение может быть распределена между несколькими серверами-подписчиками, что снижает нагрузку на основной сервер.
Отказоустойчивость: При выходе из строя издателя можно переключить подписчика на роль нового издателя (при наличии соответствующей конфигурации).
Географическое распределение: Данные могут быть размещены вблизи пользователей, что снижает задержки доступа.
Минимальная задержка: Изменения передаются практически в реальном времени (в асинхронном режиме задержка составляет от нескольких секунд до минут).
Гарантированная целостность: Благодаря атомарности транзакций, данные на подписчике всегда согласованы в рамках каждой отдельной транзакции.

Недостатки

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

Применение

Транзакционная репликация широко используется в различных сценариях:

Веб-приложения и онлайн-сервисы: Для масштабирования нагрузки на чтение (например, чтение каталога товаров с нескольких серверов-подписчиков, а запись — на один издатель).
Отчётность и аналитика: Выгрузка данных с рабочего сервера на отдельный сервер отчётности без влияния на производительность основного приложения.
Географически распределённые системы: Обеспечение локального доступа к данным для пользователей из разных регионов (например, филиалы банка или торговой сети).
Резервное копирование и миграция: Создание горячей копии базы данных для быстрого восстановления или плавного перехода на новую версию СУБД.
Интеграция данных: Синхронизация данных между различными приложениями или системами (например, CRM и ERP).

Реализации в СУБД

Транзакционная репликация является встроенной функцией многих реляционных СУБД:

Microsoft SQL Server: Поддерживает транзакционную репликацию как один из стандартных типов (наряду со снимком и слиянием). Включает все описанные компоненты (агенты, публикации, подписки).
Oracle Database: Реализует транзакционную репликацию через механизмы Oracle GoldenGate и Streams (устаревший). GoldenGate обеспечивает высокопроизводительную репликацию между различными СУБД.
PostgreSQL: Поддерживает транзакционную репликацию через встроенные механизмы потоковой репликации (Streaming Replication) и логической репликации (Logical Replication). Логическая репликация PostgreSQL является наиболее близким аналогом транзакционной репликации, описанной выше.
MySQL: Встроенная репликация (асинхронная и полусинхронная) также является транзакционной, но с некоторыми ограничениями (например, репликация на основе строк или операторов).

Сравнение с другими типами репликации

Репликация снимка (Snapshot Replication): Создаёт полную копию данных на подписчике в определённый момент времени. Изменения не отслеживаются. Подходит для статических или редко изменяющихся данных. Транзакционная репликация, напротив, отслеживает каждое изменение.
Репликация слиянием (Merge Replication): Позволяет вносить изменения на всех узлах (издателе и подписчиках) автономно, а затем объединять их. Требует сложных механизмов разрешения конфликтов. Транзакционная репликация обычно предполагает, что источник изменений один (издатель), что упрощает управление.
Логическая репликация: В контексте PostgreSQL и других СУБД является синонимом транзакционной репликации, но с более гибкими возможностями (репликация отдельных таблиц, фильтрация строк, преобразование данных).

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

Термин «транзакционная репликация» впервые был введён в продуктах Sybase и Microsoft в 1990-х годах.
В современных распределённых базах данных (NewSQL), таких как CockroachDB или Google Spanner, транзакционная репликация реализована на уровне протокола консенсуса (например, Raft или Paxos), что обеспечивает строгую согласованность в глобальном масштабе.
В некоторых СУБД (например, в Microsoft SQL Server) транзакционная репликация может использоваться для репликации не только данных, но и изменений схемы базы данных (DDL-операции), что упрощает управление обновлениями.

Источники

Microsoft Learn: Transactional Replication Overview
Oracle Database Concepts: Replication
PostgreSQL Documentation: Logical Replication
MySQL Documentation: Replication
Книга: «Microsoft SQL Server 2012. Репликация данных» (Автор: К. Хендерсон)

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

На главную BFOmetr →