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

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

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

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

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

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

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

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

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

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

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

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

Это важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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