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

Применимо к:Управляемый экземпляр SQL Azure

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

Обзор

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

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

Примечание.

Чтобы использовать все функции Управляемый экземпляр SQL Azure, необходимо использовать последние версии SQL Server Management Studio (SSMS) и SQL Server Data Tools (SSDT).

Компоненты

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

Роль	База данных SQL Azure	Управляемый экземпляр SQL Azure
Издатель	Нет	Да
Распространитель	Нет	Да
Подписчик по запросу	Нет	Да
Принудительный подписчик	Да	Да

Издатель публикует изменения, внесенные в некоторые таблицы (статьи), отправляя обновления распространителю. Издатель может быть управляемым экземпляром 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)

Примечание.

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

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

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

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

Репликация	База данных SQL Azure	Управляемый экземпляр SQL Azure
Стандартная транзакционная	Да (только в качестве подписчика)	Да
Моментальный снимок	Да (только в качестве подписчика)	Да
Репликация слиянием	Нет	Нет
Одноранговая репликация	Нет	Нет
Двунаправленная репликация	Нет	Да
Обновляемых подписок	Нет	No

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

Матрица поддержки репликации транзакций для Управляемого экземпляра SQL Azure аналогична матрице для SQL Server.

Издатель	Распространитель	Подписчик
SQL Server 2022	SQL Server 2022	SQL Server 2022 SQL Server 2019 SQL Server 2017
SQL Server 2019	SQL Server 2022 SQL Server 2019	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016
SQL Server 2017	SQL Server 2022 SQL Server 2019 SQL Server 2017	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014
SQL Server 2016	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016	SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012
SQL Server 2014	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014	SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008
SQL Server 2012	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012	SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008
SQL Server 2008 R2 SQL Server 2008	SQL Server 2022 SQL Server 2019 SQL Server 2017 SQL Server 2016 SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008	SQL Server 2014 SQL Server 2012 SQL Server 2008 R2 SQL Server 2008

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

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

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

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

Категория	Синхронизация данных	Репликация транзакций
Преимущества	— Поддержка режима "активный — активный" — Двусторонняя передача данных между локальной базой данных и службой "База данных SQL Azure"	— Низкая задержка — Согласованность транзакций — Повторное использование существующей топологии после миграции
Недостатки	— Отсутствует согласованность транзакций — Большее влияние на производительность	— Не поддерживается публикация из Базы данных SQL Azure — Дорогое обслуживание

Распространенные способы конфигурирования

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

Издатель с локальным распространителем в Управляемом экземпляре 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.
• Разместите издателя и распространителя в облаке или локальной среде.
• Настройте пиринг виртуальной частной сети между виртуальными сетями участников репликации, если виртуальные сети различаются.

Примечание.

При подключении к файлу службы хранилища Azure может возникнуть ошибка 53, если исходящий порт 445 группы безопасности сети заблокирован, когда распространитель является базой данных Управляемого экземпляра, а подписчик находится в локальной среде. Чтобы устранить эту проблему , обновите группу NSG виртуальной сети.

Ограничения

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

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

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

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

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 секунд (или более), поэтому даже если это не непрерывно, вы по-прежнему можете иметь распространитель, который вводит задержку только несколько секунд. Если требуется большое количество распространителей, рекомендуется использовать запланированную и не непрерывную конфигурацию.

Группы автоматической отработки отказа

Использование транзакционных реплика с экземплярами, которые находятся в группе отработки отказа, поддерживаются. Однако при настройке реплика tion перед добавлением управляемого экземпляра SQL в группу отработки отказа реплика приостанавливается при создании группы отработки отказа, а монитор реплика tion отображает состояние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 зависят от типа отработки отказа, которая произошла:

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

Следующие шаги

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

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

См. также

• Репликация
• Репликация в Базу данных SQL
• Репликация с использованием Управляемого экземпляра Базы данных SQL
• Create a Publication
• Create a Push Subscription
• Типы репликации
• Мониторинг (репликация)
• Инициализация подписки