рекомендации по связыванию Управляемый экземпляр — Управляемый экземпляр SQL Azure

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

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

Регулярное создание резервных копий журналов

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

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

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

Для резервного копирования файла журнала можно использовать скрипт Transact-SQL (T-SQL), например пример, приведенный в этом разделе. Замените заполнители в примере скрипта именем своей базы данных, именем и путем для файла резервной копии и описанием.

Чтобы создать резервную копию журнала транзакций, используйте следующий пример скрипта Transact-SQL (T-SQL) в SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Используйте следующую команду Transact-SQL (T-SQL), чтобы проверить пространство журнала, используемое базой данных в SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE); 

Выходные данные запроса выглядят следующим образом для примера базы данных tpcc:

В этом примере база данных использовала 76 % доступного журнала, при этом абсолютный размер файла журнала составляет приблизительно 27 ГБ (27971 МБ). Пороговые значения для действия зависят от рабочей нагрузки. В предыдущем примере размер журнала транзакций и процент использования журнала обычно указывает на то, что необходимо создать резервную копию журнала транзакций, чтобы усечь файл журнала и освободить место, а также создать более частые резервные копии журналов. Это также может указывать на то, что сокращение журнала транзакций блокируется из-за открытых транзакций. Дополнительные сведения об устранении неполадок полного журнала транзакций в SQL Server см. в разделе Устранение неполадок полного журнала транзакций (ошибка SQL Server 9002). Дополнительные сведения об устранении неполадок журнала транзакций в Управляемый экземпляр SQL Azure см. Устранение неполадок журнала транзакций в Управляемый экземпляр SQL Azure.

Сравнение возможностей производительности между репликами

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

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

• Значение redo_queue_size в динамическом управляющем представлении sys.dm_hadr_database_replica_states на первичной реплике.
• Значение InstanceRedoLagReplicationSeconds в Get-AzSqlInstanceLink на первичной реплике.

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

Мониторинг задержки репликации

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

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

Используйте следующий запрос T-SQL в SQL Server и Управляемый экземпляр SQL для отслеживания задержки репликации между репликами:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Поворот сертификата

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

SQL Server

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

Используйте следующую команду Transact-SQL (T-SQL), чтобы проверить дату окончания срока действия текущего сертификата:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK' 

Если срок действия сертификата истек или истек, создайте новый сертификат и измените существующую конечную точку, чтобы заменить текущий сертификат.

После настройки конечной точки для использования нового сертификата можно удалить истекший срок действия сертификата.

Управляемый экземпляр SQL

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

Проверка цепочки сертификатов в SQL Server

Проблемы с цепочкой сертификатов могут ухудшать связь. Чтобы предотвратить эту проблему, регулярно проверьте цепочку сертификатов на SQL Server.

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

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

Сначала определите certificate_id импортированного сертификата конечной точки MI, заменив значение <ManagedInstanceFQDN>, а затем выполните следующий запрос на SQL Server:

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

Затем проверьте сертификат, заменив значение <certificate_id> из результата предыдущего запроса, а затем выполните следующий запрос на SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

Ответ Commands completed successfully. Completion time: ... указывает, что сертификат конечной точки MI успешно проверен.

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

Добавление флагов трассировки запуска

В SQL Server есть два флага трассировки (-T1800 и -T9567), которые при добавлении в качестве параметров запуска могут оптимизировать производительность репликации данных по ссылке. Дополнительные сведения см. в разделе Включение флагов трассировки запуска.

Используйте синхронную фиксацию с осторожностью

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

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

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

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

Чтобы использовать ссылку, выполните следующие действия.

• Настройте среду для подключения к Управляемый экземпляр.
• Настройка связи между SQL Server и SQL Managed Instance с помощью SSMS
• Настройте связь между SQL Server и управляемым экземпляром SQL с помощью скриптов
• Переключение на резервное соединение
• Выполните миграцию по ссылке
• Устранение неполадок со ссылкой

Дополнительные сведения о ссылке:

• Обзор связывания с Управляемый экземпляр
• Катастрофическое восстановление с использованием связи Управляемый экземпляр
• Рекомендации по поддержанию ссылки

Для других сценариев репликации и миграции можно рассмотреть следующие варианты:

• Транзакционная репликация с Управляемый экземпляр SQL
• Служба воспроизведения логов (LRS)