Delen via

Koppeling met scripts configureren - Azure SQL Managed Instance

  • Artikel

Van toepassing op: Azure SQL Managed Instance

In dit artikel leert u hoe u een koppeling configureert tussen SQL Server en Azure SQL Managed Instance met Transact-SQL- en PowerShell- of Azure CLI-scripts. Met de koppeling worden databases van uw eerste primaire replica in bijna realtime gerepliceerd naar uw secundaire replica.

Nadat de koppeling is gemaakt, kunt u vervolgens een failover naar uw secundaire replica uitvoeren voor migratie of herstel na noodgevallen.

Notitie

Overzicht

Gebruik de koppelingsfunctie om databases van uw eerste primaire naar uw secundaire replica te repliceren. Voor SQL Server 2022 kan de eerste primaire server of Azure SQL Managed Instance zijn. Voor SQL Server 2019 en eerdere versies moet de eerste primaire versie SQL Server zijn. Nadat de koppeling is geconfigureerd, worden databases van de eerste primaire replica gerepliceerd naar de secundaire replica.

U kunt ervoor kiezen om de koppeling te behouden voor continue gegevensreplicatie in een hybride omgeving tussen de primaire en secundaire replica, of u kunt een failover van de database naar de secundaire replica uitvoeren, migreren naar Azure of herstel na noodgevallen. Voor SQL Server 2019 en eerdere versies wordt een failover naar Azure SQL Managed Instance de koppeling verbroken en wordt failback niet ondersteund. Met SQL Server 2022 hebt u de mogelijkheid om de koppeling te onderhouden en heen en weer te schakelen tussen de twee replica's. Deze functie is momenteel in preview.

Als u van plan bent om uw secundaire beheerde exemplaar alleen te gebruiken voor herstel na noodgevallen, kunt u besparen op licentiekosten door het voordeel van de hybride failover te activeren.

Gebruik de instructies in dit artikel om de koppeling tussen SQL Server en Azure SQL Managed Instance handmatig in te stellen. Nadat de koppeling is gemaakt, krijgt uw brondatabase een alleen-lezen kopie op uw secundaire doelreplica.

Tip

  • Om het gebruik van T-SQL-scripts met de juiste parameters voor uw omgeving te vereenvoudigen, raden we u ten zeerste aan de wizard Managed Instance te gebruiken in SQL Server Management Studio (SSMS) om een script te genereren om de koppeling te maken. Selecteer Op de overzichtspagina van het koppelingsvenster Nieuw beheerd exemplaar het script in plaats van Voltooien.

Vereisten

Notitie

Sommige functionaliteit van de koppeling is algemeen beschikbaar, terwijl sommige momenteel in preview zijn. Bekijk de ondersteuningsmogelijkheden voor versies voor meer informatie.

Als u uw databases wilt repliceren, hebt u de volgende vereisten nodig:

Denk aan het volgende:

  • De koppelingsfunctie ondersteunt één database per koppeling. Als u meerdere databases op een exemplaar wilt repliceren, maakt u een koppeling voor elke afzonderlijke database. Als u bijvoorbeeld 10 databases wilt repliceren naar SQL Managed Instance, maakt u 10 afzonderlijke koppelingen.
  • Sortering tussen SQL Server en SQL Managed Instance moet hetzelfde zijn. Een niet-overeenkomende sortering kan ertoe leiden dat de naam van de server niet overeenkomt en dat er geen verbinding kan worden gemaakt tussen SQL Server en SQL Managed Instance.
  • Fout 1475 op de eerste SQL Server-primaire instantie geeft aan dat u een nieuwe back-upketen moet starten door een volledige back-up te maken zonder de COPY ONLY optie.

Bevoegdheden

Voor SQL Server moet u sysadmin-machtigingen hebben.

Voor Azure SQL Managed Instance moet u lid zijn van de inzender voor SQL Managed Instance of de volgende aangepaste rolmachtigingen hebben:

Microsoft.Sql/ resource Benodigde machtigingen
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /actie
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 /Lezen
Microsoft.Sql/managedInstances/hybridLink /read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

Terminologie- en naamconventies

Wanneer u scripts uitvoert vanuit deze gebruikershandleiding, is het belangrijk om sql Server- en SQL Managed Instance-namen niet te maken voor hun FQDN's (Fully Qualified Domain Names). In de volgende tabel wordt uitgelegd wat de verschillende namen precies vertegenwoordigen en hoe u hun waarden kunt verkrijgen:

Terminologie Beschrijving Meer informatie
Eerste primaire 1 De SQL Server- of SQL Managed Instance waarin u in eerste instantie de koppeling maakt om uw database te repliceren naar de secundaire replica.
Primaire replica De SQL Server of SQL Managed Instance die momenteel als host fungeert voor de primaire database.
Secundaire replica De SQL Server of SQL Managed Instance die bijna realtime gerepliceerde gegevens van de huidige primaire replica ontvangt.
SQL Server-naam Korte, SQL Server-naam met één woord. Bijvoorbeeld: sqlserver1. Uitvoeren SELECT @@SERVERNAME vanuit T-SQL.
SQL Server-FQDN FQDN (Fully Qualified Domain Name) van uw SQL Server. Bijvoorbeeld: sqlserver1.domain.com. Bekijk uw netwerkconfiguratie (DNS) on-premises of de servernaam als u een virtuele Azure-machine (VM) gebruikt.
Naam van met SQL beheerd exemplaar Korte naam van SQL Managed Instance met één woord. Bijvoorbeeld: managedinstance1. Bekijk de naam van uw beheerde exemplaar in Azure Portal.
SQL Managed Instance FQDN FQDN (Fully Qualified Domain Name) van uw SQL Managed Instance. Bijvoorbeeld: managedinstance1.6d710bcf372b.database.windows.net. Zie de hostnaam op de overzichtspagina van SQL Managed Instance in Azure Portal.
Omzetbare domeinnaam DNS-naam die kan worden omgezet in een IP-adres. Als u bijvoorbeeld een IP-adres wilt uitvoeren nslookup sqlserver1.domain.com , bijvoorbeeld 10.0.0.1. Voer nslookup de opdracht uit vanaf de opdrachtprompt.
IP-adres van SQL Server IP-adres van uw SQL Server. Als u meerdere IP-adressen op SQL Server gebruikt, kiest u het IP-adres dat toegankelijk is vanuit Azure. Voer ipconfig de opdracht uit vanaf de opdrachtprompt van het host-besturingssysteem waarop de SQL Server wordt uitgevoerd.

1 Azure SQL Managed Instance configureren als uw eerste primaire exemplaar is momenteel in preview en alleen ondersteund vanaf SQL Server 2022 CU10.

Databaseherstel en back-up instellen

Als SQL Server de eerste primaire server is, moeten databases die via de koppeling worden gerepliceerd, zich in het volledige herstelmodel bevinden en ten minste één back-up hebben. Aangezien Azure SQL Managed Instance automatisch back-ups maakt, slaat u deze stap over als SQL Managed Instance uw eerste primaire exemplaar is. primair

Voer de volgende code uit op SQL Server voor alle databases die u wilt repliceren. Vervang door <DatabaseName> de werkelijke databasenaam.

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

Zie Een volledige databaseback-up maken voor meer informatie.

Notitie

De koppeling ondersteunt alleen replicatie van gebruikersdatabases. Replicatie van systeemdatabases wordt niet ondersteund. Als u objecten op exemplaarniveau wilt repliceren (opgeslagen in master of msdb databases), raden we u aan deze uit te voeren en T-SQL-scripts uit te voeren op het doelexemplaren.

Vertrouwen tussen exemplaren tot stand brengen

Eerst moet u een vertrouwensrelatie tussen de twee instanties tot stand brengen en de eindpunten beveiligen die worden gebruikt om gegevens in het netwerk te communiceren en te versleutelen. Gedistribueerde beschikbaarheidsgroepen gebruiken het bestaande eindpunt voor databasespiegeling voor beschikbaarheidsgroepen in plaats van hun eigen toegewezen eindpunt. Daarom moeten beveiliging en vertrouwen worden geconfigureerd tussen de twee exemplaren via het eindpunt voor het spiegelen van de beschikbaarheidsgroepdatabase.

Notitie

De koppeling is gebaseerd op de AlwaysOn-technologie voor beschikbaarheidsgroepen. Het eindpunt voor databasespiegeling is een eindpunt voor speciaal gebruik dat uitsluitend wordt gebruikt door beschikbaarheidsgroepen om verbindingen van andere exemplaren te ontvangen. Het eindpunt voor het spiegelen van de term database mag niet worden verward met de verouderde functie voor het spiegelen van SQL Server-databases.

Vertrouwen op basis van certificaten is de enige ondersteunde manier om eindpunten voor databasespiegeling te beveiligen voor SQL Server en SQL Managed Instance. Als u bestaande beschikbaarheidsgroepen hebt die gebruikmaken van Windows-verificatie, moet u een vertrouwensrelatie op basis van certificaten toevoegen aan het bestaande mirroring-eindpunt als een secundaire verificatieoptie. U kunt dit doen met behulp van de ALTER ENDPOINT instructie, zoals verderop in dit artikel wordt weergegeven.

Belangrijk

Certificaten worden gegenereerd met een vervaldatum en -tijd. Ze moeten worden vernieuwd en gedraaid voordat ze verlopen.

Hieronder vindt u een overzicht van het proces voor het beveiligen van eindpunten voor databasespiegeling voor zowel SQL Server als SQL Managed Instance:

  1. Genereer een certificaat op SQL Server en haal de bijbehorende openbare sleutel op.
  2. Haal een openbare sleutel op van het SQL Managed Instance-certificaat.
  3. De openbare sleutels uitwisselen tussen SQL Server en SQL Managed Instance.
  4. Azure-vertrouwde basiscertificeringsinstantiesleutels importeren in SQL Server

In de volgende secties worden deze stappen gedetailleerd beschreven.

Een certificaat maken op SQL Server en de bijbehorende openbare sleutel importeren in SQL Managed Instance

Maak eerst de hoofdsleutel van de database in de master database als deze nog niet aanwezig is. Voeg uw wachtwoord in plaats van <strong_password> het volgende script in en bewaar het op een vertrouwelijke en veilige plaats. Voer dit T-SQL-script uit op 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

Genereer vervolgens een verificatiecertificaat op SQL Server. Vervang in het volgende script:

  • @cert_expiry_date met de gewenste vervaldatum van het certificaat (toekomstige datum).

Noteer deze datum en stel een herinnering in om het SQL Server-certificaat vóór de vervaldatum te draaien (bij te werken) om continue werking van de koppeling te garanderen.

Belangrijk

Het wordt sterk aanbevolen om de automatisch gegenereerde certificaatnaam van dit script te gebruiken. Hoewel het aanpassen van uw eigen certificaatnaam op SQL Server is toegestaan, mag de naam geen \ tekens bevatten.

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

Gebruik vervolgens de volgende T-SQL-query op SQL Server om te controleren of het certificaat is gemaakt:

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

In de queryresultaten ziet u dat het certificaat is versleuteld met de hoofdsleutel.

Nu kunt u de openbare sleutel van het gegenereerde certificaat op SQL Server ophalen:

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

Sla waarden van SQLServerCertName en SQLServerPublicKey uit de uitvoer op, omdat u deze nodig hebt voor de volgende stap wanneer u het certificaat importeert.

Zorg er eerst voor dat u bent aangemeld bij Azure en dat u het abonnement hebt geselecteerd waarop uw beheerde exemplaar wordt gehost. Het selecteren van het juiste abonnement is vooral belangrijk als u meer dan één Azure-abonnement in uw account hebt.

Vervang <SubscriptionID> door de id van uw Azure-abonnement.

# 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

Gebruik vervolgens de Opdracht New-AzSqlInstanceServerTrustCertificate PowerShell of az sql mi partner-cert create Azure CLI om de openbare sleutel van het verificatiecertificaat van SQL Server naar Azure te uploaden, zoals het volgende PowerShell-voorbeeld.

Vul de benodigde gebruikersgegevens in, kopieer deze, plak deze en voer het script uit. Vervangen:

  • <SQLServerPublicKey> met het openbare gedeelte van het SQL Server-certificaat in binaire indeling, die u in de vorige stap hebt vastgelegd. Het is een lange tekenreekswaarde die begint met 0x.
  • <SQLServerCertName> met de naam van het SQL Server-certificaat dat u in de vorige stap hebt vastgelegd.
  • <ManagedInstanceName> met de korte naam van uw beheerde exemplaar.
# 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

Het resultaat van deze bewerking is een samenvatting van het geüploade SQL Server-certificaat naar Azure.

Als u alle SQL Server-certificaten wilt zien die zijn geüpload naar een beheerd exemplaar, gebruikt u de Azure CLI-opdracht Get-AzSqlInstanceServerTrustCertificate PowerShell of az sql mi partner-cert list in Azure Cloud Shell. Als u een SQL Server-certificaat wilt verwijderen dat is geüpload naar een met SQL beheerd exemplaar, gebruikt u de Opdracht Remove-AzSqlInstanceServerTrustCertificate PowerShell of az sql mi partner-cert delete Azure CLI in Azure Cloud Shell.

Haal de openbare sleutel van het certificaat op uit SQL Managed Instance en importeer deze in SQL Server

Het certificaat voor het beveiligen van het koppelingseindpunt wordt automatisch gegenereerd in Azure SQL Managed Instance. Haal de openbare sleutel van het certificaat op uit SQL Managed Instance en importeer deze in SQL Server met behulp van de Get-AzSqlInstanceEndpointCertificate PowerShell of az sql mi endpoint-cert show Azure CLI-opdracht, zoals het volgende PowerShell-voorbeeld.

Let op

Wanneer u de Azure CLI gebruikt, moet u handmatig toevoegen 0x aan de voorkant van de PublicKey-uitvoer wanneer u deze in de volgende stappen gebruikt. De PublicKey ziet er bijvoorbeeld uit als '0x3082033E30...'.

Voer het volgende script uit. Vervangen:

  • <SubscriptionID> met uw Azure-abonnements-id.
  • <ManagedInstanceName> met de korte naam van uw beheerde exemplaar.
# 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

Kopieer de volledige PublicKey-uitvoer (begint met 0x) omdat u deze in de volgende stap nodig hebt.

Als u problemen ondervindt bij het kopiëren en plakken van de PublicKey, kunt u ook de T-SQL-opdracht EXEC sp_get_endpoint_certificate 4 uitvoeren op het beheerde exemplaar om de openbare sleutel voor het koppelingseindpunt te verkrijgen.

Importeer vervolgens de verkregen openbare sleutel van het beveiligingscertificaat van het beheerde exemplaar naar SQL Server. Voer de volgende query uit op SQL Server. Vervangen:

  • <ManagedInstanceFQDN> met de volledig gekwalificeerde domeinnaam van het beheerde exemplaar.
  • <PublicKey>met de PublicKey-waarde die u in de vorige stap hebt verkregen (vanaf Azure Cloud Shell).0x U hoeft geen aanhalingstekens te gebruiken.

Belangrijk

De naam van het certificaat moet de FQDN van het SQL Managed Instance zijn en mag niet worden gewijzigd. De koppeling is niet operationeel als u een aangepaste naam gebruikt.

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

Azure-vertrouwde basiscertificeringsinstantiesleutels importeren in SQL Server

Het importeren van openbare basiscertificaatsleutels van Microsoft en DigiCert-certificeringsinstanties (CA) naar SQL Server is vereist voor uw SQL Server om certificaten te vertrouwen die zijn uitgegeven door Azure voor database.windows.net domeinen.

Let op

Zorg ervoor dat de PublicKey begint met een 0x. Mogelijk moet u deze handmatig toevoegen aan het begin van de PublicKey als deze nog niet aanwezig is.

Importeer eerst het Microsoft PKI-basiscertificeringsinstantiecertificaat op 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

Importeer vervolgens het DigiCert PKI-basiscertificeringsinstantiecertificaat op 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

Controleer ten slotte alle gemaakte certificaten met behulp van de volgende dynamische beheerweergave (DMV):

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

Het eindpunt voor databasespiegeling beveiligen

Als u geen bestaande beschikbaarheidsgroep of een eindpunt voor databasespiegeling op SQL Server hebt, is de volgende stap het maken van een eindpunt voor databasespiegeling op SQL Server en het beveiligen met het eerder gegenereerde SQL Server-certificaat. Als u wel een bestaande beschikbaarheidsgroep of spiegelingseindpunt hebt, gaat u naar de sectie Een bestaand eindpunt wijzigen.

Het eindpunt voor databasespiegeling maken en beveiligen op SQL Server

Gebruik het volgende script om te controleren of u geen bestaand eindpunt voor databasespiegeling hebt gemaakt:

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

Als in de voorgaande query geen bestaand eindpunt voor databasespiegeling wordt weergegeven, voert u het volgende script uit op SQL Server om de naam van het eerder gegenereerde SQL Server-certificaat op te halen.

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

Sla SQLServerCertName op uit de uitvoer, omdat u deze in de volgende stap nodig hebt.

Gebruik het volgende script om een nieuw eindpunt voor databasespiegeling te maken op poort 5022 en het eindpunt te beveiligen met het SQL Server-certificaat. Vervangen:

  • <SQL_SERVER_CERTIFICATE> met de naam van SQLServerCertName die u in de vorige stap hebt verkregen.
-- 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

Controleer of het eindpunt voor spiegeling is gemaakt door het volgende script uit te voeren op 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

Het gemaakte eindpunt state_desc kolom moet de status STARTEDhebben.

Er is een nieuw mirroring-eindpunt gemaakt met certificaatverificatie en AES-versleuteling ingeschakeld.

Een bestaand eindpunt wijzigen

Notitie

Sla deze stap over als u zojuist een nieuw mirroring-eindpunt hebt gemaakt. Gebruik deze stap alleen als u bestaande beschikbaarheidsgroepen gebruikt met een bestaand eindpunt voor databasespiegeling.

Als u bestaande beschikbaarheidsgroepen voor de koppeling gebruikt of als er een bestaand eindpunt voor databasespiegeling is, controleert u eerst of het voldoet aan de volgende verplichte voorwaarden voor de koppeling:

  • Type moet zijn DATABASE_MIRRORING.
  • Verbinding maken ieverificatie moet zijnCERTIFICATE.
  • Versleuteling moet zijn ingeschakeld.
  • Versleutelingsalgoritmen moeten zijn AES.

Voer de volgende query uit op SQL Server om details voor een bestaand databasespiegelingseindpunt weer te geven:

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

Als de uitvoer laat zien dat het bestaande DATABASE_MIRRORING eindpunt connection_auth_desc niet CERTIFICATEof encryption_algorthm_desc niet AESis, moet het eindpunt worden gewijzigd om te voldoen aan de vereisten.

Op SQL Server wordt hetzelfde eindpunt voor databasespiegeling gebruikt voor zowel beschikbaarheidsgroepen als gedistribueerde beschikbaarheidsgroepen. Als uw connection_auth_desc eindpunt ( NTLM Windows-verificatie) of KERBEROS, en u Windows-verificatie nodig hebt voor een bestaande beschikbaarheidsgroep, is het mogelijk om het eindpunt te wijzigen om meerdere verificatiemethoden te gebruiken door de verificatieoptie over te schakelen naar NEGOTIATE CERTIFICATE. Met deze wijziging kan de bestaande beschikbaarheidsgroep Windows-verificatie gebruiken, terwijl de certificaatverificatie voor SQL Managed Instance wordt gebruikt.

Als versleuteling geen AES bevat en u RC4-versleuteling nodig hebt, is het mogelijk om het eindpunt te wijzigen om beide algoritmen te gebruiken. Zie de documentatiepagina voor sys.database_mirroring_endpoints voor meer informatie over mogelijke opties voor het wijzigen van eindpunten.

Het volgende script is een voorbeeld van het wijzigen van uw bestaande eindpunt voor databasespiegeling op SQL Server. Vervangen:

  • <YourExistingEndpointName> met de naam van uw bestaande eindpunt.
  • <SQLServerCertName> met de naam van het gegenereerde SQL Server-certificaat (verkregen in een van de bovenstaande stappen).

Afhankelijk van uw specifieke configuratie moet u het script mogelijk verder aanpassen. U kunt ook SELECT * FROM sys.certificates de naam ophalen van het gemaakte certificaat op 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

Nadat u de ALTER eindpuntquery hebt uitgevoerd en de modus voor dubbele verificatie hebt ingesteld op Windows en het certificaat, gebruikt u deze query opnieuw op SQL Server om details weer te geven voor het eindpunt voor databasespiegeling:

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

U hebt het eindpunt voor databasespiegeling gewijzigd voor een sql Managed Instance-koppeling.

Een beschikbaarheidsgroep maken in SQL Server

Als u geen bestaande beschikbaarheidsgroep hebt, is de volgende stap het maken van een beschikbaarheidsgroep op SQL Server, ongeacht de eerste primaire. Opdrachten voor het maken van de beschikbaarheidsgroep verschillen als uw door SQL beheerde exemplaar de eerste primaire is, die alleen wordt ondersteund vanaf SQL Server 2022 CU10.

Hoewel het mogelijk is om meerdere koppelingen voor dezelfde database tot stand te brengen, ondersteunt de koppeling alleen replicatie van één database per koppeling. Als u meerdere koppelingen voor dezelfde database wilt maken, gebruikt u dezelfde beschikbaarheidsgroep voor alle koppelingen, maar maakt u vervolgens een nieuwe gedistribueerde beschikbaarheidsgroep voor elke databasekoppeling tussen SQL Server en SQL Managed Instance.

Als SQL Server de eerste primaire server is, maakt u een beschikbaarheidsgroep met de volgende parameters voor een koppeling:

  • Oorspronkelijke primaire servernaam
  • Databasenaam
  • Een failovermodus van MANUAL
  • Een seeding-modus van AUTOMATIC

Zoek eerst uw SQL Server-naam op door de volgende T-SQL-instructie uit te voeren:

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

Gebruik vervolgens het volgende script om de beschikbaarheidsgroep op SQL Server te maken. Vervangen:

  • <AGName> met de naam van uw beschikbaarheidsgroep. Voor een koppeling naar een beheerd exemplaar is één database per beschikbaarheidsgroep vereist. Voor meerdere databases moet u meerdere beschikbaarheidsgroepen maken. Overweeg elke beschikbaarheidsgroep een naam te geven zodat de naam overeenkomt met de bijbehorende database, AG_<db_name>bijvoorbeeld.
  • <DatabaseName> met de naam van de database die u wilt repliceren.
  • <SQLServerName> met de naam van uw SQL Server-exemplaar dat u in de vorige stap hebt verkregen.
  • <SQLServerIP> met het IP-adres van SQL Server. U kunt de naam van een om te zetten SQL Server-hostmachine als alternatief gebruiken, maar u moet ervoor zorgen dat de naam kan worden omgezet vanuit het virtuele SQL Managed Instance-netwerk.
-- 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

Belangrijk

Verwijder voor SQL Server 2016 WITH (CLUSTER_TYPE = NONE) de bovenstaande T-SQL-instructie. Laat deze staan voor alle latere SQL Server-versies.

Maak vervolgens de gedistribueerde beschikbaarheidsgroep op SQL Server. Als u van plan bent om meerdere koppelingen te maken, moet u voor elke koppeling een gedistribueerde beschikbaarheidsgroep maken, zelfs als u meerdere koppelingen voor dezelfde database tot stand wilt brengen.

Vervang de volgende waarden en voer vervolgens het T-SQL-script uit om uw gedistribueerde beschikbaarheidsgroep te maken.

  • <DAGName> met de naam van uw gedistribueerde beschikbaarheidsgroep. Aangezien u meerdere koppelingen voor dezelfde database kunt configureren door voor elke koppeling een gedistribueerde beschikbaarheidsgroep te maken, kunt u overwegen om elke gedistribueerde beschikbaarheidsgroep dienovereenkomstig een naam te geven, bijvoorbeeld DAG1_<db_name>. DAG2_<db_name>
  • <AGName> met de naam van de beschikbaarheidsgroep die u in de vorige stap hebt gemaakt.
  • <SQLServerIP> met het IP-adres van SQL Server uit de vorige stap. U kunt de naam van een om te zetten SQL Server-hostmachine als alternatief gebruiken, maar zorg ervoor dat de naam kan worden omgezet vanuit het virtuele SQL Managed Instance-netwerk (waarvoor aangepaste Azure DNS moet worden geconfigureerd voor het subnet van het beheerde exemplaar).
  • <ManagedInstanceName> met de korte naam van uw beheerde exemplaar.
  • <ManagedInstanceFQDN> met de volledig gekwalificeerde domeinnaam van uw beheerde exemplaar.
-- 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

Beschikbaarheidsgroepen controleren

Gebruik het volgende script om alle beschikbaarheidsgroepen en gedistribueerde beschikbaarheidsgroepen op het SQL Server-exemplaar weer te geven. Op dit moment moet de status van uw beschikbaarheidsgroep zijn connecteden moet de status van uw gedistribueerde beschikbaarheidsgroepen zijn disconnected. De status van de gedistribueerde beschikbaarheidsgroep wordt slechts verplaatst naar connected zodra deze is gekoppeld aan 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

U kunt ook SSMS-Objectverkenner gebruiken om beschikbaarheidsgroepen en gedistribueerde beschikbaarheidsgroepen te vinden. Vouw de map AlwaysOn Hoge beschikbaarheid en vervolgens de map Beschikbaarheidsgroepen uit.

Ten slotte kunt u de koppeling maken. De opdrachten verschillen op basis van welk exemplaar de eerste primaire instantie is. Gebruik de Opdracht New-AzSqlInstanceLink PowerShell of az sql mi link create Azure CLI om de koppeling te maken, zoals het PowerShell-voorbeeld in deze sectie. Het maken van de koppeling vanuit een primaire SQL Managed Instance wordt momenteel niet ondersteund met de Azure CLI.

Als u alle koppelingen in een beheerd exemplaar wilt zien, gebruikt u de PowerShell van Get-AzSqlInstanceLink of az sql mi link om de Azure CLI-opdracht weer te geven in Azure Cloud Shell.

Om het proces te vereenvoudigen, meldt u zich aan bij Azure Portal en voert u het volgende script uit vanuit De Azure Cloud Shell. Vervangen:

  • <ManagedInstanceName> met de korte naam van uw beheerde exemplaar.
  • <AGName> met de naam van de beschikbaarheidsgroep die is gemaakt op SQL Server.
  • <DAGName> met de naam van de gedistribueerde beschikbaarheidsgroep die is gemaakt in SQL Server.
  • <DatabaseName> waarbij de database is gerepliceerd in de beschikbaarheidsgroep op SQL Server.
  • <SQLServerIP> met het IP-adres van uw SQL Server. Het opgegeven IP-adres moet toegankelijk zijn voor het beheerde exemplaar.
#  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

Het resultaat van deze bewerking is een tijdstempel van de geslaagde uitvoering van de koppelingsaanvraag.

Voer de volgende query uit op SQL Server om de verbinding tussen SQL Managed Instance en SQL Server te controleren. De verbinding wordt niet onmiddellijk uitgevoerd. Het kan tot een minuut duren voordat de DMV een geslaagde verbinding weergeeft. Vernieuw de DMV totdat de verbinding wordt weergegeven als VERBONDEN voor de SQL Managed Instance-replica.

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

Nadat de verbinding tot stand is gebracht, kan Objectverkenner in SSMS in eerste instantie de gerepliceerde database op de secundaire replica in een herstelstatus weergeven wanneer de eerste seedingfase de volledige back-up van de database verplaatst en herstelt. Nadat de database is hersteld, moet de replicatie worden bijgehaald om de twee databases naar een gesynchroniseerde status te brengen. De database bevindt zich niet meer in Herstellen nadat de eerste seeding is voltooid. Het seeden van kleine databases is mogelijk snel genoeg om de initiële herstelstatus in SSMS niet te zien.

Belangrijk

  • De koppeling werkt alleen als er netwerkconnectiviteit bestaat tussen SQL Server en SQL Managed Instance. Volg de stappen in Netwerkconnectiviteit testen om problemen met de netwerkverbinding op te lossen.
  • Maak regelmatig back-ups van het logboekbestand op SQL Server. Als de gebruikte logboekruimte 100 procent bereikt, stopt de replicatie naar SQL Managed Instance totdat het gebruik van ruimte is verminderd. We raden u ten zeerste aan logboekback-ups te automatiseren door een dagelijkse taak in te stellen. Zie Back-up maken van logboekbestanden op SQL Server voor meer informatie.

Werkbelasting stoppen

Als u een failover van uw database naar de secundaire replica wilt uitvoeren, stopt u eerst alle toepassingsworkloads op uw primaire replica tijdens uw onderhoudsuren. Hierdoor kan databasereplicatie een inhaalslag maken op de secundaire o die u kunt migreren of een failover naar Azure uitvoeren zonder gegevensverlies. Hoewel de primaire database deel uitmaakt van een AlwaysOn-beschikbaarheidsgroep, kunt u deze niet instellen op de modus Alleen-lezen. U moet ervoor zorgen dat toepassingen geen transacties doorvoeren naar de primaire replica vóór de failover.

De replicatiemodus wijzigen

Replicatie tussen SQL Server en SQL Managed Instance is standaard asynchroon. Voordat u een failover van uw database naar de secundaire database uitvoert, schakelt u de koppeling over naar de synchrone modus. Synchrone replicatie tussen grote netwerkafstanden kan transacties op de primaire replica vertragen.

Voor het overschakelen van asynchroon naar de synchronisatiemodus is een replicatiemoduswijziging vereist voor zowel SQL Managed Instance als SQL Server.

Schakelen tussen replicatiemodus (SQL Managed Instance)

Gebruik Azure PowerShell of de Azure CLI om de replicatiemodus in SQL Managed Instance te wijzigen.

Zorg er eerst voor dat u bent aangemeld bij Azure en dat u het abonnement hebt geselecteerd waarin uw beheerde exemplaar wordt gehost met behulp van de opdracht Select-AzSubscription PowerShell of az account set Azure CLI. Het selecteren van het juiste abonnement is vooral belangrijk als u meer dan één Azure-abonnement in uw account hebt.

Vervang in het volgende PowerShell-voorbeeld door <SubscriptionID> uw Azure-abonnements-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

Zorg ervoor dat u de naam weet van de koppeling waarvoor u een failover wilt uitvoeren. U kunt de Azure CLI-opdracht Get-AzSqlInstanceLink PowerShell of az sql mi link list gebruiken.

Gebruik het volgende PowerShell-script om alle actieve koppelingen op het met SQL beheerde exemplaar weer te geven. Vervang door <ManagedInstanceName> de korte naam van uw beheerde exemplaar.

# 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

Noteer in de uitvoer van het vorige script de Name eigenschap van de koppeling waarvoor u een failover wilt uitvoeren.

Schakel vervolgens de replicatiemodus van asynchroon om te synchroniseren in SQL Managed Instance voor de geïdentificeerde koppeling met behulp van de Opdracht Update-AzSqlInstanceLink PowerShell of az sql mi link update Azure CLI.

Vervang in het volgende PowerShell-voorbeeld:

  • <ManagedInstanceName> met de korte naam van uw beheerde exemplaar.
  • <DAGName> met de naam van de koppeling die u hebt gevonden in de vorige stap (de Name eigenschap uit de vorige stap).
# 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"

De vorige opdracht geeft aan dat de bewerking is geslaagd door een samenvatting van de bewerking weer te geven, waarbij de eigenschap ReplicationMode wordt weergegeven als Sync.

Als u de bewerking wilt herstellen, voert u het vorige script uit om de replicatiemodus te wijzigen, maar vervangt u de Sync tekenreeks in het -ReplicationMode script naar Async.

Schakelen tussen replicatiemodus (SQL Server)

Gebruik het volgende T-SQL-script op SQL Server om de replicatiemodus van de gedistribueerde beschikbaarheidsgroep op SQL Server te wijzigen van asynchroon om te synchroniseren. Vervangen:

  • <DAGName> met de naam van de gedistribueerde beschikbaarheidsgroep (gebruikt om de koppeling te maken).
  • <AGName> met de naam van de beschikbaarheidsgroep die is gemaakt op SQL Server (gebruikt om de koppeling te maken).
  • <ManagedInstanceName> met de naam van uw beheerde exemplaar.
-- 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);

Gebruik de volgende dynamische beheerweergave om te bevestigen dat u de replicatiemodus van de koppeling hebt gewijzigd. Resultaten geven de SYNCHRONOUS_COMIT status aan.

-- 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 u zowel SQL Managed Instance als SQL Server hebt overgeschakeld naar de synchronisatiemodus, is replicatie tussen de twee exemplaren synchroon. Als u deze status wilt omkeren, volgt u dezelfde stappen en stelt u de status async in op zowel SQL Server als SQL Managed Instance.

LSN-waarden controleren op zowel SQL Server als SQL Managed Instance

Controleer of de replicatie is voltooid om de failover of migratie te voltooien. Zorg ervoor dat de logboekreeksnummers (LSN's) in de logboekrecords voor zowel SQL Server als SQL Managed Instance hetzelfde zijn.

In eerste instantie wordt verwacht dat de LSN op de primaire waarde hoger is dan de LSN op de secundaire. Netwerklatentie kan ertoe leiden dat replicatie enigszins achterloopt op de primaire. Omdat de workload is gestopt op de primaire, moet u verwachten dat de LSN's na enige tijd overeenkomen en stoppen met wijzigen.

Gebruik de volgende T-SQL-query op SQL Server om de LSN van het laatst geregistreerde transactielogboek te lezen. Vervangen:

  • <DatabaseName> met uw databasenaam en zoek naar het laatst beperkte LSN-nummer.
-- 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>'

Gebruik de volgende T-SQL-query in SQL Managed Instance om de laatst beperkte LSN voor uw database te lezen. Vervang door <DatabaseName> de naam van uw database.

Deze query werkt op een sql Managed Instance voor algemeen gebruik. Verwijder de opmerkingen and drs.is_primary_replica = 1 aan het einde van het script voor een Bedrijfskritiek SQL Managed Instance. Op de servicelaag Bedrijfskritiek zorgt dit filter ervoor dat details alleen worden gelezen uit de primaire replica.

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

U kunt ook de Opdracht Get-AzSqlInstanceLink PowerShell of az sql mi link gebruiken om de LastHardenedLsn eigenschap voor uw koppeling op SQL Managed Instance op te halen om dezelfde informatie op te geven als de vorige T-SQL-query.

Belangrijk

Controleer nogmaals of uw werkbelasting is gestopt op de primaire. Controleer of LSN's op zowel SQL Server als SQL Managed Instance overeenkomen en dat ze enige tijd overeenkomen en ongewijzigd blijven . Stabiele LSN's op beide exemplaren geven aan dat het tail-logboek is gerepliceerd naar de secundaire en dat de werkbelasting effectief wordt gestopt.

Failover van een database

Als u PowerShell wilt gebruiken om een failover uit te voeren voor een database tussen SQL Server 2022 en SQL Managed Instance terwijl u de koppeling nog steeds onderhoudt of als u een failover wilt uitvoeren met gegevensverlies voor een versie van SQL Server, gebruikt u de wizard Failover tussen SQL Server en Managed Instance in SSMS om het script voor uw omgeving te genereren. U kunt een geplande failover uitvoeren vanaf de primaire of secundaire replica. Als u een geforceerde failover wilt uitvoeren, maakt u verbinding met de secundaire replica.

Als u de koppeling wilt verbreken en de replicatie wilt stoppen wanneer u een failover uitvoert of uw database migreert, ongeacht de SQL Server-versie, gebruikt u de Opdracht Remove-AzSqlInstanceLink PowerShell of az sql mi link delete Azure CLI.

Let op

  • Voordat u een failover uitvoert, stopt u de workload op de brondatabase om de gerepliceerde database volledig in te halen en failover uit te voeren zonder gegevensverlies. Als u een geforceerde failover uitvoert of als u de koppeling onderbreekt voordat LSN's overeenkomen, verliest u mogelijk gegevens.
  • Een failover van een database in SQL Server 2019 en eerdere versies wordt verbroken en de koppeling tussen de twee replica's wordt verwijderd. U kunt geen failback uitvoeren naar de eerste primaire.
  • Failover van een database terwijl de koppeling met SQL Server 2022 momenteel in preview is.

Met het volgende voorbeeldscript wordt de koppeling verbroken en wordt de replicatie tussen uw replica's beëindigd, waardoor de database op beide exemplaren kan worden gelezen/geschreven. Vervangen:

  • <ManagedInstanceName> met de naam van uw beheerde exemplaar.
  • <DAGName> met de naam van de koppeling waarvoor u een failover uitvoert (uitvoer van de eigenschap Name van Get-AzSqlInstanceLink de opdracht die eerder hierboven is uitgevoerd).
# 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

Wanneer de failover is geslaagd, wordt de koppeling verwijderd en bestaat deze niet meer. De SQL Server-database en sql Managed Instance-database kunnen beide een lees-/schrijfworkload uitvoeren. Ze zijn volledig onafhankelijk. Wijs uw toepassing verbindingsreeks aan de database die u actief wilt gebruiken.

Belangrijk

Nadat de failover naar SQL Managed Instance is geslaagd, kunt u uw toepassing(en) verbindingsreeks handmatig naar de FQDN van het beheerde SQL-exemplaar verwijzen om de migratie te voltooien of een failover-overschakeling uit te voeren en door te gaan met het uitvoeren in Azure.

Beschikbaarheidsgroepen opschonen

Omdat een failover met SQL Server 2022 de koppeling niet onderbreekt, kunt u ervoor kiezen om de koppeling en beschikbaarheidsgroepen te behouden.

Als u besluit de koppeling te verbreken of als u een failover uitvoert met SQL Server 2019 en eerdere versies, moet u de gedistribueerde beschikbaarheidsgroep verwijderen om metagegevens van de koppeling uit SQL Server te verwijderen. U kunt er echter voor kiezen om de beschikbaarheidsgroep op SQL Server te behouden.

Als u de resources van uw beschikbaarheidsgroep wilt opschonen, vervangt u de volgende waarden en voert u de voorbeeldcode uit: Vervang in de volgende code:

  • <DAGName> met de naam van de gedistribueerde beschikbaarheidsgroep op SQL Server (gebruikt om de koppeling te maken).
  • <AGName> met de naam van de beschikbaarheidsgroep op SQL Server (gebruikt om de koppeling te maken).
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

Problemen oplossen

De sectie bevat richtlijnen voor het oplossen van problemen met het configureren en gebruiken van de koppeling.

Fouten

Als er een foutbericht wordt weergegeven wanneer u de koppeling maakt of een failover voor een database uitvoert, raadpleegt u het foutbericht in het uitvoervenster van de query voor meer informatie.

Als er een fout optreedt bij het werken met de koppeling, stopt de query bij de mislukte stap. Nadat de foutvoorwaarde is opgelost, voert u de opdracht opnieuw uit om door te gaan met uw actie.

Inconsistente status na geforceerde failover

Het gebruik van geforceerde failover kan leiden tot een inconsistente status tussen de primaire en secundaire replica's, waardoor een gesplitst hersenscenario wordt veroorzaakt van beide replica's die zich in dezelfde rol bevinden. Gegevensreplicatie mislukt in deze status totdat de gebruiker de situatie oplost door de ene replica handmatig aan te wijzen als primaire replica en de andere replica als secundair.

Gerelateerde inhoud

Zie de volgende bronnen voor meer informatie over de koppelingsfunctie: