Репликация транзакций с Управляемый экземпляр SQL Azure

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

Репликация транзакций — это функция Управляемый экземпляр SQL Azure и SQL Server, которая позволяет реплицировать данные из таблицы в Управляемый экземпляр SQL Azure или экземпляре 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 могут быть принудительной и вытягиваемой подпиской, хотя подписка на вытягивание не поддерживается, если распространитель является управляемым экземпляром SQL Azure, и подписчик не является. База данных SQL Azure может быть только принудительным подписчиком.

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

• SQL Server 2016 и более поздних версий
• SQL Server 2014 RTM CU10 (12.0.4427.24) или с пакетом обновления 1 (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)

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

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

Supportability matrix

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

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

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

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

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

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

Common configurations

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

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

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

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

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

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

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

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

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

Requirements

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

Security

Поддержка TLS 1.3

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

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

• Distribution agent
• Агент чтения журналов
• Snapshot agent

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

Выполните вход на странице replAgentUser.

Для репликации транзакций управляемый экземпляр SQL имеет предварительно созданные имена входа с именем replAgentUser. Это имя входа является членом sysadmin роли сервера и используется агентами репликации, которые должны подключаться к управляемому экземпляру SQL, участвующим в настройке репликации транзакций.

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

Limitations

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

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

Управляемый экземпляр SQL Azure использует пользователь, настроенный служба хранилища Azure account для файлов моментальных снимков, используемых для репликации транзакций. В отличие от SQL Server в локальной среде, Управляемый экземпляр SQL Azure не удаляет файлы моментальных снимков из учетной записи служба хранилища Azure. После того как файлы больше не нужны, их следует удалить. Это можно сделать с помощью интерфейса служба хранилища Azure в портал Azure, служба хранилища Microsoft Azure 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 на Управляемый экземпляр SQL Azure. Чтобы иметь больше агентов распространителя, которые они должны работать по запросу или с определенным расписанием. Расписание можно определить с ежедневной частотой и вхождением каждые 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. После этого необходимо повторно инициализировать репликацию.

Next steps

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

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

Related content

• Репликация
• Репликация в Базу данных SQL
• Репликация с использованием Управляемого экземпляра Базы данных SQL
• Создание публикации
• Создание Push-подписки
• Типы репликации
• Monitoring (Replication)
• Инициализация подписки