Konfigurera länk med skript – Azure SQL Managed Instance
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 växla över till den sekundära repliken för migrering eller katastrofåterställning.
Note
- Det går också att konfigurera länken med SQL Server Management Studio (SSMS).
- Du kan konfigurera Azure SQL Managed Instance som din första primära instans från och med SQL Server 2022 CU10.
Överblick
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 databasen från den första primära till den sekundära repliken.
Du kan välja att behålla länken för kontinuerlig replikering av data i en hybridmiljö mellan den primära och sekundära repliken, eller så kan du växla över databasen till den sekundära repliken för haveriberedskap eller migrera till Azure. För SQL Server 2019 och tidigare versioner innebär en övergång till Azure SQL Managed Instance att länken bryts och återställning understöds inte. Med SQL Server 2022 har du möjlighet att underhålla länken och växla fram och tillbaka mellan de två replikerna.
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å din sekundära målreplika.
Tips
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änken ny hanterad instans väljer du Skript i stället för Slutför.
Förutsättningar
För att replikera dina databaser behöver du följande krav:
- En aktiv Azure-prenumeration. Om du inte har ett skapa ett kostnadsfritt konto.
- version av SQL Server som stöds med nödvändig tjänstuppdatering installerad.
- Azure SQL Managed Instance. Kom igång om du inte har det redan.
- PowerShell-modulen Az.SQL 6.0.0 eller senareeller Azure CLI 2.67.0 eller senare. Eller använd helst Azure Cloud Shell- online från webbläsaren för att köra kommandona, eftersom det alltid uppdateras med de senaste modulversionerna.
- En korrekt förberedd miljö.
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å din ursprungliga primära SQL-server indikerar att du måste starta en ny säkerhetskopieringskedja genom att skapa en full säkerhetskopia utan att använda alternativet
COPY ONLY
. - Om du vill upprätta en länk, eller failover, från SQL Managed Instance till SQL Server 2022 måste din hanterade instans konfigureras med SQL Server 2022 uppdateringspolicy. Datareplikering och redundans från SQL Managed Instance till SQL Server 2022 stöds inte av instanser som konfigurerats med uppdateringsprincipen Always-up-to-date.
- Du kan upprätta en länk från SQL Server 2022 till en SQL-hanterad instans som konfigurerats med uppdateringsprincipen Always-up-to-date, men efter redundansväxling till SQL Managed Instance kan du inte längre replikera data eller återställa till SQL Server 2022.
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-deltagareeller ha följande anpassade rollbehörigheter:
Microsoft.Sql/-resurs | Nödvändiga behörigheter |
---|---|
Microsoft.Sql/managedInstances | /read, /write |
Microsoft.Sql/managedInstances/hybridCertificate | /handling |
Microsoft.Sql/managedInstances/databases | /läs, /radera, /skriv, /återställningKomplett/åtgärd, /läsBackuper/åtgärd, /återställDetajler/läs |
Microsoft.Sql/managedInstances/distributedAvailabilityGroups | /läs, /skriv, /radera, /sättRoll/åtgärd |
Microsoft.Sql/managedInstances/endpointCertificates | /läsa |
Microsoft.Sql/managedInstances/hybridLink | /läsa, /skriva, /radera |
Microsoft.Sql/managedInstances/serverTrustCertificates | /skriv, /radera, /läsa |
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 |
---|---|---|
Första primära 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 kopia | 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 namn för SQL Managed Instance med ett enda 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. |
Lösbart domännamn | DNS-namn som kan matchas till en IP-adress. Om du till exempel kör nslookup sqlserver1.domain.com ska du returnera en IP-adress, till exempel 10.0.0.1. |
Kör kommandot nslookup 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 kommandot ipconfig från kommandotolken för värdoperativsystemet som kör SQL Server. |
1 Konfigurera Azure SQL Managed Instance som din ursprungliga primära instans stöds 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.
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.
Note
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änglighetsgruppen databasspeglingsslutpunkti 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.
Note
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.
Viktig
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:
- Generera ett certifikat på SQL Server och hämta dess offentliga nyckel.
- Hämta en offentlig nyckel för SQL Managed Instance-certifikatet.
- Byt ut de offentliga nycklarna mellan SQL Server och SQL Managed Instance.
- 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 master
-databasen, om den 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.
Viktig
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 New-AzSqlInstanceServerTrustCertificate PowerShell eller az sql mi partner-cert create Azure CLI-kommando 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 med0x
. -
<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 Get-AzSqlInstanceServerTrustCertificate PowerShell eller az sql mi partner-cert list Azure CLI-kommandot 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 Get-AzSqlInstanceEndpointCertificate PowerShell eller az sql mi endpoint-cert show Azure CLI-kommando, till exempel följande PowerShell-exempel.
Försiktighet
När du använder Azure CLI måste du manuellt lägga till 0x
framför 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
) som du behöver 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 för att skapa MI-slutpunktscertifikatet. 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, med början i0x
). Du behöver inte använda citattecken.
Viktig
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.
Försiktighet
Kontrollera att PublicKey börjar med en 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ärdarcertifikatet 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 = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3300D06092A864886F70D01010C05003065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F726974792032303137301E170D3139313231383232353132325A170D3432303731383233303032335A3065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F72697479203230313730820222300D06092A864886F70D01010105000382020F003082020A0282020100CA5BBE94338C299591160A95BD4762C189F39936DF4690C9A5ED786A6F479168F8276750331DA1A6FBE0E543A3840257015D9C4840825310BCBFC73B6890B6822DE5F465D0CC6D19CC95F97BAC4A94AD0EDE4B431D8707921390808364353904FCE5E96CB3B61F50943865505C1746B9B685B51CB517E8D6459DD8B226B0CAC4704AAE60A4DDB3D9ECFC3BD55772BC3FC8C9B2DE4B6BF8236C03C005BD95C7CD733B668064E31AAC2EF94705F206B69B73F578335BC7A1FB272AA1B49A918C91D33A823E7640B4CD52615170283FC5C55AF2C98C49BB145B4DC8FF674D4C1296ADF5FE78A89787D7FD5E2080DCA14B22FBD489ADBACE479747557B8F45C8672884951C6830EFEF49E0357B64E798B094DA4D853B3E55C428AF57F39E13DB46279F1EA25E4483A4A5CAD513B34B3FC4E3C2E68661A45230B97A204F6F0F3853CB330C132B8FD69ABD2AC82DB11C7D4B51CA47D14827725D87EBD545E648659DAF5290BA5BA2186557129F68B9D4156B94C4692298F433E0EDF9518E4150C9344F7690ACFC38C1D8E17BB9E3E394E14669CB0E0A506B13BAAC0F375AB712B590811E56AE572286D9C9D2D1D751E3AB3BC655FD1E0ED3740AD1DAAAEA69B897288F48C407F852433AF4CA55352CB0A66AC09CF9F281E1126AC045D967B3CEFF23A2890A54D414B92AA8D7ECF9ABCD255832798F905B9839C40806C1AC7F0E3D00A50203010001A3543052300E0603551D0F0101FF040403020186300F0603551D130101FF040530030101FF301D0603551D0E0416041409CB597F86B2708F1AC339E3C0D9E9BFBB4DB223301006092B06010401823715010403020100300D06092A864886F70D01010C05000382020100ACAF3E5DC21196898EA3E792D69715B813A2A6422E02CD16055927CA20E8BAB8E81AEC4DA89756AE6543B18F009B52CD55CD53396D624C8B0D5B7C2E44BF83108FF3538280C34F3AC76E113FE6E3169184FB6D847F3474AD89A7CEB9D7D79F846492BE95A1AD095333DDEE0AEA4A518E6F55ABBAB59446AE8C7FD8A2502565608046DB3304AE6CB598745425DC93E4F8E355153DB86DC30AA412C169856EDF64F15399E14A75209D950FE4D6DC03F15918E84789B2575A94B6A9D8172B1749E576CBC156993A37B1FF692C919193E1DF4CA337764DA19FF86D1E1DD3FAECFBF4451D136DCFF759E52227722B86F357BB30ED244DDC7D56BBA3B3F8347989C1E0F20261F7A6FC0FBB1C170BAE41D97CBD27A3FD2E3AD19394B1731D248BAF5B2089ADB7676679F53AC6A69633FE5392C846B11191C6997F8FC9D66631204110872D0CD6C1AF3498CA6483FB1357D1C1F03C7A8CA5C1FD9521A071C193677112EA8F880A691964992356FBAC2A2E70BE66C40C84EFE58BF39301F86A9093674BB268A3B5628FE93F8C7A3B5E0FE78CB8C67CEF37FD74E2C84F3372E194396DBD12AFBE0C4E707C1B6F8DB332937344166DE8F4F7E095808F965D38A4F4ABDE0A308793D84D00716245274B3A42845B7F65B76734522D9C166BAAA8D87BA3424C71C70CCA3E83E4A6EFB701305E51A379F57069A641440F86B02C91C63DEAAE0F84
--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 exists.'
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 = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D09FAE5300D06092A864886F70D01010B05003061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F74204732301E170D3133303830313132303030305A170D3338303131353132303030305A3061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F7420473230820122300D06092A864886F70D01010105000382010F003082010A0282010100BB37CD34DC7B6BC9B26890AD4A75FF46BA210A088DF51954C9FB88DBF3AEF23A89913C7AE6AB061A6BCFAC2DE85E092444BA629A7ED6A3A87EE054752005AC50B79C631A6C30DCDA1F19B1D71EDEFDD7E0CB948337AEEC1F434EDD7B2CD2BD2EA52FE4A9B8AD3AD499A4B625E99B6B00609260FF4F214918F76790AB61069C8FF2BAE9B4E992326BB5F357E85D1BCD8C1DAB95049549F3352D96E3496DDD77E3FB494BB4AC5507A98F95B3B423BB4C6D45F0F6A9B29530B4FD4C558C274A57147C829DCD7392D3164A060C8C50D18F1E09BE17A1E621CAFD83E510BC83A50AC46728F67314143D4676C387148921344DAF0F450CA649A1BABB9CC5B1338329850203010001A3423040300F0603551D130101FF040530030101FF300E0603551D0F0101FF040403020186301D0603551D0E041604144E2254201895E6E36EE60FFAFAB912ED06178F39300D06092A864886F70D01010B05000382010100606728946F0E4863EB31DDEA6718D5897D3CC58B4A7FE9BEDB2B17DFB05F73772A3213398167428423F2456735EC88BFF88FB0610C34A4AE204C84C6DBF835E176D9DFA642BBC74408867F3674245ADA6C0D145935BDF249DDB61FC9B30D472A3D992FBB5CBBB5D420E1995F534615DB689BF0F330D53E31E28D849EE38ADADA963E3513A55FF0F970507047411157194EC08FAE06C49513172F1B259F75F2B18E99A16F13B14171FE882AC84F102055D7F31445E5E044F4EA879532930EFE5346FA2C9DFF8B22B94BD90945A4DEA4B89A58DD1B7D529F8E59438881A49E26D56FADDD0DC6377DED03921BE5775F76EE3C8DC45D565BA2D9666EB33537E532B6
--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 exists.'
GO
Kontrollera slutligen alla skapade certifikat med hjälp av följande dynamiska hanteringsvy (DMV):
-- Run on SQL Server
SELECT * FROM sys.certificates
Verifiera certifikatet
När du har skapat certifikaten verifierar du att MI-slutpunktscertifikatet har konfigurerats korrekt.
Bestäm först certificate_id
för det exporterade MI-certifikatet genom att ersätta värdet för <ManagedInstanceFQDN>
och sedan köra följande fråga på SQL Server:
-- Run on SQL Server
USE MASTER
GO
SELECT name, subject, certificate_id, start_date, expiry_date
FROM sys.certificates
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>'
GO
Verifiera sedan certifikatet genom att ersätta värdet för <certificate_id>
från resultatet av föregående fråga och sedan köra följande fråga på SQL Server:
-- Run on SQL Server
USE MASTER
GO
EXEC sp_validate_certificate_ca_chain <certificate_id>
GO
Ett svar på Commands completed successfully. Completion time: …
anger att MI-slutpunktscertifikatet har verifierats.
Om du får ett fel släpper du certifikatet och följer stegen i Hämta den offentliga certifikatnyckeln från SQL Managed Instance och importerar den till SQL Server-avsnittet för att importera certifikatet igen.
Om du vill släppa certifikatet kör du följande fråga på SQL Server:
-- Run on SQL Server
USE MASTER
GO
DROP CERTIFICATE [<ManagedInstanceFQDN>]
GO
Säkerställ 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 <EndpointPort>
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=<EndpointPort>, 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
Den framgångsrikt skapade slutpunktskolumnen state_desc ska ha statusen STARTED
.
En ny speglingsslutpunkt skapades med certifikatautentisering och AES-kryptering aktiverat.
Ändra en befintlig slutpunkt
Note
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
. - Anslutningsautentisering 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 är CERTIFICATE
eller encryption_algorithm_desc
inte är AES
, 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 din connection_auth_desc
slutpunkt ä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. För detaljer om möjliga alternativ för att ändra slutpunkter, se 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=<EndpointPort>, 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åga 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 framgångsrikt ändrat databasspeglingsslutpunkten för en hanterad SQL-instanslä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.
Note
Hoppa över det här avsnittet om du redan har en befintlig tillgänglighetsgrupp.
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.
- Inledande primära för SQL Server
- inledande primära SQL MI-
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 seedningslä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:
-
<AGNameOnSQLServer>
med namnet på din tillgänglighetsgrupp på SQL Server. 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 exempelAG_<db_name>
. -
<DatabaseName>
med namnet på databasen som du vill replikera. -
<SQLServerName>
med namnet på din SQL Server-instans som erhölls i föregående steg. -
<SQLServerIP>
tillsammans med SQL Serverns IP-adress. 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 [<AGNameOnSQLServer>]
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>:<EndpointPort>',
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC
);
GO
Viktig
För SQL Server 2016 tar du bort WITH (CLUSTER_TYPE = NONE)
från ovanstående T-SQL-instruktion. Lämna as-is 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 exempelDAG1_<db_name>
,DAG2_<db_name>
. -
<AGNameOnSQLServer>
med namnet på tillgänglighetsgruppen som du skapade i föregående steg. -
<AGNameOnSQLMI>
med namnet på din tillgänglighetsgrupp på SQL Managed Instance. Namnet måste vara unikt för SQL MI. Överväg att namnge varje tillgänglighetsgrupp så att dess namn återspeglar motsvarande databas, till exempelAG_<db_name>_MI
. -
<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'<AGNameOnSQLServer>' WITH
(
LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC,
SESSION_TIMEOUT = 20
),
N'<AGNameOnSQLMI>' 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 till connected
bara när den är ansluten till 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 Availability Groups.
Skapa en länk
Slutligen kan du skapa länken. Kommandona skiljer sig åt beroende på vilken instans som är den första primära. Använd New-AzSqlInstanceLink PowerShell eller az sql mi link create Azure CLI-kommando 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 kommandot Get-AzSqlInstanceLink PowerShell eller az sql mi link show Azure CLI-kommandot i Azure Cloud Shell.
- Inledande primära för SQL Server
- inledande primära SQL MI-
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. -
<AGNameOnSQLServer>
med namnet på tillgänglighetsgruppen som skapats på SQL Server. -
<AGNameOnSQLMI>
med namnet på tillgänglighetsgruppen som skapats på SQL Managed Instance. -
<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.
Note
Om du vill upprätta en länk till en tillgänglighetsgrupp som redan finns anger du IP-adressen för lyssnaren när du anger parametern <SQLServerIP>
. Kontrollera att förtroende har upprättats mellan alla tillgänglighetsgruppnoder och SQL Managed Instance (se Upprätta förtroende mellan instanser avsnittet).
# 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
$AGNameOnSQLServer = "<AGNameOnSQLServer>"
# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"
# 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 + ":<EndpointPort>"
# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $SourceIP -InstanceLinkRole Secondary
Resultatet av den här åtgärden är en tidsstämpel för den lyckade körningen av begäran att skapa en länk .
Verifiera länken
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ällnings tillstånd när den inledande seeding-fasen flyttar 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ällningsläge efter att den initiala seedingen har slutförts. Det kan gå så snabbt att fylla små databaser att du inte ser det inledande återställningstillståndet i SSMS.
Viktig
- 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.
Gör den första säkerhetskopieringen av transaktionsloggen
Om SQL Server är din första primära, är det viktigt att ta den första säkerhetskopieringen av transaktionsloggen på SQL Server när inledande seeding har slutförts, när databasen inte längre är i Återställning... tillstånd på Azure SQL Managed Instance. Ta sedan säkerhetskopieringar av SQL Server-transaktionsloggar regelbundet för att minimera överdriven loggtillväxt medan SQL Server är i den primära rollen.
Om SQL Managed Instance är din primära, behöver du inte vidta några åtgärder eftersom Azure SQL Managed Instance tar loggsäkerhetskopior automatiskt.
Släpp en länk
Om du vill släppa länken, antingen för att den inte längre behövs eller för att den är i ett irreparabelt tillstånd och måste återskapas, kan du göra det med PowerShell och T-SQL.
Använd först kommandot Remove-AzSqlInstanceLink PowerShell för att släppa länken, till exempel följande exempel:
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $managedInstanceName -Name $DAGName -Force
Kör sedan följande T-SQL-skript på SQL Server för att släppa den distribuerade tillgänglighetsgruppen. Ersätt <DAGName>
med namnet på den distribuerade tillgänglighetsgrupp som används för att skapa länken:
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName>
GO
Slutligen kan du ta bort tillgänglighetsgruppen om du inte längre har någon användning för den. Det gör du genom att ersätta <AGName>
med namnet på tillgänglighetsgruppen och sedan köra den på respektive instans:
DROP AVAILABILITY GROUP <AGName>
GO
Felsöka
Om du får ett felmeddelande när du skapar länken läser du felmeddelandet i frågeutdatafönstret för mer information. Mer information finns i felsöka problem med länken.
Relaterat innehåll
Så här använder du länken:
- Förbered miljön för länken för hanterad instans
- Konfigurera länk mellan SQL Server och SQL Managed Instance med SSMS
- Felövergång över länken
- Migrera med länken
- Metodtips för att upprätthålla länken
- Felsöka problem med länken
Om du vill veta mer om länken:
Överväg följande för andra replikerings- och migreringsscenarier: