Dela via

Konfigurera länk med skript – Azure SQL Managed Instance

  • Artikel

Gäller för:Azure SQL Managed Instance

I den här artikeln lär du dig hur du konfigurerar en länk mellan SQL Server och Azure SQL Managed Instance med Transact-SQL- och PowerShell- eller Azure CLI-skript. Med länken replikeras databaser från den ursprungliga primära repliken till den sekundära repliken nästan i realtid.

När länken har skapats kan du sedan redundansväxla till den sekundära repliken för migrering eller haveriberedskap.

Kommentar

Översikt

Använd länkfunktionen för att replikera databaser från den första primära till den sekundära repliken. För SQL Server 2022 kan den första primära vara antingen SQL Server eller Azure SQL Managed Instance. För SQL Server 2019 och tidigare versioner måste den första primära vara SQL Server. När länken har konfigurerats replikeras databaser från den första primära till den sekundära repliken.

Du kan välja att lämna länken på plats för kontinuerlig datareplikering i en hybridmiljö mellan den primära och sekundära repliken, eller så kan du redundansväxla databasen till den sekundära repliken, migrera till Azure eller för haveriberedskap. För SQL Server 2019 och tidigare versioner bryter redundansväxling till Azure SQL Managed Instance länken och återställning efter fel stöds inte. Med SQL Server 2022 har du möjlighet att underhålla länken och misslyckas fram och tillbaka mellan de två replikerna – den här funktionen är för närvarande i förhandsversion.

Om du planerar att endast använda den sekundära hanterade instansen för haveriberedskap kan du spara på licenskostnaderna genom att aktivera hybridredundansförmånen.

Använd anvisningarna i den här artikeln för att manuellt konfigurera länken mellan SQL Server och Azure SQL Managed Instance. När länken har skapats får källdatabasen en skrivskyddad kopia på den sekundära målrepliken.

Dricks

  • För att förenkla användningen av T-SQL-skript med rätt parametrar för din miljö rekommenderar vi starkt att du använder guiden Hanterad instanslänk i SQL Server Management Studio (SSMS) för att generera ett skript för att skapa länken. På sidan Sammanfattning i länkfönstret Ny hanterad instans väljer du Skript i stället för Slutför.

Förutsättningar

Kommentar

Vissa funktioner i länken är allmänt tillgängliga, medan vissa för närvarande är i förhandsversion. Läs mer i versionssupporten .

För att replikera dina databaser behöver du följande krav:

Tänk på följande:

  • Länkfunktionen stöder en databas per länk. Om du vill replikera flera databaser på en instans skapar du en länk för varje enskild databas. Om du till exempel vill replikera 10 databaser till SQL Managed Instance skapar du 10 enskilda länkar.
  • Sorteringen mellan SQL Server och SQL Managed Instance bör vara densamma. Ett matchningsfel i sorteringen kan orsaka ett matchningsfel i servernamnshöljet och förhindra en lyckad anslutning från SQL Server till SQL Managed Instance.
  • Fel 1475 på den första SQL Server-primära indikerar att du behöver starta en ny säkerhetskopieringskedja genom att skapa en fullständig säkerhetskopia utan COPY ONLY alternativet.

Behörigheter

För SQL Server bör du ha sysadmin-behörigheter .

För Azure SQL Managed Instance bör du vara medlem i SQL Managed Instance-deltagaren eller ha följande anpassade rollbehörigheter:

Microsoft.Sql/-resurs Nödvändiga behörigheter
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /åtgärd
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 /Läsa
Microsoft.Sql/managedInstances/hybridLink /read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

Terminologi och namngivningskonventioner

När du kör skript från den här användarhandboken är det viktigt att inte missta SQL Server- och SQL Managed Instance-namn för deras fullständigt kvalificerade domännamn (FQDN). I följande tabell förklaras vad de olika namnen exakt representerar och hur de får sina värden:

Terminologi beskrivning Så här får du reda på det
Inledande primär 1 SQL Server eller SQL Managed Instance där du först skapar länken för att replikera databasen till den sekundära repliken.
Primär replik SQL Server eller SQL Managed Instance som för närvarande är värd för den primära databasen.
Sekundär replik SQL Server eller SQL Managed Instance som tar emot replikerade data nästan i realtid från den aktuella primära repliken.
SQL Server-namn Kort SQL Server-namn med ett ord. Till exempel: sqlserver1. Kör SELECT @@SERVERNAME från T-SQL.
SQL Server FQDN Fullständigt domännamn (FQDN) för din SQL Server. Till exempel: sqlserver1.domain.com. Se din nätverkskonfiguration (DNS) lokalt eller servernamnet om du använder en virtuell Azure-dator (VM).
SQL Managed Instance-namn Kort sql managed instance-namn med ett ord. Till exempel: managedinstance1. Se namnet på din hanterade instans i Azure-portalen.
SQL Managed Instance FQDN Fullständigt kvalificerat domännamn (FQDN) för din SQL Managed Instance. Till exempel: managedinstance1.6d710bcf372b.database.windows.net. Se värdnamnet på översiktssidan för SQL Managed Instance i Azure-portalen.
Domännamn som kan matchas DNS-namn som kan matchas till en IP-adress. Om du till exempel kör nslookup sqlserver1.domain.com ska en IP-adress returneras, till exempel 10.0.0.1. Kör nslookup kommandot från kommandotolken.
SQL Server IP IP-adressen för din SQL Server. Om det finns flera IP-adresser på SQL Server väljer du IP-adress som är tillgänglig från Azure. Kör ipconfig kommandot från kommandotolken för värdoperativsystemet som kör SQL Server.

1 Konfigurera Azure SQL Managed Instance som din första primära är för närvarande i förhandsversion och stöds endast från och med SQL Server 2022 CU10.

Konfigurera databasåterställning och säkerhetskopiering

Om SQL Server är din första primära databas måste databaser som replikeras via länken finnas i den fullständiga återställningsmodellen och ha minst en säkerhetskopia. Eftersom Azure SQL Managed Instance tar säkerhetskopior automatiskt hoppar du över det här steget om SQL Managed Instance är den första primära instansen. primär

Kör följande kod på SQL Server för alla databaser som du vill replikera. Ersätt <DatabaseName> med det faktiska databasnamnet.

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

Mer information finns i Skapa en fullständig databassäkerhetskopia.

Kommentar

Länken stöder endast replikering av användardatabaser. Replikering av systemdatabaser stöds inte. För att replikera objekt på instansnivå (lagrade i master eller msdb databaser) rekommenderar vi att du skriptar ut dem och kör T-SQL-skript på målinstansen.

Upprätta förtroende mellan instanser

Först måste du upprätta förtroende mellan de två instanserna och skydda de slutpunkter som används för att kommunicera och kryptera data i nätverket. Distribuerade tillgänglighetsgrupper använder den befintliga tillgänglighetsgruppens databasspeglingsslutpunkt i stället för att ha en egen dedikerad slutpunkt. Därför måste säkerhet och förtroende konfigureras mellan de två instanserna via tillgänglighetsgruppens databasspeglingsslutpunkt.

Kommentar

Länken baseras på always on-tillgänglighetsgruppens teknik. Databasspeglingsslutpunkten är en specialslutpunkt som uteslutande används av tillgänglighetsgrupper för att ta emot anslutningar från andra instanser. Termen databasspeglingsslutpunkt bör inte förväxlas med den äldre SQL Server-databasspeglingsfunktionen.

Certifikatbaserat förtroende är det enda sättet att skydda databasspeglingsslutpunkter för SQL Server och SQL Managed Instance. Om du har befintliga tillgänglighetsgrupper som använder Windows-autentisering måste du lägga till certifikatbaserat förtroende till den befintliga speglingsslutpunkten som ett sekundärt autentiseringsalternativ. Du kan göra detta med hjälp av -instruktionen ALTER ENDPOINT , som du ser senare i den här artikeln.

Viktigt!

Certifikat genereras med ett förfallodatum och en förfallotid. De måste förnyas och roteras innan de upphör att gälla.

Följande visar en översikt över processen för att skydda databasspeglingsslutpunkter för både SQL Server och SQL Managed Instance:

  1. Generera ett certifikat på SQL Server och hämta dess offentliga nyckel.
  2. Hämta en offentlig nyckel för SQL Managed Instance-certifikatet.
  3. Byt ut de offentliga nycklarna mellan SQL Server och SQL Managed Instance.
  4. Importera Azure-betrodda rotcertifikatutfärdarnycklar till SQL Server

I följande avsnitt beskrivs de här stegen i detalj.

Skapa ett certifikat på SQL Server och importera dess offentliga nyckel till SQL Managed Instance

Skapa först databashuvudnyckeln i databasen, om den master inte redan finns. Infoga lösenordet i stället för <strong_password> i följande skript och förvara det på en konfidentiell och säker plats. Kör det här T-SQL-skriptet på 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

Generera sedan ett autentiseringscertifikat på SQL Server. Ersätt i följande skript:

  • @cert_expiry_date med önskat certifikatets förfallodatum (framtida datum).

Registrera det här datumet och ange en påminnelse om att rotera (uppdatera) SQL Server-certifikatet före utgångsdatumet för att säkerställa kontinuerlig drift av länken.

Viktigt!

Vi rekommenderar starkt att du använder det automatiskt genererade certifikatnamnet från det här skriptet. Det är tillåtet att anpassa ditt eget certifikatnamn på SQL Server, men namnet får inte innehålla några \ tecken.

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

Använd sedan följande T-SQL-fråga på SQL Server för att verifiera att certifikatet har skapats:

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

I frågeresultatet ser du att certifikatet har krypterats med huvudnyckeln.

Nu kan du hämta den offentliga nyckeln för det genererade certifikatet på 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;

Spara värden för SQLServerCertName och SQLServerPublicKey från utdata eftersom du behöver det i nästa steg när du importerar certifikatet.

Kontrollera först att du är inloggad i Azure och att du har valt den prenumeration där den hanterade instansen finns. Det är särskilt viktigt att välja rätt prenumeration om du har fler än en Azure-prenumeration på ditt konto.

Ersätt <SubscriptionID> med ditt Azure-prenumerations-ID.

# 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

Använd sedan antingen Kommandot New-AzSqlInstanceServerTrustCertificate PowerShell eller az sql mi partner-cert create Azure CLI för att ladda upp den offentliga nyckeln för autentiseringscertifikatet från SQL Server till Azure, till exempel följande PowerShell-exempel.

Fyll i nödvändig användarinformation, kopiera den, klistra in den och kör sedan skriptet. Ersätta:

  • <SQLServerPublicKey> med den offentliga delen av SQL Server-certifikatet i binärt format, som du har registrerat i föregående steg. Det är ett långt strängvärde som börjar med 0x.
  • <SQLServerCertName> med det SQL Server-certifikatnamn som du har registrerat i föregående steg.
  • <ManagedInstanceName> med det korta namnet på den hanterade instansen.
# 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

Resultatet av den här åtgärden är en sammanfattning av det uppladdade SQL Server-certifikatet till Azure.

Om du behöver se alla SQL Server-certifikat som laddats upp till en hanterad instans använder du Azure CLI-kommandot Get-AzSqlInstanceServerTrustCertificate PowerShell eller az sql mi partner-cert list i Azure Cloud Shell. Om du vill ta bort SQL Server-certifikat som laddats upp till en SQL-hanterad instans använder du kommandot Remove-AzSqlInstanceServerTrustCertificate PowerShell eller az sql mi partner-cert delete Azure CLI i Azure Cloud Shell.

Hämta certifikatets offentliga nyckel från SQL Managed Instance och importera den till SQL Server

Certifikatet för att skydda länkslutpunkten genereras automatiskt på Azure SQL Managed Instance. Hämta certifikatets offentliga nyckel från SQL Managed Instance och importera den till SQL Server med hjälp av Kommandot Get-AzSqlInstanceEndpointCertificate PowerShell eller az sql mi endpoint-cert show Azure CLI, till exempel följande PowerShell-exempel.

Varning

När du använder Azure CLI måste du manuellt lägga 0x till på framsidan av PublicKey-utdata när du använder det i efterföljande steg. PublicKey ser till exempel ut som "0x3082033E30...".

Kör följande skript. Ersätta:

  • <SubscriptionID> med ditt Azure-prenumerations-ID.
  • <ManagedInstanceName> med det korta namnet på den hanterade instansen.
# 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

Kopiera hela PublicKey-utdata (börjar med 0x) eftersom du behöver det i nästa steg.

Om du stöter på problem med att kopiera och klistra in PublicKey kan du också köra T-SQL-kommandot EXEC sp_get_endpoint_certificate 4 på den hanterade instansen för att hämta dess offentliga nyckel för länkslutpunkten.

Importera sedan den hämtade offentliga nyckeln för säkerhetscertifikatet för den hanterade instansen till SQL Server. Kör följande fråga på SQL Server. Ersätta:

  • <ManagedInstanceFQDN> med det fullständigt kvalificerade domännamnet för den hanterade instansen.
  • <PublicKey> med publickey-värdet som erhölls i föregående steg (från Azure Cloud Shell, från och med 0x). Du behöver inte använda citattecken.

Viktigt!

Namnet på certifikatet måste vara SQL Managed Instance FQDN och bör inte ändras. Länken fungerar inte om du använder ett anpassat namn.

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

Importera Azure-betrodda rotcertifikatutfärdarnycklar till SQL Server

Import av offentliga rotcertifikatnycklar för Microsoft och DigiCert-certifikatutfärdare (CA) till SQL Server krävs för att SQL Server ska kunna lita på certifikat som utfärdats av Azure för database.windows.net domäner.

Varning

Kontrollera att PublicKey börjar med .0x Du kan behöva lägga till den manuellt i början av PublicKey om den inte redan finns där.

Importera först Microsoft PKI-rotutfärdarcertifikat på 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

Importera sedan DigiCert PKI-rotutfärdarcertifikat på 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

Kontrollera slutligen alla skapade certifikat med hjälp av följande dynamiska hanteringsvy (DMV):

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

Skydda databasens speglingsslutpunkt

Om du inte har någon befintlig tillgänglighetsgrupp eller en databasspeglingsslutpunkt på SQL Server är nästa steg att skapa en databasspeglingsslutpunkt på SQL Server och skydda den med det tidigare genererade SQL Server-certifikatet. Om du har en befintlig tillgänglighetsgrupp eller speglingsslutpunkt går du vidare till avsnittet Ändra en befintlig slutpunkt .

Skapa och skydda databasspeglingsslutpunkten på SQL Server

Använd följande skript för att kontrollera att du inte har skapat någon befintlig databasspeglingsslutpunkt:

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

Om föregående fråga inte visar en befintlig databasspeglingsslutpunkt kör du följande skript på SQL Server för att hämta namnet på det tidigare genererade SQL Server-certifikatet.

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

Spara SQLServerCertName från utdata när du behöver det i nästa steg.

Använd följande skript för att skapa en ny databasspeglingsslutpunkt på port 5022 och skydda slutpunkten med SQL Server-certifikatet. Ersätta:

  • <SQL_SERVER_CERTIFICATE> med namnet på SQLServerCertName som hämtades i föregående steg.
-- 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

Kontrollera att speglingsslutpunkten skapades genom att köra följande skript på 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

Slutpunkten state_desc kolumnen ska ha statusen STARTED.

En ny speglingsslutpunkt skapades med certifikatautentisering och AES-kryptering aktiverat.

Ändra en befintlig slutpunkt

Kommentar

Hoppa över det här steget om du just har skapat en ny speglingsslutpunkt. Använd endast det här steget om du använder befintliga tillgänglighetsgrupper med en befintlig databasspeglingsslutpunkt.

Om du använder befintliga tillgänglighetsgrupper för länken eller om det finns en befintlig databasspeglingsslutpunkt kontrollerar du först att den uppfyller följande obligatoriska villkor för länken:

  • Typen måste vara DATABASE_MIRRORING.
  • Anslut ion-autentisering måste vara CERTIFICATE.
  • Kryptering måste vara aktiverat.
  • Krypteringsalgoritmen måste vara AES.

Kör följande fråga på SQL Server för att visa information om en befintlig databasspeglingsslutpunkt:

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

Om utdata visar att den befintliga DATABASE_MIRRORING slutpunkten connection_auth_desc inte CERTIFICATEär , eller encryption_algorthm_desc inte AESär , måste slutpunkten ändras för att uppfylla kraven.

På SQL Server används samma databasspeglingsslutpunkt för både tillgänglighetsgrupper och distribuerade tillgänglighetsgrupper. Om slutpunkten connection_auth_desc är NTLM (Windows-autentisering) eller KERBEROS, och du behöver Windows-autentisering för en befintlig tillgänglighetsgrupp, kan du ändra slutpunkten så att den använder flera autentiseringsmetoder genom att växla autentiseringsalternativet till NEGOTIATE CERTIFICATE. Den här ändringen gör att den befintliga tillgänglighetsgruppen kan använda Windows-autentisering, samtidigt som certifikatautentisering används för SQL Managed Instance.

På samma sätt, om kryptering inte innehåller AES och du behöver RC4-kryptering, är det möjligt att ändra slutpunkten för att använda båda algoritmerna. Mer information om möjliga alternativ för att ändra slutpunkter finns på dokumentationssidan för sys.database_mirroring_endpoints.

Följande skript är ett exempel på hur du ändrar din befintliga databasspeglingsslutpunkt på SQL Server. Ersätta:

  • <YourExistingEndpointName> med ditt befintliga slutpunktsnamn.
  • <SQLServerCertName> med namnet på det genererade SQL Server-certifikatet (hämtas i något av de tidigare stegen ovan).

Beroende på din specifika konfiguration kan du behöva anpassa skriptet ytterligare. Du kan också använda SELECT * FROM sys.certificates för att hämta namnet på det skapade certifikatet på 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

När du har kört ALTER slutpunktsfrågan och angett läget för dubbel autentisering till Windows och certifikat använder du den här frågan igen på SQL Server för att visa information om databasens speglingsslutpunkt:

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

Du har ändrat databasspeglingsslutpunkten för en SQL Managed Instance-länk.

Skapa en tillgänglighetsgrupp på SQL Server

Om du inte har någon befintlig tillgänglighetsgrupp är nästa steg att skapa en på SQL Server, oavsett vilken som är den första primära. Kommandon för att skapa tillgänglighetsgruppen skiljer sig om din SQL Managed Instance är den första primära, som endast stöds från och med SQL Server 2022 CU10.

Det går att upprätta flera länkar för samma databas, men länken stöder bara replikering av en databas per länk. Om du vill skapa flera länkar för samma databas använder du samma tillgänglighetsgrupp för alla länkar, men skapar sedan en ny distribuerad tillgänglighetsgrupp för varje databaslänk mellan SQL Server och SQL Managed Instance.

Om SQL Server är din första primära, skapar du en tillgänglighetsgrupp med följande parametrar för en länk:

  • Ursprungligt primärt servernamn
  • Databasnamn
  • Ett redundansläge för MANUAL
  • Ett seeding-läge för AUTOMATIC

Ta först reda på ditt SQL Server-namn genom att köra följande T-SQL-instruktion:

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

Använd sedan följande skript för att skapa tillgänglighetsgruppen på SQL Server. Ersätta:

  • <AGName> med namnet på din tillgänglighetsgrupp. En hanterad instans-länk kräver en databas per tillgänglighetsgrupp. För flera databaser måste du skapa flera tillgänglighetsgrupper. Överväg att namnge varje tillgänglighetsgrupp så att dess namn återspeglar motsvarande databas , till exempel AG_<db_name>.
  • <DatabaseName> med namnet på databasen som du vill replikera.
  • <SQLServerName> med namnet på din SQL Server-instans som hämtades i föregående steg.
  • <SQLServerIP> med SQL Server IP-adressen. Du kan använda ett matchningsbart SQL Server-värddatornamn som ett alternativ, men du måste se till att namnet kan matchas från det virtuella SQL Managed Instance-nätverket.
-- 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

Viktigt!

För SQL Server 2016 tar du bort WITH (CLUSTER_TYPE = NONE) från ovanstående T-SQL-instruktion. Lämna som den är för alla senare SQL Server-versioner.

Skapa sedan den distribuerade tillgänglighetsgruppen på SQL Server. Om du planerar att skapa flera länkar måste du skapa en distribuerad tillgänglighetsgrupp för varje länk, även om du upprättar flera länkar för samma databas.

Ersätt följande värden och kör sedan T-SQL-skriptet för att skapa din distribuerade tillgänglighetsgrupp.

  • <DAGName> med namnet på din distribuerade tillgänglighetsgrupp. Eftersom du kan konfigurera flera länkar för samma databas genom att skapa en distribuerad tillgänglighetsgrupp för varje länk bör du överväga att namnge varje distribuerad tillgänglighetsgrupp i enlighet med detta, till exempel DAG1_<db_name>, DAG2_<db_name>.
  • <AGName> med namnet på tillgänglighetsgruppen som du skapade i föregående steg.
  • <SQLServerIP> med IP-adressen för SQL Server från föregående steg. Du kan använda ett matchningsbart SQL Server-värddatornamn som ett alternativ, men kontrollera att namnet kan matchas från det virtuella SQL Managed Instance-nätverket (vilket kräver att du konfigurerar anpassad Azure DNS för undernätet för den hanterade instansen).
  • <ManagedInstanceName> med det korta namnet på den hanterade instansen.
  • <ManagedInstanceFQDN> med det fullständigt kvalificerade domännamnet för din hanterade instans.
-- 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

Verifiera tillgänglighetsgrupper

Använd följande skript för att visa en lista över alla tillgänglighetsgrupper och distribuerade tillgänglighetsgrupper på SQL Server-instansen. Nu måste statusen för tillgänglighetsgruppen vara connected, och tillståndet för dina distribuerade tillgänglighetsgrupper måste vara disconnected. Tillståndet för den distribuerade tillgänglighetsgruppen flyttas bara till när den är ansluten till connected SQL Managed Instance.

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

Du kan också använda SSMS Object Explorer för att hitta tillgänglighetsgrupper och distribuerade tillgänglighetsgrupper. Expandera mappen Always On High Availability och sedan mappen Tillgänglighetsgrupper.

Slutligen kan du skapa länken. Kommandona skiljer sig åt beroende på vilken instans som är den första primära. Använd Kommandot New-AzSqlInstanceLink PowerShell eller az sql mi link create Azure CLI för att skapa länken, till exempel PowerShell-exemplet i det här avsnittet. Det går för närvarande inte att skapa länken från en primär SQL Managed Instance-instans med Azure CLI.

Om du behöver se alla länkar på en hanterad instans använder du Get-AzSqlInstanceLink PowerShell eller az sql mi link show Azure CLI-kommandot i Azure Cloud Shell.

För att förenkla processen loggar du in på Azure-portalen och kör följande skript från Azure Cloud Shell. Ersätta:

  • <ManagedInstanceName> med det korta namnet på den hanterade instansen.
  • <AGName> med namnet på tillgänglighetsgruppen som skapats på SQL Server.
  • <DAGName> med namnet på den distribuerade tillgänglighetsgruppen som skapats på SQL Server.
  • <DatabaseName> med databasen replikerad i tillgänglighetsgruppen på SQL Server.
  • <SQLServerIP> med IP-adressen för din SQL Server. Den angivna IP-adressen måste vara tillgänglig för den hanterade instansen.
#  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

Resultatet av den här åtgärden är en tidsstämpel för den lyckade körningen av en länkbegäran.

Kontrollera anslutningen mellan SQL Managed Instance och SQL Server genom att köra följande fråga på SQL Server. Anslutningen blir inte omedelbar. Det kan ta upp till en minut innan DMV:en börjar visa en lyckad anslutning. Fortsätt att uppdatera DMV tills anslutningen visas som ANSLUTEN för SQL Managed Instance-repliken.

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

När anslutningen har upprättats kan Object Explorer i SSMS först visa den replikerade databasen på den sekundära repliken i ett återställningstillstånd när den inledande seeding-fasen flyttas och återställer den fullständiga säkerhetskopian av databasen. När databasen har återställts måste replikeringen komma ikapp för att de två databaserna ska få ett synkroniserat tillstånd. Databasen kommer inte längre att vara i Återställning när den första seedingen har slutförts. Det kan vara tillräckligt snabbt att ta bort små databaser så att du inte ser det inledande återställningstillståndet i SSMS.

Viktigt!

  • Länken fungerar inte om inte nätverksanslutningen finns mellan SQL Server och SQL Managed Instance. Om du vill felsöka nätverksanslutningen följer du stegen i Testa nätverksanslutningen.
  • Gör regelbundna säkerhetskopior av loggfilen på SQL Server. Om det använda loggutrymmet når 100 procent stoppas replikeringen till SQL Managed Instance tills utrymmesanvändningen minskar. Vi rekommenderar starkt att du automatiserar loggsäkerhetskopior genom att konfigurera ett dagligt jobb. Mer information finns i Säkerhetskopiera loggfiler på SQL Server.

Stoppa arbetsbelastning

Om du vill redundansväxla databasen till den sekundära repliken stoppar du först alla programarbetsbelastningar på din primära under underhållstimmarna. Detta gör att databasreplikeringen kan komma ikapp den sekundära filen o du kan migrera eller redundansväxla till Azure utan dataförlust. Även om den primära databasen är en del av en AlwaysOn-tillgänglighetsgrupp kan du inte ställa in den i skrivskyddat läge. Du måste se till att program inte genomför transaktioner till den primära repliken före redundansväxlingen.

Växla replikeringsläge

Replikeringen mellan SQL Server och SQL Managed Instance är asynkron som standard. Innan du redundansväxlar databasen till den sekundära, växlar du länken till synkront läge. Synkron replikering över stora nätverksavstånd kan göra transaktionerna på den primära repliken långsammare.

Om du byter från asynkronisering till synkroniseringsläge krävs en replikeringslägesändring på både SQL Managed Instance och SQL Server.

Växla replikeringsläge (SQL Managed Instance)

Använd antingen Azure PowerShell eller Azure CLI för att växla replikeringsläge på SQL Managed Instance.

Kontrollera först att du är inloggad i Azure och att du har valt den prenumeration där den hanterade instansen finns med hjälp av kommandot Select-AzSubscription PowerShell eller az account set Azure CLI. Det är särskilt viktigt att välja rätt prenumeration om du har fler än en Azure-prenumeration på ditt konto.

I följande PowerShell-exempel ersätter du <SubscriptionID> med ditt Azure-prenumerations-ID.

# 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

Se till att du känner till namnet på länken som du vill redundansväxla. Du kan använda Kommandot Get-AzSqlInstanceLink PowerShell eller az sql mi link list Azure CLI.

Använd följande PowerShell-skript för att visa alla aktiva länkar i SQL Managed Instance. Ersätt <ManagedInstanceName> med det korta namnet på den hanterade instansen.

# 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

Från utdata från föregående skript registrerar Name du egenskapen för länken som du vill redundansväxla.

Växla sedan replikeringsläget från asynkronisering till att synkronisera på SQL Managed Instance för den identifierade länken med hjälp av Kommandot Update-AzSqlInstanceLink PowerShell eller az sql mi link update Azure CLI.

I följande PowerShell-exempel ersätter du:

  • <ManagedInstanceName> med det korta namnet på den hanterade instansen.
  • <DAGName> med namnet på länken som du fick reda på i föregående steg (egenskapen Name från föregående steg).
# 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"

Föregående kommando anger att åtgärden lyckades genom att visa en sammanfattning av åtgärden, med egenskapen ReplicationMode som visas som Sync.

Om du behöver återställa åtgärden kör du det tidigare skriptet för att växla replikeringsläget men ersätter strängen Sync -ReplicationMode i till Async.

Växla replikeringsläge (SQL Server)

Använd följande T-SQL-skript på SQL Server för att ändra replikeringsläget för den distribuerade tillgänglighetsgruppen på SQL Server från asynkronisering till synkronisering. Ersätta:

  • <DAGName> med namnet på den distribuerade tillgänglighetsgruppen (används för att skapa länken).
  • <AGName> med namnet på tillgänglighetsgruppen som skapats på SQL Server (används för att skapa länken).
  • <ManagedInstanceName> med namnet på din hanterade instans.
-- 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);

Om du vill bekräfta att du har ändrat länkens replikeringsläge använder du följande dynamiska hanteringsvy. Resultaten anger tillståndet 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

Nu när du har bytt både SQL Managed Instance och SQL Server till synkroniseringsläge är replikeringen mellan de två instanserna synkron. Om du behöver återställa det här tillståndet följer du samma steg och anger tillståndet till async för både SQL Server och SQL Managed Instance.

Kontrollera LSN-värden på både SQL Server och SQL Managed Instance

Bekräfta att replikeringen är klar för att slutföra redundansväxlingen eller migreringen. För detta kontrollerar du att loggsekvensnumren (LSN) i loggposterna för både SQL Server och SQL Managed Instance är desamma.

Inledningsvis förväntas LSN på den primära vara högre än LSN på den sekundära. Nätverksfördröjningen kan leda till att replikeringen ligger något efter den primära. Eftersom arbetsbelastningen har stoppats på den primära bör du förvänta dig att LSN:erna matchar och slutar ändras efter en viss tid.

Använd följande T-SQL-fråga på SQL Server för att läsa LSN för den senaste registrerade transaktionsloggen. Ersätta:

  • <DatabaseName> med databasnamnet och leta efter det senaste härdade LSN-numret.
-- 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>'

Använd följande T-SQL-fråga på SQL Managed Instance för att läsa den senaste härdade LSN för databasen. Ersätt <DatabaseName> med databasnamnet.

Den här frågan fungerar på en sql-hanterad instans för generell användning. För en Affärskritisk SQL Managed Instance avkommenteras and drs.is_primary_replica = 1 i slutet av skriptet. På tjänstnivån Affärskritisk ser det här filtret till att information endast läse från den primära repliken.

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

Du kan också använda Länken Get-AzSqlInstanceLink PowerShell eller az sql mi show Azure CLI för att hämta LastHardenedLsn egenskapen för din länk i SQL Managed Instance för att ange samma information som föregående T-SQL-fråga.

Viktigt!

Kontrollera återigen att din arbetsbelastning har stoppats på den primära. Kontrollera att LSN:er på både SQL Server och SQL Managed Instance matchar och att de förblir matchade och oförändrade under en tid. Stabila LSN på båda instanserna indikerar att tail-loggen har replikerats till den sekundära och att arbetsbelastningen stoppas effektivt.

Redundansvä redundansväsna en databas

Om du vill använda PowerShell för att redundansväxla en databas mellan SQL Server 2022 och SQL Managed Instance samtidigt som du behåller länken, eller om du vill utföra en redundansväxling med dataförlust för någon version av SQL Server, använder du guiden Redundans mellan SQL Server och Hanterad instans i SSMS för att generera skriptet för din miljö. Du kan utföra en planerad redundansväxling från antingen den primära eller den sekundära repliken. Om du vill göra en tvingad redundansväxling ansluter du till den sekundära repliken.

Om du vill bryta länken och stoppa replikeringen när du redundansväxlar eller migrerar databasen oavsett SQL Server-version använder du Kommandot Remove-AzSqlInstanceLink PowerShell eller az sql mi link delete Azure CLI.

Varning

  • Innan du redundansväxlar stoppar du arbetsbelastningen på källdatabasen så att den replikerade databasen kan komma ifatt och redundansväxla helt utan dataförlust. Om du utför en tvingad redundansväxling, eller om du bryter länken innan LSN matchar, kan du förlora data.
  • Redväxlar en databas i SQL Server 2019 och tidigare versioner bryter och tar bort länken mellan de två replikerna. Du kan inte växla tillbaka till den första primära.
  • Rederovera en databas samtidigt som länken med SQL Server 2022 finns för närvarande i förhandsversion.

Följande exempelskript bryter länken och avslutar replikeringen mellan dina repliker, vilket gör att databasen läser/skriver på båda instanserna. Ersätta:

  • <ManagedInstanceName> med namnet på din hanterade instans.
  • <DAGName> med namnet på länken du reder över (utdata från egenskapen Name från Get-AzSqlInstanceLink kommandot som kördes tidigare ovan).
# 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

När redundansväxlingen lyckas tas länken bort och finns inte längre. SQL Server-databasen och SQL Managed Instance-databasen kan båda köra en läs-/skrivarbetsbelastning. De är helt oberoende. Ange om programmet anslutningssträng till den databas som du vill använda aktivt.

Viktigt!

När redundansväxlingen till SQL Managed Instance har slutfört migreringen eller redundansväxlingen manuellt och fortsätter att köras i Azure om du har redundansväxla dina anslutningssträng program till sql-hanterade instansens FQDN.

Rensa tillgänglighetsgrupper

Eftersom redigering med SQL Server 2022 inte bryter länken kan du välja att låta länk- och tillgänglighetsgrupperna vara kvar.

Om du bestämmer dig för att bryta länken, eller om du redviker med SQL Server 2019 och tidigare versioner, måste du släppa den distribuerade tillgänglighetsgruppen för att ta bort länkmetadata från SQL Server. Du kan dock välja att behålla tillgänglighetsgruppen på SQL Server.

Om du vill rensa resurser för tillgänglighetsgruppen ersätter du följande värden och kör sedan exempelkoden: Ersätt i följande kod:

  • <DAGName> med namnet på den distribuerade tillgänglighetsgruppen på SQL Server (används för att skapa länken).
  • <AGName> med namnet på tillgänglighetsgruppen på SQL Server (används för att skapa länken).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

Felsöka

Avsnittet innehåller vägledning för att åtgärda problem med att konfigurera och använda länken.

Fel

Om du får ett felmeddelande när du skapar länken eller redundansväxlar en databas läser du felmeddelandet i frågeutdatafönstret för mer information.

Om du får ett fel när du arbetar med länken slutar frågan att köras i det misslyckade steget. När feltillståndet har lösts kör du kommandot igen för att fortsätta med åtgärden.

Inkonsekvent tillstånd efter tvingad redundans

Om du använder tvingad redundans kan det resultera i ett inkonsekvent tillstånd mellan de primära och sekundära replikerna, vilket orsakar ett scenario med delad hjärna från båda replikerna som har samma roll. Datareplikeringen misslyckas i det här tillståndet tills användaren löser situationen genom att manuellt ange en replik som primär och den andra repliken som sekundär.

Relaterat innehåll

Mer information om länkfunktionen finns i följande resurser: