репликация транзакций

Область применения: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

В этой статье описывается репликация транзакций для SQL Server. Репликация транзакций обычно начинается с создания моментального снимка объектов и данных базы данных публикации. Как только создан исходный моментальный снимок, последующие изменения данных и схемы на издателе обычно доставляются подписчику без задержек (практически в реальном времени). Изменения данных применяются на подписчике в том же порядке и в тех же рамках транзакций, в которых они выполнялись у издателя. Поэтому в пределах публикации гарантируется согласованность транзакций.

Обзор

Репликация транзакций обычно используется в серверных средах и пригодна в следующих случаях:

• Необходимо, чтобы дополнительные изменения распространялись подписчикам сразу же, как только они происходят.

• Приложению требуется низкая задержка между моментом внесения изменений у Publisher и моментом, когда эти изменения поступают к Subscriber.

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

• На издателе выполняется очень большое количество операций вставки, обновления и удаления.

• Издатель или подписчик являются базой данных, отличной от SQL Server, например Oracle.

По умолчанию подписчики на транзакционные публикации должны считаться доступными только для чтения, так как изменения не передаются обратно издателю. Однако транзакционная репликация предоставляет возможности, позволяющие выполнять обновления на подписчике.

Примечание.

Управляемый экземпляр SQL Azure может быть издателем, распространителем и подписчиком для репликации моментальных снимков и транзакций. Базы данных в База данных SQL Azure могут выступать только как подписчики типа push для репликации моментальных снимков и транзакционной репликации. Дополнительные сведения см. в статье о репликации транзакций с Базой данных SQL Azure и Управляемым экземпляром SQL Azure.

Настройка шифрования TLS 1.3

SQL Server 2025 (17.x) предоставляет поддержку TDS 8.0 для репликации транзакций, включая:

• Настройка агентов репликации для использования шифрования TLS 1.3 между экземплярами SQL Server 2025 (17.x), а также между SQL Server 2025 (17.x) и Управляемым экземпляром SQL Azure.
• Шифрование по умолчанию для обмена данными между экземплярами связанного сервера SQL Server 2025 (17.x) в топологии репликации. Связанные серверы в SQL Server 2025 (17.x) используют драйвер OLE DB версии 19, который по умолчанию используется для Encrypt=Mandatory шифрования.

Примечание.

Для топологий репликации с удаленным распространителем:

• Компоненты репликации могут дать сбой после обновления до SQL Server 2025 для экземпляров с удаленным дистрибьютором
• Добавление удаленного распространителя к издателю SQL Server 2025 может не выполниться

Как работает репликация транзакций

Транзакционная репликация реализуется агентом моментальных снимков SQL Server, агентом чтения журнала и агентом распространения. Агент моментальных снимков подготавливает файлы моментального снимка, содержащие схему и данные опубликованных таблиц и объектов базы данных, сохраняет эти файлы в папке моментальных снимков и записывает задания синхронизации в базу данных распространения на распространителе.

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

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

На следующем рисунке показаны основные компоненты репликации транзакций.

Исходная база данных

Прежде чем новый подписчик транзакционной репликации сможет получать инкрементальные изменения от издателя, подписчик должен содержать таблицы с той же схемой и теми же данными, что и таблицы на издателе. Исходный набор данных обычно представляет собой моментальный снимок, который создается агентом моментальных снимков, а распространяется и применяется агентом распространения. Исходный набор данных также можно предоставить с помощью резервного копирования или других средств, таких как службы SQL Server Integration Services.

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

Параллельная обработка моментальных снимков

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

агент моментальных снимков

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

После создания файлов моментальных снимков их можно просмотреть в папке моментальных снимков с помощью Microsoft Windows Explorer.

Изменение данных и агент чтения журналов

Агент чтения журнала работает на распределителе; обычно он работает непрерывно, но также может запускаться по заданному вами расписанию. При выполнении агент чтения журнала сначала считывает журнал транзакций публикации (тот же журнал базы данных, который используется для отслеживания транзакций и восстановления во время обычной работы ядра СУБД SQL Server) и определяет любые операторы INSERT, UPDATE и DELETE, а также другие изменения, внесенные в данные в транзакциях, помеченных для репликации. Далее агент копирует эти транзакции пакетами в базу данных распространения у Распространителя. Агент чтения журнала использует внутреннюю хранимую процедуру sp_replcmds для получения из журнала следующего набора команд, отмеченных для репликации. После этого база данных распространителя становится очередью с функциями хранения и переадресации, из которой изменения отправляются подписчикам. В базу данных распространителя отправляются только зафиксированные транзакции.

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

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

Агент распространителя

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

Типы публикации

Репликация транзакций поддерживает четыре типа публикаций:

Тип публикации	Описание
Стандартная публикация транзакций	Подходит для топологий, в которых все данные у абонента доступны только для чтения (репликация транзакций не гарантирует соблюдение этого у абонента). Стандартные публикации транзакций создаются по умолчанию, если используется Transact-SQL или объекты RMO. При использовании мастера создания публикаций они создаются путем выбора транзакционной публикации на странице Тип публикации. Дополнительные сведения о создании публикаций см. в статье Публикация данных и объектов базы данных.
публикация транзакций с обновляемыми подписками;	Ниже приведены характеристики этого типа публикации: -Каждый узел содержит идентичные данные: один издатель и один подписчик. -Строки можно обновлять в подписчике -Эта топология лучше всего подходит для серверных сред, где требуются высокая доступность и масштабируемость операций чтения. Дополнительные сведения см. в разделе Обновляемые подписки.
Одноранговая топология	Ниже приведены характеристики этого типа публикации: - Каждое расположение содержит идентичные данные и действует и как издатель, и как подписчик. - Одну и ту же строку можно изменить только в одном месте одновременно. - Поддерживает обнаружение конфликтов. - Эта топология лучше всего подходит для серверных сред, где требуются высокая доступность и масштабируемость чтения. Дополнительные сведения см. в разделе Peer-to-Peer Transactional Replication.
Двунаправленная репликация транзакций	Ниже приведены характеристики этого типа публикации: Двунаправленная репликация аналогична одноранговой репликации, однако она не обеспечивает разрешение конфликтов. Кроме того, двунаправленная репликация ограничена 2 серверами. Дополнительные сведения см. в статье Двунаправленная репликация транзакций.