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

  • Articolo

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 near real-time.

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 Nuovo collegamento 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:

Considerare quanto segue:

  • La funzionalità di collegamento supporta un database per ogni collegamento. Per replicare più database in un'istanza, creare un collegamento per ogni singolo database. Ad esempio, per replicare 10 database in Istanza gestita di SQL, creare 10 collegamenti individuali.
  • 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 amministratore di sistema.

Per Istanza gestita di SQL di Azure, è necessario essere membri del Contributore 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/* /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 scoprirlo
Primo iniziale 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 Breve nome di un’unica parola per SQL Server. Ad esempio: sqlserver1. Eseguire SELECT @@SERVERNAME da T-SQL.
FQDN SQL Server FQDN è il nome di dominio completo del 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) Breve nome di un’unica parola per l’Istanza gestita di SQL. Ad esempio: managedinstance1. Trovare il nome della risorsa Istanza gestita nel portale di Azure.
FQDN dell'istanza gestita di SQL Il nome di dominio completo (FQDN) dell'Istanza gestita di SQL di Azure. 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. Dal prompt dei comandi eseguire questo comando nslookup.
IP SQL server L'indirizzo IP del server SQL. In caso di più indirizzi IP in SQL Server, scegliere l'indirizzo IP accessibile da Azure. Eseguire il comando ipconfig 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 backup e il ripristino 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 Creazione di un backup completo del database.

Nota

Il collegamento supporta solo la replica dei database utente. La replica del database di sistema non è supportata. Per eseguire la migrazione di oggetti a livello di istanza (archiviati nel database master o msdb), è consigliabile inserirli in script ed eseguire gli 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 utilizzato esclusivamente dai gruppi di disponibilità per ricevere connessioni da altre istanze del server. Il termine endpoint del mirroring del database non deve essere confuso 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 l'autenticazione di Windows, è possibile aggiungere l'attendibilità basata su certificati 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 è possibile trovare una panoramica del processo per proteggere gli endpoint di mirroring del database protetti per SQL Server e Istanza gestita di SQL:

  1. Generare un certificato in SQL Server e recuperarne la chiave pubblica.
  2. Recuperare la chiave pubblica del certificato dell’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 database master, se non è già presente. Inserire la password al posto di <strong_password> nello 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.

Adesso è possibile ottenere la chiave pubblica del certificato di SQL Server generato:

-- 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 PowerShell New-AzSqlInstanceServerTrustCertificate 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 di PowerShell Get-AzSqlInstanceServerTrustCertificate 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 PowerShell Remove-AzSqlInstanceServerTrustCertificate o az sql mi partner-cert delete dell'interfaccia della riga di comando di Azure in Azure Cloud Shell.

Importare la chiave pubblica del certificato dall’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 della 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.

Quindi, 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 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 Modificare 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 è creato correttamente dovrebbe essere nello stato STARTED.

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

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

Per ottenere i dettagli per un endpoint di mirroring del database esistente, eseguire la seguente query su 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

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

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 KERBEROS, ed è 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 ed è 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 di mirroring del database esistente su 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à su 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 l’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 poi 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, ad esempio AG_<db_name>.
  • <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 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 connected, e lo stato dei gruppi di disponibilità distribuiti deve essere disconnected. Lo stato del gruppo di disponibilità distribuito passa a connected solo quando viene unito all’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 di 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 Get-AzSqlInstanceLink di PowerShell o il comando az sql mi link show dell’interfaccia della riga di comando di Azure 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à Always On, non è possibile impostarlo sulla modalità di sola lettura. È necessario assicurarsi che le applicazioni non eseguano 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 di PowerShell o il comando 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 di PowerShell o il comando az sql mi link list dell'interfaccia della riga di comando di Azure.

Usare il seguente script di PowerShell per elencare tutti i collegamenti attivi nell’Istanza gestita di SQL. Sostituire <ManagedInstanceName> con il nome breve della propria 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 proprietà Name 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 di PowerShell o il comando az sql mi link update dell'interfaccia della riga di comando di Azure.

Nel seguente esempio di PowerShell, sostituire:

  • <ManagedInstanceName> con il nome breve dell'istanza gestita.
  • <DAGName> con il nome del collegamento rilevato nel passaggio precedente (la proprietà Name 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 stringa Sync nella -ReplicationMode con Async.

Cambiare modalità di replica (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 DMV seguente. I risultati indicano lo stato 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

Ora che sia Istanza gestita di SQL che SQL Server sono passate 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 sia per SQL Server che per 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 del file 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 che dopo un certo periodo di tempo smettano di cambiare.

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 di PowerShell o il comando 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 che continuino a corrispondere 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 di PowerShell o il comando 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 LSN, è 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 comando Get-AzSqlInstanceLink 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 il database di Istanza gestita di SQL possono eseguire entrambi un carico di lavoro di lettura/scrittura. Sono completamente indipendenti. Ripristinare la 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 FQDN 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 effettua 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 l’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.

Contenuto correlato

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