Настройка ссылки с помощью скриптов — Управляемый экземпляр SQL Azure

  • Статья

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

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

После создания ссылки вы можете выполнить отработку отказа в дополнительный реплика для миграции или аварийного восстановления.

Примечание.

  • Также можно настроить ссылку на SQL Server Management Studio (SSMS).
  • Настройка Управляемый экземпляр SQL Azure в качестве исходного основного в настоящее время находится в предварительной версии и поддерживается только с SQL Server 2022 CU10.

Обзор

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

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

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

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

Совет

  • Чтобы упростить использование скриптов T-SQL с правильными параметрами для вашей среды, настоятельно рекомендуется использовать мастер связи Управляемый экземпляр в SQL Server Management Studio (SSMS) для создания скрипта для создания ссылки. На странице "Сводка" окна ссылки "Создать Управляемый экземпляр" выберите "Скрипт" вместо "Готово".

Предварительные требования

Примечание.

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

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

В частности, необходимо принимать во внимание следующее:

  • Функция связи поддерживает одну базу данных для каждого канала. Чтобы реплика управлять несколькими базами данных в экземпляре, создайте ссылку для каждой отдельной базы данных. Например, чтобы реплицировать 10 баз данных в Управляемый экземпляр SQL, создайте 10 отдельных связей.
  • Параметры сортировки между SQL Server и Управляемым экземпляром SQL должны быть одинаковыми. Несоответствие параметров сортировки может привести к несоответствию регистра имен серверов и помешать успешному подключению SQL Server к Управляемому экземпляру SQL.
  • Ошибка 1475 на исходном первичном сервере SQL Server указывает, что необходимо запустить новую цепочку резервных копий, создав полную резервную копию без COPY ONLY параметра.

Разрешения

Для SQL Server у вас должны быть разрешения sysadmin .

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

Microsoft.Sql/ ресурс Необходимые разрешения
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /действие
Microsoft.Sql/managedInstances/databases /read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /read
Microsoft.Sql/managedInstances/hybridLink /read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

Терминология и соглашения об именовании

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

Терминология Description Порядок получения
Начальная первичная 1 SQL Server или Управляемый экземпляр SQL, где изначально создается ссылка для реплика подключения базы данных к вторичному реплика.
Первичная реплика SQL Server или Управляемый экземпляр SQL, на котором в настоящее время размещается база данных-источник.
Вторичная реплика SQL Server или Управляемый экземпляр SQL, получающий практически в реальном времени реплика данные из текущей основной реплика.
Имя SQL Server Короткое, одно слово SQL Server. Например: sqlserver1. Выполните SELECT @@SERVERNAME в T-SQL.
Полное доменное имя SQL Server Полное доменное имя (FQDN) sql Server. Например: sqlserver1.domain.com. Проверьте локальную конфигурацию сети (DNS) или имя сервера, если вы используете виртуальную машину Azure.
Имя Управляемого экземпляра SQL Короткое, одно слово Управляемый экземпляр SQL имя. Например: managedinstance1. См. имя управляемого экземпляра на портале Azure.
Полное доменное имя управляемого экземпляра SQL Полное доменное имя (FQDN) Управляемый экземпляр SQL. Например: managedinstance1.6d710bcf372b.database.windows.net. См. имя узла на странице обзора Управляемого экземпляра SQL на портале Azure.
Разрешаемое доменное имя DNS-имя, которое может быть разрешено в IP-адрес. Например, выполнение nslookup sqlserver1.domain.com должно возвращать IP-адрес, например 10.0.0.1. Выполните nslookup команду из командной строки.
IP-адрес SQL Server IP-адрес SQL Server. В случае нескольких IP-адресов в SQL Server выберите IP-адрес, доступный из Azure. Выполните ipconfig команду из командной строки ос узла под управлением SQL Server.

1 Настройка Управляемый экземпляр SQL Azure в качестве исходного основного в настоящее время находится в предварительной версии и поддерживается только с SQL Server 2022 CU10.

Настройка восстановления и резервного копирования базы данных

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

Выполните следующий код в SQL Server для всех баз данных, которые вы хотите реплика te. Замените <DatabaseName> фактическим именем базы данных.

-- Run on SQL Server
-- Set full recovery model for all databases you want to replicate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to replicate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Дополнительные сведения см. в статье "Создание полной резервной копии базы данных".

Примечание.

Связь поддерживает репликацию только пользовательских баз данных. Репликация системных баз данных не поддерживается. Чтобы реплика te объекты уровня экземпляра (хранящиеся в master базах данных или msdb в базах данных), рекомендуется выполнить скрипты T-SQL в целевом экземпляре.

Установка отношений доверия между экземплярами

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

Примечание.

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

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

Важно!

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

Ниже приведен обзор процесса защиты конечных точек базы данных зеркало для SQL Server и Управляемый экземпляр SQL.

  1. Создайте сертификат в SQL Server и получите соответствующий открытый ключ.
  2. Получите открытый ключ сертификата Управляемого экземпляра SQL.
  3. Обеспечьте обмен открытыми ключами между SQL Server и Управляемым экземпляром SQL.
  4. Импорт ключей доверенного корневого центра сертификации Azure в SQL Server

В следующих разделах подробно описаны эти действия.

Создание сертификата в SQL Server и импорт его открытого ключа в Управляемый экземпляр

Сначала создайте главный ключ базы данных в master базе данных, если он еще не присутствует. Вставьте пароль вместо следующего скрипта <strong_password> и сохраните его в конфиденциальном и безопасном месте. Запустите этот скрипт T-SQL в SQL Server:

-- Run on SQL Server
-- Create a master key encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

Затем создайте сертификат проверки подлинности в SQL Server. В следующем скрипте замените следующее:

  • @cert_expiry_date с требуемой датой окончания срока действия сертификата (дата будущего).

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

Важно!

Настоятельно рекомендуется использовать автоматически созданное имя сертификата из этого скрипта. При настройке собственного имени сертификата в SQL Server имя не должно содержать никаких \ символов.

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

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

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

В результатах запроса вы найдете сертификат и увидите, что он зашифрован с помощью главного ключа.

Теперь вы можете получить открытый ключ созданного сертификата в SQL Server:

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

Сохраните значения и SQLServerPublicKey из выходных SQLServerCertName данных, так как при импорте сертификата потребуется следующее действие.

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

Замените <SubscriptionID> идентификатором своей подписки Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Затем используйте команду New-AzSqlInstanceServerTrustCertificate PowerShell или az sql mi partner-cert, чтобы отправить открытый ключ сертификата проверки подлинности из SQL Server в Azure, например следующий пример PowerShell.

Заполните необходимые сведения о пользователе, скопируйте его, вставьте его, а затем запустите скрипт. Замена:

  • <SQLServerPublicKey> с общедоступной частью сертификата SQL Server в двоичном формате, который вы записали на предыдущем шаге. Это длинное строковое значение, начинающееся с 0x.
  • <SQLServerCertName> с именем сертификата SQL Server, записанным на предыдущем шаге.
  • <ManagedInstanceName> коротким именем управляемого экземпляра;
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded

Результатом этой операции является сводка отправленного сертификата SQL Server в Azure.

Если вам нужно просмотреть все сертификаты SQL Server, отправленные в управляемый экземпляр, используйте команду Get-AzSqlInstanceServerTrustCertificate PowerShell или az sql mi partner-cert list Azure CLI в Azure Cloud Shell. Чтобы удалить сертификат SQL Server, отправленный в управляемый экземпляр SQL, используйте команду Remove-AzSqlInstanceServerTrustCertificate PowerShell или az sql mi partner-cert delete Azure CLI в Azure Cloud Shell.

Получение открытого ключа сертификата из Управляемого экземпляра SQL и его импорт в SQL Server

Сертификат для защиты конечной точки ссылки автоматически создается на Управляемый экземпляр SQL Azure. Получите открытый ключ сертификата из Управляемый экземпляр SQL и импортируйте его в SQL Server с помощью команды Get-AzSqlInstanceEndpointCertificate PowerShell или az sql mi endpoint-cert, например следующую команду PowerShell.

Внимание

При использовании Azure CLI необходимо вручную добавить 0x в передней части выходных данных PublicKey при его использовании в последующих шагах. Например, PublicKey будет выглядеть как "0x3082033E30...".

Запустите указанный ниже скрипт. Замена:

  • <SubscriptionID> идентификатором своей подписки Azure;
  • <ManagedInstanceName> коротким именем управляемого экземпляра;
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string

Скопируйте все выходные данные PublicKey (начинается с 0x) по мере его использования на следующем шаге.

Кроме того, при возникновении проблем при копировании общедоступного ключа можно также запустить команду EXEC sp_get_endpoint_certificate 4 T-SQL в управляемом экземпляре, чтобы получить его открытый ключ для конечной точки ссылки.

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

  • <ManagedInstanceFQDN> с полным доменным именем управляемого экземпляра.
  • <PublicKey> значение PublicKey, полученное на предыдущем шаге (начиная с Azure Cloud Shell 0x). Вам не нужно использовать кавычки.

Важно!

Имя сертификата должно быть полным доменным именем Управляемый экземпляр SQL и не должно быть изменено. Ссылка не будет работает, если используется пользовательское имя.

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey>

Импорт ключей доверенного корневого центра сертификации Azure в SQL Server

Импорт ключей открытых корневых сертификатов центра сертификации Майкрософт и DigiCert в SQL Server требуется для того, чтобы SQL Server доверял сертификатам, выданным Azure для database.windows.net доменов.

Внимание

Убедитесь, что publicKey начинается с 0x. Возможно, вам потребуется вручную добавить его в начало PublicKey, если он еще не существует.

Сначала импортируйте сертификат корневого центра Microsoft PKI в SQL Server:

-- Run on SQL Server
-- Import Microsoft PKI root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'MicrosoftPKI')
BEGIN
    PRINT 'Creating MicrosoftPKI certificate.'
    CREATE CERTIFICATE [MicrosoftPKI] FROM BINARY = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3

    --Trust certificates issued by Microsoft PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('MicrosoftPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate MicrosoftPKI already exsits.'
GO

Затем импортируйте сертификат корневого центра DigiCert PKI в SQL Server:

-- Run on SQL Server
-- Import DigiCert PKI root-authority certificate trusted by Azure to SQL Server, if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'DigiCertPKI')
BEGIN
    PRINT 'Creating DigiCertPKI certificate.'
    CREATE CERTIFICATE [DigiCertPKI] FROM BINARY = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D0

    --Trust certificates issued by DigiCert PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('DigiCertPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate DigiCertPKI already exsits.'
GO

Наконец, проверьте все созданные сертификаты с помощью следующего динамического административного представления.

-- Run on SQL Server
SELECT * FROM sys.certificates

Защита конечной точки зеркало базы данных

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

Создание и защита конечной точки зеркало базы данных в SQL Server

Чтобы убедиться, что конечная точка зеркального отображения базы данных не создана, используйте следующий скрипт.

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

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

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

Сохраните SQLServerCertName из выходных данных, так как вам потребуется на следующем шаге.

Используйте следующий скрипт, чтобы создать новую конечную точку базы данных зеркало на порте 5022 и защитить конечную точку с помощью сертификата SQL Server. Замена:

  • <SQL_SERVER_CERTIFICATE> с именем SQLServerCertName, полученным на предыдущем шаге.
-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

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

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

Успешно созданная конечная точка state_desc столбца должна иметь состояние STARTED.

Новая конечная точка зеркального отображения была создана с проверкой подлинности на основе сертификата, и для нее было включено шифрование AES.

Изменение существующей конечной точки

Примечание.

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

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

  • Тип — DATABASE_MIRRORING
  • Проверка подлинности подключения — CERTIFICATE.
  • Должно быть включено шифрование.
  • Алгоритм шифрования — AES.

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

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Если выходные данные показывают, что существующая конечная точка DATABASE_MIRRORINGconnection_auth_desc не представляет CERTIFICATE или encryption_algorthm_desc не представляет AES, конечная точка должна быть изменена в соответствии с требованиями.

В SQL Server одна конечная точка зеркального отображения базы данных используется как для групп доступности, так и для распределенных групп доступности. Если ваша конечная точка connection_auth_desc представляет NTLM (проверка подлинности Windows) или KERBEROS, и вам требуется проверка подлинности Windows для существующей группы доступности, можно изменить конечную точку для использования нескольких методов проверки подлинности, переключив параметр проверки подлинности на NEGOTIATE CERTIFICATE. Это изменение позволяет существующей группе доступности использовать проверка подлинности Windows при использовании проверки подлинности сертификата для Управляемый экземпляр SQL.

Аналогично: если шифрование не включает AES и требуется шифрование RC4, можно изменить конечную точку для использования обоих алгоритмов. Дополнительные сведения о возможных вариантах изменения конечных точек см. на странице документации по sys.database_mirroring_endpoints.

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

  • <YourExistingEndpointName> именем существующей конечной точки.
  • <SQLServerCertName> с именем созданного сертификата SQL Server (полученного в одном из предыдущих шагов выше).

В зависимости от конкретной конфигурации вам может потребоваться дополнительно настроить скрипт. Вы также можете использовать SELECT * FROM sys.certificates для получения имени созданного сертификата в SQL Server.

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

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

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

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

Создание группы доступности в SQL Server

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

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

Если SQL Server является основным, создайте группу доступности со следующими параметрами для ссылки:

  • Начальное имя сервера-источника
  • Имя базы данных
  • Режим отработки отказа MANUAL
  • Режим заполнения AUTOMATIC

Сначала узнайте имя своего экземпляра SQL Server, выполнив следующую инструкцию T-SQL.

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName

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

  • <AGName> именем своей группы доступности. Для функции связи Управляемого экземпляра требуется по одной базе данных на группу доступности. Для нескольких баз данных потребуется создать несколько групп доступности. Рекомендуется назначить каждой группе доступности имя, которое отражает соответствующую базу данных, например AG_<db_name>.
  • <DatabaseName> именем базы данных, которую вы хотите реплицировать;
  • <SQLServerName> с именем экземпляра SQL Server, полученного на предыдущем шаге.
  • <SQLServerIP> IP-адресом SQL Server. В качестве альтернативы можно использовать разрешаемое имя главного компьютера SQL Server, но необходимо убедиться, что это имя разрешается из виртуальной сети Управляемого экземпляра SQL.
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

Важно!

Для SQL Server 2016 удалите WITH (CLUSTER_TYPE = NONE) из приведенной выше инструкции T-SQL. Оставьте значение as-is для всех последующих версий SQL Server.

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

Замените следующие значения, а затем запустите скрипт T-SQL для создания распределенной группы доступности.

  • <DAGName> именем вашей распределенной группы доступности. Так как можно настроить несколько ссылок для одной и той же базы данных, создав распределенную группу доступности для каждой ссылки, рассмотрите возможность именования каждой распределенной группы доступности соответствующим образом , напримерDAG1_<db_name>. DAG2_<db_name>
  • <AGName> именем группы доступности, созданной на предыдущем шаге;
  • <SQLServerIP> IP-адресом SQL Server, полученным на предыдущем шаге. Можно использовать разрешаемое имя компьютера узла SQL Server в качестве альтернативы, но убедитесь, что имя разрешается из виртуальной сети Управляемый экземпляр SQL (для которой требуется настроить настраиваемую службу Azure DNS для подсети управляемого экземпляра).
  • <ManagedInstanceName> коротким именем управляемого экземпляра;
  • <ManagedInstanceFQDN> полным доменным именем управляемого экземпляра.
-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGName>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<ManagedInstanceName>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

Проверка групп доступности

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

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

Кроме того, вы можете использовать обозреватель объектов SSMS для поиска групп доступности и распределенных групп доступности. Разверните папки Высокий уровень доступности Always On и Группы доступности.

Наконец, можно создать ссылку. Команды отличаются в зависимости от того, какой экземпляр является начальным первичным. Используйте команду New-AzSqlInstanceLink PowerShell или az sql mi link, чтобы создать ссылку, например пример PowerShell в этом разделе. Создание ссылки из основной Управляемый экземпляр SQL в настоящее время не поддерживается в Azure CLI.

Если вам нужно просмотреть все ссылки в управляемом экземпляре, используйте команду Get-AzSqlInstanceLink PowerShell или az sql mi link, чтобы показать команду Azure CLI в Azure Cloud Shell.

Чтобы упростить процесс, войдите в портал Azure и запустите следующий сценарий из Azure Cloud Shell. Замена:

  • <ManagedInstanceName> коротким именем управляемого экземпляра;
  • <AGName> именем группы доступности, созданной в SQL Server;
  • <DAGName> именем распределенной группы доступности, созданной в SQL Server.
  • <DatabaseName> именем базы данных, реплицированной в SQL Server.
  • <SQLServerIP> с IP-адресом SQL Server. Предоставленный IP-адрес должен быть доступен управляемым экземпляром.
#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# Enter the availability group name that was created on SQL Server
$AGName = "<AGName>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":5022"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGName -SecondaryAvailabilityGroupName $ManagedInstanceName |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

Результатом этой операции является метка времени успешного выполнения запроса на создание ссылки.

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

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

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

Важно!

  • Функция связи не будет работать, если между SQL Server и Управляемым экземпляром SQL нет сетевого подключения. Чтобы устранить неполадки с сетевым подключением, выполните действия, описанные в разделе "Тестирование сетевого подключения".
  • Регулярно создавайте резервные копии файла журнала в SQL Server. Если используемое пространство журнала достигает 100 %, репликация в Управляемый экземпляр SQL будет остановлена, пока использование пространства не будет снижено. Настоятельно рекомендуется автоматизировать резервное копирование журналов с помощью ежедневного задания. Дополнительные сведения см. в разделе Резервное копирование файлов журналов в SQL Server.

Остановка рабочей нагрузки

Чтобы выполнить отработку отказа базы данных на вторичную реплика, сначала остановите все рабочие нагрузки приложений на основном сервере во время обслуживания. Это позволяет базе данных реплика перехватывать вторичные o, которые можно перенести или выполнить отработку отказа в Azure без потери данных. База данных-источник является частью группы доступности Always On, но для нее нельзя задать режим только для чтения. Необходимо убедиться, что приложения не фиксируют транзакции в основном реплика до отработки отказа.

Переключение режима репликации

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

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

Переключение режима репликации (Управляемый экземпляр SQL)

Используйте Azure PowerShell или Azure CLI для переключения режима реплика на Управляемый экземпляр SQL.

Сначала убедитесь, что вы вошли в Azure и выбрали подписку, в которой размещен управляемый экземпляр, с помощью команды Select-AzSubscription PowerShell или az account set Azure CLI. Выбор правильной подписки особенно важен, если у вас несколько подписок Azure на вашей учетной записи.

В следующем примере PowerShell замените <SubscriptionID> идентификатор подписки Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Убедитесь, что вы знаете имя ссылки, на который вы хотите выполнить отработку отказа. Вы можете использовать команду Get-AzSqlInstanceLink PowerShell или az sql mi link list Azure CLI.

Используйте следующий скрипт PowerShell для перечисления всех активных ссылок на Управляемый экземпляр SQL. Замените <ManagedInstanceName> коротким именем управляемого экземпляра.

# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO LIST ALL LINKS ON MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# List all links on the specified managed instance
Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName

В выходных данных предыдущего скрипта запишите Name свойство ссылки, которую вы хотите выполнить отработку отказа.

Затем переключите режим реплика tion из асинхронного режима, чтобы синхронизировать Управляемый экземпляр SQL для определенной ссылки с помощью команды Update-AzSqlInstanceLink PowerShell или az sql mi link update Azure CLI.

В следующем примере PowerShell замените следующее:

  • <ManagedInstanceName> коротким именем управляемого экземпляра;
  • <DAGName> с именем ссылки, обнаруженной на предыдущем шаге ( Name свойство из предыдущего шага).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO SWITCH LINK REPLICATION MODE (ASYNC\SYNC)
# ===== Enter user variables here ====

# Enter the link name 
$LinkName = "<DAGName>"  

# Enter your managed instance name – for example, "sqlmi1" 
$ManagedInstanceName = "<ManagedInstanceName>" 

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Update replication mode of the specified link
Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName |
-Name $LinkName -ReplicationMode "Sync"

Предыдущая команда указывает на успех, отображая сводку операции с свойством ReplicationMode , показанным как Sync.

Если необходимо отменить изменения операцию, выполните предыдущий сценарий, чтобы переключить режим реплика tion, но заменить Sync строку в поле -ReplicationModeAsync.

Переключение режима репликации (SQL Server)

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

  • <DAGName> с именем распределенной группы доступности (используется для создания ссылки).
  • <AGName> с именем группы доступности, созданной на SQL Server (используется для создания ссылки).
  • <ManagedInstanceName> именем управляемого экземпляра;
-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

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

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

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

Проверка значений номеров LSN как в SQL Server, так и в Управляемом экземпляре SQL

Чтобы завершить отработку отказа или миграцию, убедитесь, что реплика tion завершена. Для этого убедитесь, что номера последовательности журналов (LSN) в записях журнала для SQL Server и Управляемый экземпляр SQL одинаковы.

Первоначально ожидается, что LSN на первичном объекте будет выше, чем LSN на вторичной. Задержка в сети может привести к тому, что реплика задержка несколько отстает от основного. Так как рабочая нагрузка остановлена на первичном сервере, следует ожидать, что LSN будет соответствовать и перестать меняться через некоторое время.

Используйте следующий запрос T-SQL в SQL Server, чтобы считать номер LSN последнего записанного журнала транзакций. Замена:

  • <DatabaseName> с именем базы данных и найдите последний защищенный номер LSN.
-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

Используйте следующий запрос T-SQL в Управляемом экземпляре SQL, чтобы считать последний зафиксированный номер LSN для базы данных. Замените <DatabaseName> именем базы данных.

Этот запрос работает с Управляемый экземпляр SQL общего назначения. Для критически важный для бизнеса Управляемый экземпляр SQL раскомментируйте and drs.is_primary_replica = 1 его в конце скрипта. На уровне служб критически важный для бизнеса этот фильтр гарантирует, что сведения считываются только из основного реплика.

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

Кроме того, можно использовать команду Get-AzSqlInstanceLink PowerShell или az sql mi link, чтобы получить LastHardenedLsn свойство для ссылки на Управляемый экземпляр SQL, чтобы предоставить те же сведения, что и предыдущий запрос T-SQL.

Важно!

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

Отработка отказа базы данных

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

Чтобы разорвать ссылку и остановить реплика tion при отработке отказа или переносе базы данных независимо от версии SQL Server, используйте команду Remove-AzSqlInstanceLink PowerShell или az sql mi link delete Azure CLI.

Внимание

  • Прежде чем выполнить отработку отказа, остановите рабочую нагрузку в исходной базе данных, чтобы позволить реплика базе данных полностью выполнить перехват и отработку отказа без потери данных. Если вы выполняете принудительной отработки отказа или если вы прерываете ссылку до сопоставления LSN, может потерять данные.
  • Отработка отказа базы данных в SQL Server 2019 и более ранних версиях прерывает работу и удаляет связь между двумя реплика. Не удается вернуться к исходному первичному источнику.
  • Отработка отказа базы данных при сохранении ссылки на SQL Server 2022 в настоящее время находится в предварительной версии.

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

  • <ManagedInstanceName> именем управляемого экземпляра;
  • <DAGName> с именем отработки отказа ссылки (выходные данные свойства Name из Get-AzSqlInstanceLink команды, выполненной ранее выше).
# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

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

Важно!

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

Очистка групп доступности

Так как отработка отказа с помощью SQL Server 2022 не нарушает эту ссылку, вы можете оставить ссылку и группы доступности.

Если вы решили разорвать ссылку или выполнить отработку отказа с помощью SQL Server 2019 и более ранних версий, необходимо удалить распределенную группу доступности, чтобы удалить метаданные ссылки из SQL Server. Однако вы можете сохранить группу доступности в SQL Server.

Чтобы очистить ресурсы группы доступности, замените следующие значения и запустите пример кода: в следующем коде замените:

  • <DAGName> с именем распределенной группы доступности в SQL Server (используется для создания ссылки).
  • <AGName> с именем группы доступности на SQL Server (используется для создания ссылки).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

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

В этом разделе приводятся рекомендации по устранению проблем с настройкой и использованием ссылки.

ошибки

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

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

Несогласованное состояние после принудительной отработки отказа

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

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

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