Configurare il collegamento con gli script - Istanza gestita di SQL di Azure

Si applica a:Istanza gestita di SQL di Azure

Questo articolo illustra come configurare un collegamento tra SQL Server e Istanza gestita di SQL di Azure con script Transact-SQL e PowerShell o dell'interfaccia della riga di comando di Azure. Con il collegamento, i database del database primario iniziale vengono replicati nella replica secondaria quasi in tempo reale.

Dopo aver creato il collegamento, è possibile eseguire il failover nella replica secondaria allo scopo della migrazione o del ripristino di emergenza.

Nota

Panoramica

Usare la funzionalità di collegamento per replicare i database dal database primario iniziale alla replica secondaria. Per SQL Server 2022, il database primario iniziale può essere SQL Server o Istanza gestita di SQL di Azure. Per SQL Server 2019 e versioni precedenti, il database primario iniziale deve essere SQL Server. Dopo aver configurato il collegamento, i database dal database primario iniziale vengono replicati nella replica secondaria.

È possibile scegliere di lasciare il collegamento sul posto per la replica continua dei dati in un ambiente ibrido tra la replica primaria e secondaria oppure è possibile eseguire il failover del database nella replica secondaria, eseguire la migrazione ad Azure o per il ripristino di emergenza. Per SQL Server 2019 e versioni precedenti, il failover a Istanza gestita di SQL di Azure interrompe il collegamento e il failback non è supportato. Con SQL Server 2022 è possibile mantenere il collegamento e il failback tra le due repliche. Questa funzionalità è attualmente in anteprima.

Se si prevede di usare l'istanza gestita secondaria solo per il ripristino di emergenza, è possibile risparmiare sui costi di licenza attivando il vantaggio di failover ibrido.

Usare le istruzioni in questo articolo per configurare manualmente il collegamento tra SQL Server e Istanza gestita di SQL di Azure. Dopo aver creato il collegamento, il database di origine ottiene una copia di sola lettura nella replica secondaria di destinazione.

Suggerimento

  • Per semplificare l'uso degli script T-SQL con i parametri corretti per l'ambiente, è consigliabile usare la procedura guidata Istanza gestita collegamento guidato in SQL Server Management Studio (SSMS) per generare uno script per creare il collegamento. Nella pagina Riepilogo della finestra di collegamento Nuovo Istanza gestita selezionare Script anziché Fine.

Prerequisiti

Nota

Alcune funzionalità del collegamento sono disponibili a livello generale, mentre alcune sono attualmente in anteprima. Per altre informazioni, vedere Supporto delle versioni.

Per replicare i database, sono necessari i prerequisiti seguenti:

Tenere presente quanto segue:

  • La funzionalità di collegamento supporta un database per ogni collegamento. Per replicare più database in un'istanza di , creare un collegamento per ogni singolo database. Ad esempio, per replicare 10 database in Istanza gestita di SQL, creare 10 singoli collegamenti.
  • Le regole di confronto tra SQL Server e Istanza gestita di SQL devono essere uguali. Una mancata corrispondenza nelle regole di confronto potrebbe causare una mancata corrispondenza nelle maiuscole e minuscole dei nomi del server e impedire una connessione corretta da SQL Server a Istanza gestita di SQL.
  • L'errore 1475 nella replica primaria iniziale di SQL Server indica che è necessario avviare una nuova catena di backup creando un backup completo senza l'opzione COPY ONLY .

Autorizzazioni

Per SQL Server è necessario disporre delle autorizzazioni sysadmin .

Per Istanza gestita di SQL di Azure, è necessario essere membri del collaboratore Istanza gestita di SQL oppure disporre delle autorizzazioni personalizzate seguenti:

Risorsa Microsoft.Sql/ Autorizzazioni necessarie
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /azione
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

Terminologia e convenzioni di denominazione

Quando si eseguono script da questa guida utente, è importante non sbagliare SQL Server e Istanza gestita di SQL nomi per i nomi di dominio completi (FQDN). Nella tabella seguente vengono illustrati i vari nomi che rappresentano esattamente e come ottenere i relativi valori:

Terminologia Descrizione Come scoprire
Primo primario 1 SQL Server o Istanza gestita di SQL in cui inizialmente si crea il collegamento per replicare il database nella replica secondaria.
Replica primaria SQL Server o Istanza gestita di SQL che attualmente ospita il database primario.
Replica secondaria SQL Server o Istanza gestita di SQL che riceve dati replicati quasi in tempo reale dalla replica primaria corrente.
Nome SQL Server Nome breve di SQL Server a parola singola. Ad esempio: sqlserver1. Eseguire SELECT @@SERVERNAME da T-SQL.
SQL Server FQDN Nome di dominio completo (FQDN) di SQL Server. Ad esempio: sqlserver1.domain.com. Vedere la configurazione di rete (DNS) in locale o il nome del server se si usa una macchina virtuale (VM) di Azure.
SQL Managed Instance name (Nome dell'istanza gestita di SQL) Nome breve Istanza gestita di SQL parola singola. Ad esempio: managedinstance1. Vedere il nome dell'istanza gestita nel portale di Azure.
Istanza gestita di SQL FQDN Nome di dominio completo (FQDN) del Istanza gestita di SQL. Ad esempio: managedinstance1.6d710bcf372b.database.windows.net. Vedere il nome host nella pagina di panoramica Istanza gestita di SQL nel portale di Azure.
Nome di dominio risolvibile Nome DNS che può essere risolto in un indirizzo IP. Ad esempio, l'esecuzione nslookup sqlserver1.domain.com deve restituire un indirizzo IP, ad esempio 10.0.0.1. Eseguire nslookup il comando dal prompt dei comandi.
SQL Server IP Indirizzo IP di SQL Server. In caso di più indirizzi IP in SQL Server, scegliere l'indirizzo IP accessibile da Azure. Eseguire ipconfig il comando dal prompt dei comandi del sistema operativo host che esegue SQL Server.

1 La configurazione di Istanza gestita di SQL di Azure come primario iniziale è attualmente in anteprima e supportata solo a partire da SQL Server 2022 CU10.

Configurare il ripristino e il backup del database

Se SQL Server è il database primario iniziale, i database che verranno replicati tramite il collegamento devono trovarsi nel modello di recupero con registrazione completa e disporre di almeno un backup. Poiché Istanza gestita di SQL di Azure esegue automaticamente i backup, ignorare questo passaggio se Istanza gestita di SQL è il database primario iniziale. primaria

Eseguire il codice seguente in SQL Server per tutti i database da replicare. Sostituire <DatabaseName> con il nome effettivo del database.

-- 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

Per altre informazioni, vedere Creare un backup completo del database.

Nota

Il collegamento supporta solo la replica dei database utente. La replica dei database di sistema non è supportata. Per replicare gli oggetti a livello di istanza (archiviati in master o msdb database), è consigliabile crearne uno script e eseguirne lo script T-SQL nell'istanza di destinazione.

Stabilire un trust tra istanze

Prima di tutto, è necessario stabilire un trust tra le due istanze e proteggere gli endpoint usati per comunicare e crittografare i dati in rete. I gruppi di disponibilità distribuiti usano l'endpoint del mirroring del database del gruppo di disponibilità esistente, anziché avere il proprio endpoint dedicato. Di conseguenza, la sicurezza e l'attendibilità devono essere configurate tra le due istanze tramite l'endpoint del mirroring del database del gruppo di disponibilità.

Nota

Il collegamento si basa sulla tecnologia del gruppo di disponibilità Always On. L'endpoint del mirroring del database è un endpoint speciale usato esclusivamente dai gruppi di disponibilità per ricevere connessioni da altre istanze. Il termine endpoint del mirroring del database non deve essere errato con la funzionalità di mirroring del database SQL Server legacy.

L'attendibilità basata su certificati è l'unico modo supportato per proteggere gli endpoint del mirroring del database per SQL Server e Istanza gestita di SQL. Se si dispone di gruppi di disponibilità esistenti che usano autenticazione di Windows, è necessario aggiungere un trust basato su certificato all'endpoint di mirroring esistente come opzione di autenticazione secondaria. A tale scopo, è possibile usare l'istruzione ALTER ENDPOINT , come illustrato più avanti in questo articolo.

Importante

I certificati vengono generati con una data e un'ora di scadenza. Devono essere rinnovati e ruotati prima della scadenza.

Di seguito è riportata una panoramica del processo per proteggere gli endpoint del mirroring del database per SQL Server e Istanza gestita di SQL:

  1. Generare un certificato in SQL Server e ottenere la relativa chiave pubblica.
  2. Ottenere una chiave pubblica del certificato Istanza gestita di SQL.
  3. Scambiare le chiavi pubbliche tra SQL Server e Istanza gestita di SQL.
  4. Importare le chiavi dell'autorità di certificazione radice attendibile di Azure in SQL Server

Le sezioni seguenti descrivono questi passaggi in dettaglio.

Creare un certificato in SQL Server e importarne la chiave pubblica in Istanza gestita di SQL

Creare prima di tutto la chiave master del master database nel database, se non è già presente. Inserire la password al posto dello <strong_password> script seguente e mantenerla in un luogo riservato e sicuro. Eseguire questo script T-SQL in 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

Generare quindi un certificato di autenticazione in SQL Server. Nello script seguente sostituire:

  • @cert_expiry_date con la data di scadenza del certificato desiderata (data futura).

Registrare questa data e impostare un promemoria per ruotare (aggiornare) il certificato di SQL Server prima della data di scadenza per garantire il funzionamento continuo del collegamento.

Importante

È consigliabile usare il nome del certificato generato automaticamente da questo script. Durante la personalizzazione del proprio nome di certificato in SQL Server è consentito, il nome non deve contenere caratteri \ .

-- 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

Usare quindi la query T-SQL seguente in SQL Server per verificare che il certificato sia stato creato:

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

Nei risultati della query si noterà che il certificato è stato crittografato con la chiave master.

A questo punto, è possibile ottenere la chiave pubblica del certificato generato in 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;

Salvare i valori di SQLServerCertName e SQLServerPublicKey dall'output, perché sarà necessario per il passaggio successivo quando si importa il certificato.

Assicurarsi prima di tutto di aver eseguito l'accesso ad Azure e di aver selezionato la sottoscrizione in cui è ospitata l'istanza gestita. La selezione della sottoscrizione appropriata è particolarmente importante se si dispone di più sottoscrizioni di Azure nell'account.

Sostituire <SubscriptionID> con l'ID della sottoscrizione di 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

Usare quindi il comando New-AzSqlInstanceServerTrustCertificate powerShell o az sql mi partner-cert create dell'interfaccia della riga di comando di Azure per caricare la chiave pubblica del certificato di autenticazione da SQL Server in Azure, ad esempio l'esempio di PowerShell seguente.

Compilare le informazioni utente necessarie, copiarlo, incollarlo e quindi eseguire lo script. Sostituzione:

  • <SQLServerPublicKey> con la parte pubblica del certificato di SQL Server in formato binario, registrata nel passaggio precedente. Si tratta di un valore stringa lungo che inizia con 0x.
  • <SQLServerCertName> con il nome del certificato di SQL Server registrato nel passaggio precedente.
  • <ManagedInstanceName> con il nome breve dell'istanza gestita.
# 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 

Il risultato di questa operazione è un riepilogo del certificato di SQL Server caricato in Azure.

Se è necessario visualizzare tutti i certificati di SQL Server caricati in un'istanza gestita, usare il comando Get-AzSqlInstanceServerTrustCertificate di PowerShell o az sql mi partner-cert list dell'interfaccia della riga di comando di Azure in Azure Cloud Shell. Per rimuovere il certificato di SQL Server caricato in un'istanza gestita di SQL, usare il comando Remove-AzSqlInstanceServerTrustCertificate powerShell o az sql mi partner-cert delete dell'interfaccia della riga di comando di Azure in Azure Cloud Shell.

Ottenere la chiave pubblica del certificato da Istanza gestita di SQL e importarla in SQL Server

Il certificato per proteggere l'endpoint di collegamento viene generato automaticamente in Istanza gestita di SQL di Azure. Ottenere la chiave pubblica del certificato da Istanza gestita di SQL e importarla in SQL Server usando il comando Get-AzSqlInstanceEndpointCertificate di PowerShell o az sql mi endpoint-cert show dell'interfaccia della riga di comando di Azure, ad esempio l'esempio di PowerShell seguente.

Attenzione

Quando si usa l'interfaccia della riga di comando di Azure, è necessario aggiungere 0x manualmente all'inizio dell'output PublicKey quando viene usato nei passaggi successivi. Ad esempio, PublicKey sarà simile a "0x3082033E30...".

Eseguire lo script seguente. Sostituzione:

  • <SubscriptionID> con l'ID sottoscrizione di Azure.
  • <ManagedInstanceName> con il nome breve dell'istanza gestita.
# 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   

Copiare l'intero output PublicKey (inizia con 0x) perché sarà necessario nel passaggio successivo.

In alternativa, se si verificano problemi durante la copia incolla della chiave Pubblica, è anche possibile eseguire il comando EXEC sp_get_endpoint_certificate 4 T-SQL nell'istanza gestita per ottenere la relativa chiave pubblica per l'endpoint di collegamento.

Successivamente, importare la chiave pubblica ottenuta del certificato di sicurezza dell'istanza gestita in SQL Server. Eseguire la query seguente in SQL Server. Sostituzione:

  • <ManagedInstanceFQDN> con il nome di dominio completo dell'istanza gestita.
  • <PublicKey> con il valore PublicKey ottenuto nel passaggio precedente (da Azure Cloud Shell, a partire da 0x). Non è necessario usare le virgolette.

Importante

Il nome del certificato deve essere il nome FQDN Istanza gestita di SQL e non deve essere modificato. Il collegamento non sarà operativo se si usa un nome personalizzato.

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

Importare le chiavi dell'autorità di certificazione radice attendibile di Azure in SQL Server

L'importazione delle chiavi del certificato radice pubblico delle autorità di certificazione Microsoft e DigiCert (CA) in SQL Server è necessaria affinché SQL Server consideri attendibili i certificati rilasciati da Azure per i domini di database.windows.net.

Attenzione

Assicurarsi che PublicKey inizi con un oggetto 0x. Potrebbe essere necessario aggiungerlo manualmente all'inizio di PublicKey, se non è già presente.

Prima di tutto, importare il certificato dell'autorità radice PKI Microsoft in 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

Importare quindi il certificato dell'autorità radice PKI DigiCert in 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

Infine, verificare tutti i certificati creati usando la dmv seguente:

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

Proteggere l'endpoint del mirroring del database

Se non si dispone di un gruppo di disponibilità esistente o di un endpoint del mirroring del database in SQL Server, il passaggio successivo consiste nel creare un endpoint del mirroring del database in SQL Server e proteggerlo con il certificato di SQL Server generato in precedenza. Se si dispone di un gruppo di disponibilità o di un endpoint di mirroring esistente, passare alla sezione Alter an existing endpoint (Modifica endpoint esistente).

Creare e proteggere l'endpoint del mirroring del database in SQL Server

Per verificare che non sia stato creato un endpoint di mirroring del database esistente, usare lo script seguente:

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

Se la query precedente non mostra un endpoint del mirroring del database esistente, eseguire lo script seguente in SQL Server per ottenere il nome del certificato di SQL Server generato in precedenza.

-- 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'

Salvare SQLServerCertName dall'output perché sarà necessario nel passaggio successivo.

Usare lo script seguente per creare un nuovo endpoint del mirroring del database sulla porta 5022 e proteggere l'endpoint con il certificato di SQL Server. Sostituzione:

  • <SQL_SERVER_CERTIFICATE> con il nome di SQLServerCertName ottenuto nel passaggio precedente.
-- 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

Verificare che l'endpoint del mirroring sia stato creato eseguendo lo script seguente in 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

L'endpoint state_desc colonna è STARTEDstato creato correttamente.

È stato creato un nuovo endpoint di mirroring con l'autenticazione del certificato e la crittografia AES abilitata.

Modificare un endpoint esistente

Nota

Ignorare questo passaggio se è stato appena creato un nuovo endpoint di mirroring. Usare questo passaggio solo se si usano gruppi di disponibilità esistenti con un endpoint di mirroring del database esistente.

Se si usano gruppi di disponibilità esistenti per il collegamento o se è presente un endpoint di mirroring del database esistente, verificare prima di tutto che soddisfi le condizioni obbligatorie seguenti per il collegamento:

  • Il tipo deve essere DATABASE_MIRRORING.
  • Connessione autenticazione deve essere CERTIFICATE.
  • La crittografia deve essere abilitata.
  • L'algoritmo di crittografia deve essere AES.

Eseguire la query seguente in SQL Server per visualizzare i dettagli per un endpoint di mirroring del database esistente:

-- 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

Se l'output indica che l'endpoint esistente DATABASE_MIRRORING non CERTIFICATEè o encryption_algorthm_desc non AESè , l'endpoint deve essere modificato per soddisfare i requisiti.connection_auth_desc

In SQL Server lo stesso endpoint del mirroring del database viene usato sia per i gruppi di disponibilità che per i gruppi di disponibilità distribuiti. Se l'endpoint connection_auth_desc è NTLM (autenticazione di Windows) o KERBEROSed è necessario autenticazione di Windows per un gruppo di disponibilità esistente, è possibile modificare l'endpoint per usare più metodi di autenticazione passando all'opzione di autenticazione su NEGOTIATE CERTIFICATE. Questa modifica consente al gruppo di disponibilità esistente di usare autenticazione di Windows, usando l'autenticazione del certificato per Istanza gestita di SQL.

Analogamente, se la crittografia non include AES e è necessaria la crittografia RC4, è possibile modificare l'endpoint per usare entrambi gli algoritmi. Per informazioni dettagliate sulle opzioni possibili per la modifica degli endpoint, vedere la pagina della documentazione per sys.database_mirroring_endpoints.

Lo script seguente è un esempio di come modificare l'endpoint del mirroring del database esistente in SQL Server. Sostituzione:

  • <YourExistingEndpointName> con il nome dell'endpoint esistente.
  • <SQLServerCertName> con il nome del certificato di SQL Server generato (ottenuto in uno dei passaggi precedenti).

A seconda della configurazione specifica, potrebbe essere necessario personalizzare ulteriormente lo script. È anche possibile usare SELECT * FROM sys.certificates per ottenere il nome del certificato creato in 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

Dopo aver eseguito la query dell'endpoint ALTER e aver impostato la modalità di autenticazione doppia su Windows e sul certificato, usare di nuovo questa query in SQL Server per visualizzare i dettagli per l'endpoint del mirroring del database:

-- 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

L'endpoint del mirroring del database è stato modificato correttamente per un collegamento Istanza gestita di SQL.

Creare un gruppo di disponibilità in SQL Server

Se non si dispone di un gruppo di disponibilità esistente, il passaggio successivo consiste nel crearne uno in SQL Server, indipendentemente dal quale sarà il database primario iniziale. I comandi per creare il gruppo di disponibilità sono diversi se il Istanza gestita di SQL è il database primario iniziale, supportato solo a partire da SQL Server 2022 CU10.

Sebbene sia possibile stabilire più collegamenti per lo stesso database, il collegamento supporta solo la replica di un database per ogni collegamento. Se si desidera creare più collegamenti per lo stesso database, usare lo stesso gruppo di disponibilità per tutti i collegamenti, ma creare un nuovo gruppo di disponibilità distribuito per ogni collegamento di database tra SQL Server e Istanza gestita di SQL.

Se SQL Server è il database primario iniziale, creare un gruppo di disponibilità con i parametri seguenti per un collegamento:

  • Nome server primario iniziale
  • Nome database
  • Modalità di failover di MANUAL
  • Modalità di seeding di AUTOMATIC

Per prima cosa, individuare il nome di SQL Server eseguendo l'istruzione T-SQL seguente:

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

Usare quindi lo script seguente per creare il gruppo di disponibilità in SQL Server. Sostituzione:

  • <AGName> con il nome del gruppo di disponibilità. Un collegamento Istanza gestita richiede un database per ogni gruppo di disponibilità. Per più database, è necessario creare più gruppi di disponibilità. Prendere in considerazione la denominazione di ogni gruppo di disponibilità in modo che il nome rifletta il database corrispondente, AG_<db_name>ad esempio .
  • <DatabaseName> con il nome del database da replicare.
  • <SQLServerName> con il nome dell'istanza di SQL Server ottenuta nel passaggio precedente.
  • <SQLServerIP> con l'indirizzo IP di SQL Server. È possibile usare un nome di computer host di SQL Server risolvibile come alternativa, ma è necessario assicurarsi che il nome sia risolvibile dalla rete virtuale Istanza gestita di 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

Importante

Per SQL Server 2016, eliminare WITH (CLUSTER_TYPE = NONE) dall'istruzione T-SQL precedente. Lasciare invariato il valore per tutte le versioni successive di SQL Server.

Creare quindi il gruppo di disponibilità distribuito in SQL Server. Se si prevede di creare più collegamenti, è necessario creare un gruppo di disponibilità distribuito per ogni collegamento, anche se si stabiliscono più collegamenti per lo stesso database.

Sostituire i valori seguenti e quindi eseguire lo script T-SQL per creare il gruppo di disponibilità distribuito.

  • <DAGName> con il nome del gruppo di disponibilità distribuito. Poiché è possibile configurare più collegamenti per lo stesso database creando un gruppo di disponibilità distribuito per ogni collegamento, prendere in considerazione la possibilità di denominare di conseguenza ogni gruppo di disponibilità distribuito, ad esempio , DAG1_<db_name>DAG2_<db_name>.
  • <AGName> con il nome del gruppo di disponibilità creato nel passaggio precedente.
  • <SQLServerIP> con l'indirizzo IP di SQL Server del passaggio precedente. È possibile usare un nome di computer host di SQL Server risolvibile come alternativa, ma assicurarsi che il nome sia risolvibile dalla rete virtuale Istanza gestita di SQL (che richiede la configurazione di DNS di Azure personalizzato per la subnet dell'istanza gestita).
  • <ManagedInstanceName> con il nome breve dell'istanza gestita.
  • <ManagedInstanceFQDN> con il nome di dominio completo dell'istanza gestita.
-- 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

Verificare i gruppi di disponibilità

Usare lo script seguente per elencare tutti i gruppi di disponibilità e i gruppi di disponibilità distribuiti nell'istanza di SQL Server. A questo punto, lo stato del gruppo di disponibilità deve essere connectede lo stato dei gruppi di disponibilità distribuiti deve essere disconnected. Lo stato del gruppo di disponibilità distribuito passa a connected una sola volta che viene aggiunto con Istanza gestita di 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

In alternativa, è possibile usare SSMS Esplora oggetti per trovare gruppi di disponibilità e gruppi di disponibilità distribuiti. Espandere la cartella Disponibilità elevata Always On e quindi la cartella Gruppi di disponibilità.

Infine, è possibile creare il collegamento. I comandi differiscono in base all'istanza primaria iniziale. Usare il comando New-AzSqlInstanceLink PowerShell o az sql mi link create dell'interfaccia della riga di comando di Azure per creare il collegamento, ad esempio l'esempio di PowerShell in questa sezione. La creazione del collegamento da un Istanza gestita di SQL primario non è attualmente supportata con l'interfaccia della riga di comando di Azure.

Se è necessario visualizzare tutti i collegamenti in un'istanza gestita, usare il comando PowerShell Get-AzSqlInstanceLink o az sql mi link show Azure CLI in Azure Cloud Shell.

Per semplificare il processo, accedere al portale di Azure ed eseguire lo script seguente da Azure Cloud Shell. Sostituzione:

  • <ManagedInstanceName> con il nome breve dell'istanza gestita.
  • <AGName> con il nome del gruppo di disponibilità creato in SQL Server.
  • <DAGName> con il nome del gruppo di disponibilità distribuito creato in SQL Server.
  • <DatabaseName> con il database replicato nel gruppo di disponibilità in SQL Server.
  • <SQLServerIP> con l'indirizzo IP di SQL Server. L'indirizzo IP specificato deve essere accessibile dall'istanza gestita.
#  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

Il risultato di questa operazione è un timestamp dell'esecuzione corretta della creazione di una richiesta di collegamento.

Per verificare la connessione tra Istanza gestita di SQL e SQL Server, eseguire la query seguente in SQL Server. La connessione non sarà istantanea. L'avvio della DMV può richiedere fino a un minuto. Continuare ad aggiornare la DMV fino a quando la connessione non viene visualizzata come CONNECTED per la replica Istanza gestita di 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

Dopo aver stabilito la connessione, Esplora oggetti in SSMS potrebbe inizialmente mostrare il database replicato nella replica secondaria in uno stato di ripristino durante lo spostamento della fase di seeding iniziale e ripristina il backup completo del database. Dopo il ripristino del database, la replica deve recuperare lo stato sincronizzato dei due database. Il database non sarà più in Ripristino al termine del seeding iniziale. Il seeding di database di piccole dimensioni potrebbe essere sufficientemente veloce da non visualizzare lo stato di ripristino iniziale in SSMS.

Importante

  • Il collegamento non funzionerà a meno che non esista la connettività di rete tra SQL Server e Istanza gestita di SQL. Per risolvere i problemi di connettività di rete, seguire la procedura descritta in Testare la connettività di rete.
  • Eseguire backup regolari del file di log in SQL Server. Se lo spazio del log usato raggiunge il 100%, la replica in Istanza gestita di SQL si arresta fino a quando l'uso dello spazio non viene ridotto. È consigliabile automatizzare i backup del log configurando un processo giornaliero. Per informazioni dettagliate, vedere Eseguire il backup dei file di log in SQL Server.

Arrestare il carico di lavoro

Per eseguire il failover del database nella replica secondaria, arrestare prima di tutto tutti i carichi di lavoro dell'applicazione nel database primario durante le ore di manutenzione. Ciò consente alla replica di database di recuperare il database secondario o è possibile eseguire la migrazione o il failover in Azure senza perdita di dati. Anche se il database primario fa parte di un gruppo di disponibilità AlwaysOn, non è possibile impostarlo sulla modalità di sola lettura. È necessario assicurarsi che le applicazioni non esemettano il commit delle transazioni nella replica primaria prima del failover.

Cambiare la modalità di replica

La replica tra SQL Server e Istanza gestita di SQL è asincrona per impostazione predefinita. Prima di eseguire il failover del database nel database secondario, passare al collegamento alla modalità sincrona. La replica sincrona tra distanze di rete di grandi dimensioni potrebbe rallentare le transazioni nella replica primaria.

Il passaggio dalla modalità asincrona alla modalità di sincronizzazione richiede una modifica della modalità di replica sia in Istanza gestita di SQL che in SQL Server.

Modalità di replica switch (Istanza gestita di SQL)

Usare Azure PowerShell o l'interfaccia della riga di comando di Azure per cambiare la modalità di replica in Istanza gestita di SQL.

Prima di tutto, assicurarsi di aver eseguito l'accesso ad Azure e di aver selezionato la sottoscrizione in cui è ospitata l'istanza gestita usando il comando Select-AzSubscription PowerShell o az account set dell'interfaccia della riga di comando di Azure. La selezione della sottoscrizione appropriata è particolarmente importante se si dispone di più sottoscrizioni di Azure nell'account.

Nell'esempio di PowerShell seguente sostituire <SubscriptionID> con l'ID sottoscrizione di 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

Assicurarsi di conoscere il nome del collegamento di cui si vuole eseguire il failover. È possibile usare il comando Get-AzSqlInstanceLink PowerShell o az sql mi link list dell'interfaccia della riga di comando di Azure.

Usare lo script di PowerShell seguente per elencare tutti i collegamenti attivi nella Istanza gestita di SQL. Sostituire <ManagedInstanceName> con il nome breve dell'istanza gestita.

# 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 

Dall'output dello script precedente, registrare la Name proprietà del collegamento di cui si vuole eseguire il failover.

Passare quindi dalla modalità di replica da asincrona alla sincronizzazione in Istanza gestita di SQL per il collegamento identificato usando il comando Update-AzSqlInstanceLink PowerShell o az sql mi link update dell'interfaccia della riga di comando di Azure.

Nell'esempio di PowerShell seguente sostituire:

  • <ManagedInstanceName> con il nome breve dell'istanza gestita.
  • <DAGName> con il nome del collegamento rilevato nel passaggio precedente (la Name proprietà del passaggio precedente).
# 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"

Il comando precedente indica l'esito positivo visualizzando un riepilogo dell'operazione, con la proprietà ReplicationMode visualizzata come Sync.

Se è necessario ripristinare l'operazione, eseguire lo script precedente per cambiare la modalità di replica, ma sostituire la Sync stringa in -ReplicationMode su Async.

Modalità di replica switch (SQL Server)

Usare lo script T-SQL seguente in SQL Server per modificare la modalità di replica del gruppo di disponibilità distribuito in SQL Server da asincrona alla sincronizzazione. Sostituire:

  • <DAGName> con il nome del gruppo di disponibilità distribuito (usato per creare il collegamento).
  • <AGName> con il nome del gruppo di disponibilità creato in SQL Server (usato per creare il collegamento).
  • <ManagedInstanceName> con il nome dell'istanza gestita.
-- 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);

Per verificare che la modalità di replica del collegamento sia stata modificata correttamente, usare la visualizzazione a gestione dinamica seguente. I risultati indicano lo SYNCHRONOUS_COMIT stato.

-- 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

Ora che sono state passate sia Istanza gestita di SQL che SQL Server alla modalità di sincronizzazione, la replica tra le due istanze è sincrona. Se è necessario invertire questo stato, seguire gli stessi passaggi e impostare lo stato su async per SQL Server e Istanza gestita di SQL.

Controllare i valori LSN sia in SQL Server che in Istanza gestita di SQL

Per completare il failover o la migrazione, verificare che la replica sia stata completata. A tale scopo, verificare che i numeri di sequenza di log (LSN) nei record di log per SQL Server e Istanza gestita di SQL siano uguali.

Inizialmente, è previsto che l'LSN nel database primario sia superiore al numero LSN sul database secondario. La latenza di rete potrebbe causare un ritardo della replica in qualche modo dietro la replica primaria. Poiché il carico di lavoro è stato arrestato nel database primario, è consigliabile che i nomi LSN corrispondano e interrompino la modifica dopo un certo periodo di tempo.

Usare la query T-SQL seguente in SQL Server per leggere l'LSN dell'ultimo log delle transazioni registrato. Sostituzione:

  • <DatabaseName> con il nome del database e cercare l'ultimo numero LSN con protezione avanzata.
-- 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>'

Usare la query T-SQL seguente su Istanza gestita di SQL per leggere l'ultimo LSN con protezione avanzata per il database. Sostituire <DatabaseName> con il nome del database.

Questa query funziona su un Istanza gestita di SQL per utilizzo generico. Per un Istanza gestita di SQL business critical, rimuovere il commento and drs.is_primary_replica = 1 alla fine dello script. Nel livello di servizio Business Critical questo filtro garantisce che i dettagli vengano letti solo dalla replica primaria.

-- 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

In alternativa, è anche possibile usare il comando Get-AzSqlInstanceLink PowerShell o az sql mi link show dell'interfaccia della riga di comando di Azure per recuperare la proprietà per il LastHardenedLsn collegamento in Istanza gestita di SQL per fornire le stesse informazioni della query T-SQL precedente.

Importante

Verificare di nuovo che il carico di lavoro sia stato arrestato nel database primario. Verificare che i nomi LSN in SQL Server e Istanza gestita di SQL corrispondano e rimangano invariati per un certo periodo di tempo. I nomi LSN stabili in entrambe le istanze indicano che il log della parte finale è stato replicato nel database secondario e il carico di lavoro viene arrestato in modo efficace.

Eseguire il failover di un database

Se si vuole usare PowerShell per eseguire il failover di un database tra SQL Server 2022 e Istanza gestita di SQL mantenendo il collegamento o per eseguire un failover con perdita di dati per qualsiasi versione di SQL Server, usare la procedura guidata Failover tra SQL Server e Istanza gestita in SSMS per generare lo script per l'ambiente. È possibile eseguire un failover pianificato dalla replica primaria o secondaria. Per eseguire un failover forzato, connettersi alla replica secondaria.

Per interrompere il collegamento e arrestare la replica quando si esegue il failover o la migrazione del database indipendentemente dalla versione di SQL Server, usare il comando Remove-AzSqlInstanceLink PowerShell o az sql mi link delete dell'interfaccia della riga di comando di Azure.

Attenzione

  • Prima del failover, arrestare il carico di lavoro nel database di origine per consentire al database replicato di recuperare completamente e eseguire il failover senza perdita di dati. Se si esegue un failover forzato o si interrompe il collegamento prima della corrispondenza con IDN, è possibile che i dati vadano persi.
  • Il failover di un database in SQL Server 2019 e versioni precedenti interrompe e rimuove il collegamento tra le due repliche. Non è possibile eseguire il failback al database primario iniziale.
  • Il failover di un database mantenendo il collegamento con SQL Server 2022 è attualmente in anteprima.

Lo script di esempio seguente interrompe il collegamento e termina la replica tra le repliche, rendendo il database in lettura/scrittura in entrambe le istanze. Sostituzione:

  • <ManagedInstanceName> con il nome dell'istanza gestita.
  • <DAGName> con il nome del collegamento di cui si esegue il failover (output della proprietà Name del Get-AzSqlInstanceLink comando eseguito in precedenza).
# 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

Quando il failover ha esito positivo, il collegamento viene eliminato e non esiste più. Il database di SQL Server e Istanza gestita di SQL database possono eseguire entrambi un carico di lavoro di lettura/scrittura. Sono completamente indipendenti. Ripristinare il stringa di connessione dell'applicazione al database che si vuole usare attivamente.

Importante

Al termine del failover in Istanza gestita di SQL, ripristinare manualmente le applicazioni stringa di connessione al nome di dominio completo dell'istanza gestita di SQL per completare la migrazione o il processo di failover e continuare l'esecuzione in Azure.

Pulire i gruppi di disponibilità

Poiché il failover con SQL Server 2022 non interrompe il collegamento, è possibile scegliere di lasciare il collegamento e i gruppi di disponibilità sul posto.

Se si decide di interrompere il collegamento o se si esegue il failover con SQL Server 2019 e versioni precedenti, è necessario eliminare il gruppo di disponibilità distribuito per rimuovere i metadati dei collegamenti da SQL Server. È tuttavia possibile scegliere di mantenere il gruppo di disponibilità in SQL Server.

Per pulire le risorse del gruppo di disponibilità, sostituire i valori seguenti e quindi eseguire il codice di esempio: Nel codice seguente sostituire:

  • <DAGName> con il nome del gruppo di disponibilità distribuito in SQL Server (usato per creare il collegamento).
  • <AGName> con il nome del gruppo di disponibilità in SQL Server (usato per creare il collegamento).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

Risoluzione dei problemi

La sezione fornisce indicazioni per risolvere i problemi relativi alla configurazione e all'uso del collegamento.

Errori

Se viene visualizzato un messaggio di errore quando si crea il collegamento o si esegue il failover di un database, esaminare il messaggio di errore nella finestra di output della query per altre informazioni.

Se si verifica un errore durante l'utilizzo del collegamento, la query interrompe l'esecuzione nel passaggio non riuscito. Dopo aver risolto la condizione di errore, eseguire di nuovo il comando per procedere con l'azione.

Stato incoerente dopo il failover forzato

L'uso del failover forzato può comportare uno stato incoerente tra le repliche primarie e secondarie, causando uno scenario di divisione del cervello da entrambe le repliche nello stesso ruolo. La replica dei dati non riesce in questo stato finché l'utente non risolve la situazione designando manualmente una replica come primaria e l'altra come secondaria.

Per altre informazioni sulla funzionalità di collegamento, vedere le risorse seguenti: