Транзакционная репликация с Azure SQL Managed Instance

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

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

Overview

Репликацию транзакций можно использовать для отправки изменений, внесенных в управляемый экземпляр SQL Azure:

• База данных SQL Server (локальная или виртуальная машина Azure)
• база данных в Базе данных SQL Azure;
• База данных в Azure SQL Управляемом экземпляре

Components

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

Издатель публикует изменения, внесенные в некоторые таблицы (статьи), отправляя обновления распространителю. Издателем может быть управляемый экземпляр SQL в Azure или экземпляр SQL Server.

Распространитель собирает изменения в статьях от издателя и распространяет их подписчикам. Распространитель может быть управляемым экземпляром SQL Azure или экземпляром SQL Server (любая версия, если она равна или выше версии издателя).

Подписчик получает изменения, внесенные Издателем. Экземпляр SQL Server и управляемый экземпляр SQL Azure могут быть подписчиками push и pull, хотя подписка pull не поддерживается, если распространителем является управляемый экземпляр SQL Azure, а подписчик — нет. База данных в Azure SQL Database может быть только подписчиком в модели 'push'.

Управляемый экземпляр Azure SQL может поддерживать возможность быть подписчиком из следующих версий SQL Server:

• SQL Server 2016 и более поздних версий
• SQL Server 2014 RTM CU10 (12.0.4427.24) или SP1 CU3 (12.0.2556.4)
• SQL Server 2012 SP2 CU8 (11.0.5634.1) или SP3 (11.0.6020.0) или SP4 (11.0.7001.0)

Типы репликации

Существуют разные типы репликации.

Матрица поддержки

Матрица поддержки репликации транзакций и моментальных снимков для Управляемого экземпляра SQL Azure совпадает с матрицей поддержки репликации транзакций для SQL Server:

AUTD применяется к управляемому экземпляру SQL Azure, настроенного с помощью политики обновления Always-up-to-date.
²⁰²⁵ Применяется к Управляемому экземпляру SQL Azure, настроенному с политикой обновления SQL Server 2025.
²⁰²² Применяется к Управляемому экземпляру SQL Azure, настроенному с политикой обновления SQL Server 2022 .
¹ Применяется на основе требований поддерживаемых конфигураций для базы данных SQL в Microsoft Fabric.

Когда использовать

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

• Публикация изменений, внесенных в одной или нескольких таблицах в базе данных, и их распределение в одну или несколько баз данных экземпляра SQL Server или Azure SQL Database, которые подписаны на получение изменений.
• Поддержание нескольких распределенных баз данных в синхронизированном состоянии.
• Миграция баз данных из одного экземпляра SQL Server или Управляемого экземпляра SQL Azure в другую базу данных путем постоянной публикации изменений.

Сравните синхронизацию данных с транзакционной репликацией

Общие конфигурации

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

Издатель с локальным дистрибьютором в управляемом экземпляре SQL

Издатель и распространитель настраиваются в одном управляемом экземпляре SQL и распределяют изменения в другом управляемом экземпляре SQL, базе данных SQL или экземпляре SQL Server.

Издатель с удаленным распространителем на управляемом сервере (инстансе) SQL

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

Издатель и распространитель настроены на двух управляемых экземплярах. В этой конфигурации есть некоторые ограничения.

• Оба управляемых экземпляра находятся в той же виртуальной сети.
• Оба управляемых экземпляра находятся в том же местоположении.

Локальный издатель или распространитель с удаленным подписчиком

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

Requirements

• При подключении между участниками репликации следует использовать проверку подлинности SQL.
• Для рабочей папки, используемой для репликации, используйте общий ресурс учетной записи хранения Azure.
• Для получения доступа к общей папке Azure следует открыть исходящий TCP-порт 445 в правилах безопасности подсети.
• Откройте исходящий порт TCP 1433, когда управляемый экземпляр SQL используется в качестве издателя и/или дистрибьютора, а подписчик не является таковым. Кроме того, может потребоваться изменить правило безопасности для исходящего трафика NSG управляемого экземпляра SQL для , заменив тег службы назначения порта 1433 с на .
• Разместите издателя и распространителя в облаке или локальной среде.
• Настройте пиринговое подключение VPN между виртуальными сетями участников репликации, если они различаются.

Security

Поддержка TLS 1.3

Управляемый экземпляр SQL Azure поддерживает TLS 1.3 для подключений репликации, инициализированных агентами, настроенными для работы на этом экземпляре SQL. Это относится к топологии репликации между двумя экземплярами SQL под управлением, а также к любой версии SQL Server, выступающей в качестве подписчика от издателя и распределителя управляемого экземпляра SQL.

Если вы используете TLS 1.3 для защиты подключений между экземплярами в топологии репликации, укажите значение 3 или 4 для параметра -EncryptionLevel каждого агента репликации:

• Агент распространителя
• Агент чтения журналов
• Агент моментальных снимков

Значение 3 обеспечивает принудительное использование TLS 1.3 для подключений к управляемым экземплярам SQL, но не влияет на подключения к серверам SQL Server. Значение 4 обеспечивает подключения TLS 1.3 между управляемыми экземплярами SQL, а также для подключений из управляемых экземпляров SQL к SQL Server и требует установки сертификата на узел SQL Server.

Войти replAgentUser.

Экземпляры, настроенные с помощью агента распространения или моментального снимка, получают replAgentUser учетную запись, создаваемую автоматически. Агент распространения и моментальных снимков использует replAgentUser имя входа для подключения к соответствующей базе данных. Для push подписки имя входа создается у распространителя. Для подписки типа pull или анонимной подписки у подписчика создается учетная запись. Имя входа является членом фиксированной db_owner роли базы данных в распределительной или подписной базе данных.

Логин replAgentUser автоматически создается при первом запуске агента репликации. Логин автоматически исключается из дистрибьютора при запуске хранимой процедуры sp_dropdistributor. Имя учетной записи автоматически удаляется из подписчика при удалении последней pull подписки или анонимной подписки.

Limitations

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

Файлы моментальных снимков не удаляются из учетной записи служба хранилища Azure

Управляемый экземпляр Azure SQL использует настроенный пользователем аккаунт хранилища Azure для файлов моментальных снимков, используемых в транзакционной репликации. В отличие от SQL Server в локальной среде, Управляемый экземпляр SQL Azure не удаляет файлы моментальных снимков из учетной записи службы хранения Azure. После того как файлы больше не нужны, их следует удалить. Это можно сделать с помощью интерфейса службы хранилища Azure на портале Azure, Microsoft Azure Storage Explorer, или с помощью клиентов командной строки (Azure PowerShell или CLI) или REST API управления хранилищем Azure.

Ниже приведен пример того, как удалить файл и как удалить пустую папку.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

Количество агентов распространения, работающих непрерывно

Число агентов распространения, настроенных для непрерывной работы, ограничено до 30 в службе Azure SQL Managed Instance. Чтобы иметь больше агентов распространения, они должны работать либо по запросу, либо по определённому расписанию. Расписание можно задавать с частотой каждые 10 секунд (или более), поэтому, даже если это не является непрерывным, вы всё равно можете использовать распространитель, который вносит задержку всего в несколько секунд. Если требуется большое количество распространителей, рекомендуется использовать запланированную и не непрерывную конфигурацию.

Группы отработки отказа

Использование транзакционной репликации с экземплярами, которые находятся в группе отказоустойчивости, поддерживается. Однако, если вы настроите репликацию до добавления управляемого экземпляра SQL в группу аварийного переключения, репликация приостанавливается при начале создания группы, и монитор репликации показывает статус Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Репликация возобновляется после успешного создания группы отказа.

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

1. Остановите все задания репликации, выполняющиеся в базе данных, если таковые имеются.

2. Удалите метаданные подписки от издателя, выполнив следующий скрипт в базе данных издателя. Замените значения <name of publication> и <name of subscriber>.

   EXEC sp_dropsubscription @publication = '<name of publication>',
       @article = 'all',
       @subscriber = '<name of subscriber>'
   

3. Удалите метаданные подписки из аккаунта подписчика. Выполните следующий скрипт в базе данных подписки на SQL-управляемом экземпляре подписчика. Замените значение <full DNS of publisher>. Например, example.ac2d23028af5.database.windows.net:

   EXEC sp_subscription_cleanup
      @publisher = N'<full DNS of publisher>',
      @publisher_db = N'<publisher database>',
      @publication = N'<name of publication>';
   

4. Принудительно удалите все объекты репликации с публикующего сервера, выполнив следующий скрипт в базе данных издателя.

   EXEC sp_removedbreplication;
   

5. Принудительно удалить старого распространителя из оригинального первичного управляемого экземпляра SQL при возврате на старый первичный экземпляр, который ранее использовался с распространителем. Выполните следующий скрипт на базе данных master в прежнем управляемом экземпляре SQL распространителя.

   EXEC sp_dropdistributor 1, 1;
   

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

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

Устранение распространенных неполадок

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

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

Агент чтения журналов отключен

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

Время ожидания запроса агента чтения журналов

Иногда задание чтения журналов не может действительно эффективно выполняться из-за повторяющихся тайм-аутов запросов. Способ устранения таймаутов выполнения запросов — увеличить настройку времени ожидания запроса для задания агента чтения журналов базы данных.

Увеличение времени ожидания запроса для задания чтения журналов можно сделать с помощью SSMS. В обозревателе объектов в разделе Агент SQL Server найдите задание, которое вы хотите изменить. Сначала остановите его, а затем откройте его свойства. Найдите step 2 и измените его. Добавьте к значению команды -QueryTimeout <timeout_in_seconds>. Для значения времени ожидания запроса попробуйте 21600 или выше. Наконец, запустите задание снова.

Максимальный размер хранилища журналов составляет 2 ТБ

Если размер хранилища журналов транзакций достигает максимального предела, что составляет 2 ТБ, журнал физически не может увеличиться больше, чем это. В этом случае единственным доступным решением является пометка всех транзакций, которые необходимо реплицировать как обработанные, чтобы позволить усечение журнала транзакций. Это означает, что остальные транзакции в журнале не будут реплицироваться, и необходимо повторно инициализировать репликацию.

Чтобы выполнить смягчение последствий, сначала необходимо остановить агент чтения журналов на сервере распределения. Затем необходимо запустить хранимую процедуру sp_repldone с флагом reset, установленным на 1, в базе данных издателя, чтобы разрешить усечение журнала транзакций. Эта команда должна выглядеть следующим образом EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1. После этого необходимо повторно инициализировать репликацию.

Дальнейшие шаги

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

• Настройте репликацию между издателем управляемого экземпляра SQL и подписчиком управляемого экземпляра SQL.
• Настройте репликацию между издателем Управляемого экземпляра SQL, распространителем Управляемого экземпляра SQL и подписчиком SQL Server.
• Создание публикации.
• Создайте push-подписку, используя имя сервера в качестве подписчика (например, N'azuresqldbdns.database.windows.net), и укажите имя базы данных в Azure SQL Database в качестве целевой базы данных (например, Adventureworks).

Связанный контент

• Репликация с помощью SQL Managed Instance и группы аварийного переключения
• Репликация в Базу данных SQL
• Репликация с использованием Управляемого экземпляра Базы данных SQL
• Создание публикации
• Создание Push-подписки
• Типы репликации
• Мониторинг (репликация)
• Инициализация подписки