Een failovergroep configureren voor Azure SQL Managed Instance

2025-05-05

Van toepassing op:Azure SQL Managed Instance

In dit artikel leert u hoe u een failovergroep voor Azure SQL Managed Instance configureert met behulp van Azure Portal en Azure PowerShell.

Voor een end-to-end PowerShell-script om beide exemplaren in een failovergroep te maken, raadpleegt u Exemplaar toevoegen aan een failovergroep met PowerShell.

Vereiste voorwaarden

Als u een failovergroep wilt configureren, moet u al over de juiste machtigingen beschikken en een door SQL beheerd exemplaar dat u wilt gebruiken als de primaire instantie. Bekijk Instantie maken om aan de slag te gaan.

Controleer de beperkingen voordat u uw secundaire exemplaar en failovergroep maakt.

Configuratievereisten

Houd rekening met de volgende vereisten om een failovergroep te configureren tussen een primair en secundair beheerd SQL-exemplaar:

Het secundaire beheerde exemplaar moet leeg zijn, zonder gebruikersdatabases.
De twee exemplaren moeten dezelfde servicelaag hebben en dezelfde opslaggrootte hebben. Hoewel dit niet vereist is, wordt ten zeerste aangeraden dat beide exemplaren gelijke rekenkracht hebben om ervoor te zorgen dat de secundaire instantie duurzaam wijzigingen kan verwerken die zijn gerepliceerd vanaf het primaire exemplaar, inclusief tijdens perioden van piekactiviteit.
Het IP-adresbereik voor het virtuele netwerk van het primaire exemplaar mag niet overlappen met het adresbereik van het virtuele netwerk voor het secundaire beheerde exemplaar of een ander virtueel netwerk dat is gekoppeld aan het primaire of secundaire virtuele netwerk.
Beide exemplaren moeten zich in dezelfde DNS-zone bevinden. Wanneer u uw secundaire beheerde exemplaar maakt, moet u de DNS-zone-id van het primaire exemplaar opgeven. Als u dit niet doet, wordt de zone-id gegenereerd als een willekeurige tekenreeks wanneer het eerste exemplaar in elk virtueel netwerk wordt gemaakt en dezelfde id wordt toegewezen aan alle andere exemplaren in hetzelfde subnet. Zodra de DNS-zone is toegewezen, kan deze niet meer worden gewijzigd.
Netwerkbeveiligingsgroepen (NSG)-regels voor de subnetten van beide exemplaren moeten open inkomende en uitgaande TCP-verbindingen hebben voor poort 5022 en poortbereik 11000-11999 om de communicatie tussen de twee exemplaren mogelijk te maken.
Beheerde exemplaren dienen te worden geïmplementeerd in gekoppelde regio's vanwege prestatieoverwegingen. Beheerde exemplaren die zich in geografisch gekoppelde regio's bevinden, profiteren van een aanzienlijk hogere geo-replicatiesnelheid in vergelijking met niet-gepaareerde regio's.
Beide exemplaren moeten hetzelfde updatebeleid gebruiken.

Het secundaire exemplaar maken

Wanneer u het secundaire exemplaar maakt, moet u een virtueel netwerk gebruiken met een IP-adresruimte die niet overlapt met het IP-adresruimtebereik van het primaire exemplaar. Wanneer u het nieuwe secundaire exemplaar configureert, moet u bovendien de zone-id van het primaire exemplaar opgeven.

U kunt het secundaire virtuele netwerk configureren en het secundaire exemplaar maken met behulp van Azure Portal en PowerShell.

Azure-portal
PowerShell

Virtueel netwerk maken

Als u een virtueel netwerk wilt maken voor uw secundaire exemplaar in Azure Portal, voert u de volgende stappen uit:

Controleer de adresruimte voor het primaire exemplaar. Ga naar de resource van het virtuele netwerk voor het primaire exemplaar in de Azure-portal en selecteer onder InstellingenAdresruimte. Controleer het bereik onder Adresbereik:
Maak een nieuw virtueel netwerk dat u wilt gebruiken voor het secundaire exemplaar door naar de pagina Virtueel netwerk maken te gaan.
Op het tabblad Basisbeginselen van de pagina Virtueel netwerk maken :
1. Selecteer de resourcegroep die u wilt gebruiken voor het secundaire exemplaar. Maak een nieuwe als deze nog niet bestaat.
2. Geef een naam op voor uw virtuele netwerk, zoals vnet-sql-mi-secondary.
3. Selecteer een regio die is gekoppeld aan de regio waarin het primaire exemplaar zich bevindt.
Op het tabblad IP-adressen van de pagina Virtueel netwerk maken :
1. Gebruik Adresruimte verwijderen om de bestaande IPv4-adresruimte te verwijderen.
2. Nadat de adresruimte is verwijderd, selecteert u IPv4-adresruimte toevoegen om een nieuwe ruimte toe te voegen en geeft u vervolgens een IP-adresruimte op die verschilt van de adresruimte die wordt gebruikt door het virtuele netwerk van het primaire exemplaar. Als uw huidige primaire instantie bijvoorbeeld gebruikmaakt van een adresruimte van 10.0.0.16, voert 10.1.0.0/16 u de adresruimte in van het virtuele netwerk dat u wilt gebruiken voor het secundaire exemplaar.
3. Gebruik + Een subnet toevoegen om een standaardsubnet met standaardwaarden toe te voegen.
4. Gebruik + Een subnet toevoegen om een leeg subnet toe te voegen dat ManagedInstance wordt toegewezen aan het secundaire exemplaar, met behulp van een adresbereik dat verschilt van het standaardsubnet. Als uw primaire exemplaar bijvoorbeeld een adresbereik van 10.0.0.0 - 10.0.255.255 gebruikt, geeft u een subnetbereik op van 10.1.1.0 - 10.1.1.255 het subnet van het secundaire exemplaar.
Gebruik Beoordelen en maken om uw instellingen te controleren en gebruik vervolgens Maken om uw nieuwe virtuele netwerk te maken.

Secundair exemplaar maken

Nadat uw virtuele netwerk gereed is, volgt u deze stappen om uw secundaire exemplaar te maken in Azure Portal:

Ga naar Azure SQL Managed Instance maken in de Azure portal.
Op het tabblad Basisbeginselen van de pagina Azure SQL Managed Instance maken :
1. Kies een regio voor uw secundaire exemplaar dat is gekoppeld aan het primaire exemplaar.
2. Kies een servicelaag die overeenkomt met de servicelaag van het primaire exemplaar.
Gebruik op het tabblad Netwerken van de pagina Azure SQL Managed Instance maken de vervolgkeuzelijst onder Virtueel netwerk/subnet om het virtuele netwerk en subnet te selecteren dat u eerder hebt gemaakt:
Selecteer op het tabblad Aanvullende instellingen van de pagina Azure SQL Managed Instance maken de optie Ja om als secundaire failover te gebruiken en kies vervolgens het juiste primaire exemplaar in de vervolgkeuzelijst.
Configureer de rest van de instantie volgens uw zakelijke behoeften en maak deze vervolgens aan met behulp van Controleren + Aanmaken.

U kunt zowel uw virtuele netwerk als uw secundaire exemplaar maken met behulp van PowerShell. Raadpleeg Exemplaar toevoegen aan failovergroep met PowerShell voor een volledig PowerShell-voorbeeldscript dat beide taken uitvoert.

Wanneer u uw secundaire exemplaar maakt met Azure PowerShell, moet u de DnsZonePartner waarde opgeven met de zone-id van het primaire exemplaar.

U kunt de opdracht Get-AzSqlInstance gebruiken om de DNS-zone-id van het primaire exemplaar te parameteriseren en deze vervolgens door te geven aan de DnsZonePartner parameter van de opdracht New-AzSqlInstance :

# Get the DNS zone ID of the primary instance
$primaryManagedInstanceId = Get-AzSqlInstance -Name $primaryInstance -ResourceGroupName $resourceGroupName | Select-Object Id

Connectiviteit tussen de exemplaren tot stand brengen

Voor ononderbroken verkeersstroom voor geo-replicatie moet u verbinding maken tussen de subnetten van het virtuele netwerk die als host fungeren voor de primaire en secundaire exemplaren. Er zijn meerdere manieren om beheerde exemplaren in verschillende Azure-regio's te verbinden, waaronder:

Wereldwijde peering van virtuele netwerken wordt aanbevolen als de meest presterende en robuuste manier om connectiviteit tussen exemplaren in een failovergroep tot stand te brengen. Wereldwijde peering van virtuele netwerken biedt een privéverbinding met lage latentie en hoge bandbreedte tussen gekoppelde virtuele netwerken met behulp van de Microsoft-backbone-infrastructuur. Er zijn geen openbare internetverbinding, gateways of bijkomende versleuteling vereist in de communicatie tussen de peering virtuele netwerken.

Belangrijk

Alternatieve manieren om exemplaren te verbinden waarbij extra netwerkapparaten betrokken zijn, kunnen problemen met connectiviteit of replicatiesnelheid bemoeilijken, waardoor mogelijk actieve betrokkenheid van netwerkbeheerders nodig is en mogelijk aanzienlijk langere oplossingstijd nodig is.

Als u een mechanisme gebruikt om connectiviteit tot stand te brengen tussen de andere exemplaren dan de aanbevolen globale peering voor virtuele netwerken, moet u het volgende controleren:

Netwerkapparaten, zoals firewalls of virtuele netwerkapparaten (NVA's), blokkeren geen verkeer op binnenkomende en uitgaande verbindingen voor poort 5022 (TCP) en poortbereik 11000-11999.
Routering is correct geconfigureerd en asymmetrische routering wordt vermeden.
Als u failovergroepen implementeert in een hub-and-spoke-netwerktopologie tussen regio's, om connectiviteits- en replicatiesnelheidsproblemen te voorkomen, moet replicatieverkeer rechtstreeks tussen de twee subnetten van het beheerde exemplaar gaan in plaats van via de hubnetwerken.

In dit artikel wordt u begeleid bij het configureren van wereldwijde peering van virtuele netwerken tussen de netwerken van de twee exemplaren met behulp van Azure Portal en PowerShell.

Azure-portal
PowerShell

Ga in de Azure portal naar de Virtual Network resource voor uw primaire managed instance.
Selecteer Peerings onder Instellingen om de pagina Peerings te openen en gebruik vervolgens + Toevoegen op de opdrachtbalk om de pagina Peering toevoegen te openen.

Voer op de pagina Peering toevoegen waarden in of selecteer deze voor de volgende instellingen:

Instellingen	Beschrijving
Samenvatting van extern virtueel netwerk
Naam van peeringverbinding	De naam voor de peering moet uniek zijn binnen het virtuele netwerk. In dit artikel wordt gebruikgemaakt van `Fog-peering`.
Implementatiemodel voor het virtuele netwerk	Selecteer Resourcebeheerder.
Ik ken mijn resource-id	U kunt dit selectievakje uitgeschakeld laten, tenzij u de resource-id kent.
Abonnement	Selecteer het abonnement in de vervolgkeuzelijst.
Virtueel netwerk	Selecteer het virtuele netwerk voor het secundaire exemplaar in de vervolgkeuzelijst.
Instellingen voor peering van externe virtuele netwerken
'secundair virtueel netwerk' toegang geven tot 'primair virtueel netwerk'	Schakel het selectievakje in om communicatie tussen de twee netwerken toe te staan. Als u communicatie tussen virtuele netwerken inschakelt, kunnen resources die zijn verbonden met een virtueel netwerk met elkaar communiceren met dezelfde bandbreedte en latentie alsof ze zijn verbonden met hetzelfde virtuele netwerk. Alle communicatie tussen resources in de twee virtuele netwerken vindt plaats via het privénetwerk van Azure.
'secundair virtueel netwerk' toestaan om doorgestuurd verkeer te ontvangen van 'primair virtueel netwerk'	U kunt dit selectievakje in- of uitschakelen. Dit werkt voor deze handleiding. Zie Een peering maken voor meer informatie.
Sta de gateway of routerserver in het 'secundaire virtuele netwerk' toe om verkeer door te sturen naar het 'primaire virtuele netwerk'.	U kunt dit selectievakje in- of uitschakelen. Dit werkt voor deze handleiding. Zie Een peering maken voor meer informatie.
'secundair virtueel netwerk' inschakelen om de externe gateway of routeserver van het primaire virtuele netwerk te gebruiken	Laat dit selectievakje uitgeschakeld. Zie Een peering maken voor meer informatie over de andere beschikbare opties.
Samenvatting van lokaal virtueel netwerk
Naam van peeringverbinding	De naam van dezelfde peering die wordt gebruikt voor het externe virtuele netwerk. In dit artikel wordt gebruikgemaakt van `Fog-peering`.
'Primair virtueel netwerk' toegang geven tot 'secundair virtueel netwerk'	Schakel het selectievakje in om communicatie tussen de twee netwerken toe te staan. Als u communicatie tussen virtuele netwerken inschakelt, kunnen resources die zijn verbonden met een virtueel netwerk met elkaar communiceren met dezelfde bandbreedte en latentie alsof ze zijn verbonden met hetzelfde virtuele netwerk. Alle communicatie tussen resources in de twee virtuele netwerken vindt plaats via het privénetwerk van Azure.
Toestaan dat 'primair virtueel netwerk' doorgestuurd verkeer ontvangt van 'secundair virtueel netwerk'	U kunt dit selectievakje in- of uitschakelen. Dit werkt voor deze handleiding. Zie Een peering maken voor meer informatie.
Gateway of routeserver in 'primair virtueel netwerk' toestaan om verkeer door te sturen naar 'secundair virtueel netwerk'	U kunt dit selectievakje in- of uitschakelen. Dit werkt voor deze handleiding. Zie Een peering maken voor meer informatie.
'primair virtueel netwerk' inschakelen om de externe gateway of routeserver van het secundaire virtuele netwerk te gebruiken	Laat dit selectievakje uitgeschakeld. Zie Een peering maken voor meer informatie over de andere beschikbare opties.

Gebruik Toevoegen om peering te configureren met het virtuele netwerk dat u hebt geselecteerd en ga automatisch terug naar de pagina Peerings , waarin wordt weergegeven dat de twee netwerken zijn verbonden:

Configureer globale peering voor virtuele netwerken tussen de virtuele netwerken van de primaire en secundaire beheerde instanties:


# Create global virtual network peering
$primaryVirtualNetwork  = Get-AzVirtualNetwork `
                  -Name $primaryVNet `
                  -ResourceGroupName $resourceGroupName

$secondaryVirtualNetwork = Get-AzVirtualNetwork `
                  -Name $secondaryVNet `
                  -ResourceGroupName $resourceGroupName
                  
Write-host "Peering primary VNet to secondary VNet..."
Add-AzVirtualNetworkPeering `
 -Name primaryVnet-secondaryVNet1 `
 -VirtualNetwork $primaryVirtualNetwork `
 -RemoteVirtualNetworkId $secondaryVirtualNetwork.Id
 Write-host "Primary VNet peered to secondary VNet successfully."

Write-host "Peering secondary VNet to primary VNet..."
Add-AzVirtualNetworkPeering `
 -Name secondaryVNet-primaryVNet `
 -VirtualNetwork $secondaryVirtualNetwork `
 -RemoteVirtualNetworkId $primaryVirtualNetwork.Id
Write-host "Secondary VNet peered to primary VNet successfully."

Write-host "Checking peering state on the primary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $primaryVNet `
| Select PeeringState

Write-host "Checking peering state on the secondary virtual network..."
Get-AzVirtualNetworkPeering `
-ResourceGroupName $resourceGroupName `
-VirtualNetworkName $secondaryVNet `
| Select PeeringState

In dit codefragment worden de volgende opdrachten gebruikt:

Opdracht	Opmerkingen
1. Get-AzVirtualNetwork	Verkrijgt een virtueel netwerk in een resourcegroep.
2. Add-AzVirtualNetworkPeering	Hiermee voegt u een peering toe aan een virtueel netwerk.
3. Get-AzVirtualNetworkPeering	Hiermee haalt u een peering op voor een virtueel netwerk.

Poorten en NSG-regels configureren

Ongeacht het gekozen connectiviteitsmechanisme tussen de twee instanties moeten uw netwerken voldoen aan de volgende vereisten voor de stroom van verkeer van geo-replicatie.

De routetabel en netwerkbeveiligingsgroepen die zijn toegewezen aan de subnetten van het beheerde exemplaar worden niet gedeeld tussen de twee gekoppelde virtuele netwerken.
De NSG-regels (Network Security Group) voor beide subnetten die elk exemplaar hosten, staan zowel inkomend als uitgaand verkeer naar het andere exemplaar toe op poort 5022 en het poortbereik 11000-11999.

U kunt uw poortcommunicatie en NSG-regels configureren met behulp van Azure Portal en PowerShell.

Azure-portal
PowerShell

Voer de volgende stappen uit om netwerkbeveiligingsgroeppoorten (NSG) te openen in Azure Portal:

Ga naar de resource van de netwerkbeveiligingsgroep voor het primaire exemplaar.
Selecteer onder InstellingenInkomende beveiligingsregels. Controleer of u al regels hebt die verkeer toestaan voor poort 5022 en het bereik 11000-11999. Als u dit doet en de bron voldoet aan de behoeften van uw bedrijf, kunt u deze stap overslaan. Als de regels niet bestaan of als u een andere bron (zoals het veiligere IP-adres) wilt gebruiken, verwijdert u de bestaande regel en selecteert u + Toevoegen op de opdrachtbalk om het deelvenster Binnenkomende beveiligingsregels toevoegen te openen:

Voer in het deelvenster Binnenkomende beveiligingsregels toevoegen waarden in of selecteer deze voor de volgende instellingen:

Instellingen	Aanbevolen waarde	Beschrijving
Bron	IP-adressen of servicetag	Het filter voor de bron van de communicatie. HET IP-adres is het veiligste en wordt aanbevolen voor productieomgevingen. Servicetag is geschikt voor niet-productieomgevingen.
Bron servicetag	Als u servicetag als bron hebt geselecteerd, geeft u `VirtualNetwork` deze op als de brontag.	Standaardtags zijn vooraf gedefinieerde id's die een categorie IP-adressen vertegenwoordigen. De VirtualNetwork-tag geeft alle adresruimten van het virtuele en lokale netwerk aan.
Bron-IP-adressen	Als u IP-adressen als bron hebt geselecteerd, geeft u het IP-adres van het secundaire exemplaar op.	Geef een adresbereik op met cidr-notatie (bijvoorbeeld 192.168.99.0/24 of 2001:1234::/64) of een IP-adres (bijvoorbeeld 192.168.99.0 of 2001:1234::). U kunt ook een door komma's gescheiden lijst met IP-adressen of adresbereiken opgeven met behulp van IPv4 of IPv6.
Poortbereiken van bron	5022	Hiermee kunt u aangeven op welke poorten verkeer volgens deze regel wordt toegestaan.
Dienst	Op maat gemaakt	De service geeft het doelprotocol en poortbereik voor deze regel op.
Poortbereiken van bestemming	5022	Hiermee kunt u aangeven op welke poorten verkeer volgens deze regel wordt toegestaan. Deze poort moet overeenkomen met het bronpoortbereik.
Handeling	Toestaan	Communicatie op de opgegeven poort toestaan.
protocol	TCP	Bepaalt het protocol voor poortcommunicatie.
Prioriteit	1200	Regels worden verwerkt in volgorde van prioriteit; hoe lager het getal, hoe hoger de prioriteit.
Naam	allow_geodr_inbound	De naam van de regel.
Beschrijving	Optioneel	U kunt ervoor kiezen om een beschrijving op te geven of dit veld leeg te laten.

Selecteer Toevoegen om uw instellingen op te slaan en uw nieuwe regel toe te voegen.

Herhaal deze stappen om een andere binnenkomende beveiligingsregel toe te voegen voor het poortbereik 11000-11999 met een naam zoals allow_redirect_inbound en een prioriteit die iets hoger is dan de regel 5022, zoals 1100.
Selecteer onder Instellingende optie Uitgaande beveiligingsregels. Controleer of u al regels hebt die verkeer toestaan voor poort 5022 en het bereik 11000-11999. Als u dit doet en de bron voldoet aan de behoeften van uw bedrijf, kunt u deze stap overslaan. Als de regels niet bestaan of als u een andere bron (zoals het veiligere IP-adres) wilt gebruiken, verwijdert u de bestaande regel en selecteert u + Toevoegen op de opdrachtbalk om het deelvenster Uitgaande beveiligingsregels toevoegen te openen.
Gebruik in het deelvenster Uitgaande beveiligingsregel toevoegen dezelfde configuratie voor poort 5022 en het bereik 11000-11999 als voor de binnenkomende poorten.
Ga naar de netwerkbeveiligingsgroep voor het secundaire exemplaar en herhaal deze stappen zodat beide netwerkbeveiligingsgroepen de volgende regels hebben:
- Binnenkomend verkeer toestaan op poort 5022
- Binnenkomend verkeer op poortbereik toestaan 11000-11999
- Uitgaand verkeer toestaan op poort 5022
- Uitgaand verkeer op poortbereik toestaan 11000-11999

De failovergroep maken

Maak de failovergroep voor uw beheerde exemplaren met behulp van Azure Portal of PowerShell.

Portaal
PowerShell

Maak de failovergroep voor uw SQL Managed Instances met behulp van Azure Portal.

Selecteer Azure SQL in het linkermenu van Azure Portal. Als Azure SQL niet in de lijst staat, selecteert u Alle services en typt u Azure SQL in het zoekvak. (Optioneel) Selecteer de ster naast Azure SQL om het toe te voegen als favoriet item aan de linkernavigatiebalk.
Selecteer het primaire beheerde exemplaar dat u wilt toevoegen aan de failovergroep.
Selecteer failovergroepen onder Gegevensbeheer en gebruik vervolgens Groep toevoegen om de pagina Exemplaarfailovergroep te openen:
Op de pagina Exemplaarfailovergroep :
1. Het primaire beheerde exemplaar wordt vooraf geselecteerd.
2. Voer onder Naam van failovergroep een naam in voor de failovergroep.
3. Selecteer onder Secundair beheerd exemplaar het beheerde exemplaar dat u wilt gebruiken als secundaire instantie in de failovergroep.
4. Kies een lees-/schrijffailoverbeleid uit de keuzelijst. Handmatig wordt aanbevolen om u de controle te geven over failover.
5. Laat Inschakelen van failover-rechtenop Uit, tenzij u van plan bent deze replica alleen te gebruiken voor rampenherstel.
6. Gebruik Maken om uw instellingen op te slaan en uw failovergroep te maken.
Nadat de implementatie van een failovergroep is gestart, gaat u terug naar de pagina Failovergroepen . De pagina wordt vernieuwd om de nieuwe failovergroep weer te geven nadat de implementatie is voltooid.

Gebruik New-AzSqlDatabaseInstanceFailoverGroup om de failovergroep voor uw beheerde exemplaren te maken met behulp van PowerShell.


# Create failover group
Write-host "Creating the failover group..."
$failoverGroup = New-AzSqlDatabaseInstanceFailoverGroup -Name $failoverGroupName `
     -Location $location -ResourceGroupName $resourceGroupName -PrimaryManagedInstanceName $primaryInstance `
     -PartnerRegion $drLocation -PartnerManagedInstanceName $secondaryInstance `
     -FailoverPolicy Manual -GracePeriodWithDataLossHours 1
$failoverGroup

Failover testen

Test het failover van uw failovergroep door gebruik te maken van de Azure Portal of PowerShell.

Azure-portal
PowerShell

Test de failover van uw failovergroep met de Azure-portal.

Ga naar het primaire of secundaire beheerde exemplaar in Azure Portal.
Selecteer onder Gegevensbeheer de optie Failovergroepen.
In het deelvenster Failovergroepen ziet u welke instantie het primaire exemplaar is en welke instantie het secundaire exemplaar is.
In het deelvenster Failovergroepen, selecteer Failover vanuit de opdrachtbalk. Selecteer Ja bij de waarschuwing over het verbreken van de verbinding met TDS-sessies en noteer de licentieimplicatie.
In het deelvenster Failovergroepen wisselen de exemplaren van rol nadat de failover is geslaagd, zodat de vorige secundaire de nieuwe primaire wordt en de vorige primaire de nieuwe secundaire wordt.

Belangrijk

Als rollen niet zijn gewisseld, controleer de connectiviteit tussen de exemplaren en de bijbehorende NSG- en firewallregels. Ga door met de volgende stap pas nadat de rollen zijn overgeschakeld.
(Opioneel) Gebruik de optie failover in het deelvenster Failovergroepen om de rollen terug te schakelen, zodat de oorspronkelijke primaire opnieuw de primaire rol krijgt.

Test een geplande failover door met PowerShell over te schakelen naar de secundaire replica en vervolgens weer terug te schakelen.

Controleer de rollen van elk voorbeeld

Gebruik de opdracht Get-AzSqlDatabaseInstanceFailoverGroup om de rollen van elk exemplaar te bevestigen:


# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Failover naar het secundaire exemplaar

Gebruik de Switch-AzSqlDatabaseFailoverGroup om een failover uit te voeren naar het secundaire exemplaar.

# Failover the primary managed instance to the secondary role
Write-host "Failing primary over to the secondary location"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to secondary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $drLocation -Name $failoverGroupName

Controleer de rollen van elk voorbeeld

Gebruik de opdracht Get-AzSqlDatabaseInstanceFailoverGroup om de rollen van elk exemplaar te bevestigen:


# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Failovergroep terugzetten naar de primaire server

Gebruik desgewenst de opdracht Switch-AzSqlDatabaseFailoverGroup om een failback naar het primaire exemplaar uit te voeren.


# Fail primary managed instance back to primary role
Write-host "Failing primary back to primary role"
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName | Switch-AzSqlDatabaseInstanceFailoverGroup
Write-host "Successfully failed failover group to primary location"

# Verify the current primary role
Get-AzSqlDatabaseInstanceFailoverGroup -ResourceGroupName $resourceGroupName `
    -Location $location -Name $failoverGroupName

Failover bijhouden in het activiteitenlogboek

U kunt het activiteitenlogboek in Azure Portal gebruiken om de status van de failoverbewerking bij te houden. Volg hiervoor deze stappen:

Ga naar uw SQL Managed Instance in de Azure-portal.
Selecteer Activiteitenlogboek om het deelvenster Activiteitenlogboek te openen .
Wis alle filters voor resource.
Zoeken naar bewerkingen met de naam Failover Azure SQL Database failover group:

Bestaande failovergroep wijzigen

U kunt een bestaande failovergroep wijzigen, zoals het failoverbeleid wijzigen met behulp van Azure Portal, PowerShell, Azure CLI en de REST API's.

Voer de volgende stappen uit om een bestaande failovergroep te wijzigen met behulp van Azure Portal:

Ga naar uw SQL Managed Instance in de Azure-portal.
Selecteer onder Gegevensbeheerfailovergroepen om het deelvenster Failovergroepen te openen.
Selecteer in het deelvenster Failovergroepenconfiguraties bewerken op de opdrachtbalk om het deelvenster Failovergroep bewerken te openen:

Listener-eindpunt zoeken

Nadat uw failovergroep is geconfigureerd, werkt u de verbindingsreeks voor uw toepassing bij zodat deze verwijst naar het eindpunt van de lees-/schrijflistener , zodat uw toepassing na een failover verbinding blijft maken met het exemplaar dat primair is. Door het listener-eindpunt te gebruiken, hoeft u de verbindingsreeks niet handmatig bij te werken telkens wanneer uw failovergroep een failover-overschakeling uitvoert, omdat verkeer altijd naar de huidige primaire wordt doorgestuurd. U kunt ook alleen-lezen werkbelasting naar het alleen-lezen listener eindpunt verwijzen.

Belangrijk

Wanneer u verbinding maakt met een exemplaar in een failovergroep met behulp van de exemplaarspecifieke verbindingsreeks, wordt dit sterk afgeraden. Gebruik in plaats daarvan de listener-eindpunten.

Als u het listener-eindpunt in Azure Portal wilt vinden, gaat u naar uw met SQL beheerde exemplaar en selecteert u Failover-groepen onder Gegevensbeheer.

Schuif omlaag om de listener-eindpunten te vinden:

Het eindpunt van de listener lezen/schrijven , in de vorm van fog-name.dns-zone.database.windows.net, stuurt verkeer naar het primaire exemplaar.
Het read-only luisteraar-eindpunt, in de vorm van fog-name.secondary.dns-zone.database.windows.net, routeert verkeer naar de secundaire instantie.

Failovergroep maken tussen instanties in verschillende abonnementen

U kunt een failovergroep maken tussen SQL Managed Instances in twee verschillende abonnementen, zolang abonnementen zijn gekoppeld aan dezelfde Microsoft Entra-tenant.

Wanneer u De PowerShell-API gebruikt, kunt u dit doen door de PartnerSubscriptionId parameter voor het secundaire met SQL beheerde exemplaar op te geven.
Wanneer u REST API gebruikt, kan elke exemplaar-id die in de properties.managedInstancePairs parameter is opgenomen, een eigen abonnements-id hebben.
Azure Portal biedt geen ondersteuning voor het maken van failovergroepen in verschillende abonnementen.

Belangrijk

Het maken van een failovergroep tussen twee exemplaren in verschillende resourcegroepen of abonnementen wordt alleen ondersteund met Azure PowerShell of de REST API, en niet de Azure-portal of de Azure CLI.

Verlies van kritieke gegevens voorkomen

Vanwege de hoge latentie van wide area networks maakt geo-replicatie gebruik van een asynchroon replicatiemechanisme. Asynchrone replicatie maakt de mogelijkheid van gegevensverlies onvermijdelijk als de primaire mislukt. Een toepassingsontwikkelaar kan de sp_wait_for_database_copy_sync opgeslagen procedure direct na het doorvoeren van de transactie aanroepen om kritieke transacties te beschermen tegen gegevensverlies. Het aanroepen van sp_wait_for_database_copy_sync blokkeert de oproepende thread tot de laatst doorgevoerde transactie is verzonden en gehard in het transactielogboek van de secundaire database. Er wordt echter niet gewacht totdat de verzonden transacties op de secundaire opnieuw worden afgespeeld. sp_wait_for_database_copy_sync is gericht op een specifieke geo-replicatiekoppeling. Elke gebruiker met de verbindingsrechten voor de primaire database kan deze procedure aanroepen.

Opmerking

sp_wait_for_database_copy_sync voorkomt gegevensverlies na geo-failover voor specifieke transacties, maar garandeert geen volledige synchronisatie voor leestoegang. De vertraging die wordt veroorzaakt door een sp_wait_for_database_copy_sync procedure-aanroep kan aanzienlijk zijn en is afhankelijk van de grootte van het nog niet verzonden transactielogboek op de primaire op het moment van de oproep.

De secundaire regio wijzigen

Stel dat exemplaar A het primaire exemplaar is, exemplaar B het bestaande secundaire exemplaar is en exemplaar C het nieuwe secundaire exemplaar in de derde regio is. Voer de volgende stappen uit om de overgang te maken:

Maak exemplaar C met dezelfde grootte als A en in dezelfde DNS-zone.
Verwijder de failovergroep tussen exemplaren A en B. Op dit moment mislukken pogingen om zich aan te melden omdat de SQL-aliassen voor de listeners van de failovergroep zijn verwijderd en de gateway de naam van de failovergroep niet herkent. De secundaire databases worden losgekoppeld van de primaries en worden lees-/schrijfdatabases.
Maak een failovergroep met dezelfde naam tussen exemplaar A en C. Volg de instructies in de handleiding failovergroep configureren. Dit is een gegevensintensieve bewerking en wordt voltooid wanneer alle databases van exemplaar A zijn geïnitieerd en gesynchroniseerd.
Verwijder exemplaar B als dat niet nodig is om onnodige kosten te voorkomen.

Opmerking

Na stap 2 en totdat stap 3 is voltooid, blijven de databases in exemplaar A onbeveiligd tegen een onherstelbare fout van exemplaar A.

De primaire regio wijzigen

Stel dat exemplaar A het primaire exemplaar is, exemplaar B het bestaande secundaire exemplaar is en exemplaar C het nieuwe primaire exemplaar in de derde regio is. Voer de volgende stappen uit om de overgang te maken:

Maak exemplaar C met dezelfde grootte als B en in dezelfde DNS-zone.
Initieer een handmatige failover van exemplaar B om deze de nieuwe primary te maken. Exemplaar A wordt automatisch het nieuwe secundaire exemplaar.
Verwijder de failovergroep tussen exemplaren A en B. Op dit moment mislukken aanmeldingspogingen met behulp van eindpunten van failovergroepen. De secundaire databases op A worden losgekoppeld van de primaire databases en worden lees- en schrijfdatabases.
Maak een failovergroep met dezelfde naam tussen exemplaar B en C. Dit is een gegevensbewerking op basis van gegevensomvang en wordt voltooid wanneer alle databases van exemplaar B zijn doorgestuurd en gesynchroniseerd met exemplaar C. Op dit moment stoppen aanmeldingspogingen met falen.
Voer handmatig een failover uit om het C-exemplaar over te schakelen naar de primaire rol. Exemplaar B wordt automatisch het nieuwe secundaire exemplaar.
Verwijder exemplaar A als dat niet nodig is om onnodige kosten te voorkomen.

Waarschuwing

Na stap 3 en totdat stap 4 is voltooid, blijven de databases in exemplaar A onbeveiligd tegen een onherstelbare fout van exemplaar A.

Belangrijk

Wanneer de failovergroep wordt verwijderd, worden de DNS-records voor de listener-eindpunten ook verwijderd. Op dat moment is er een kans groter dan nul dat iemand anders een failovergroep met dezelfde naam aanmaakt. Omdat namen van failovergroepen wereldwijd uniek moeten zijn, voorkomt u dat u dezelfde naam opnieuw gebruikt. Gebruik geen algemene namen van failovergroepen om dit risico te minimaliseren.

Updatebeleid wijzigen

Exemplaren in een failovergroep moeten overeenkomend updatebeleid hebben. Als u het beleid altijd-up-to-datumupdate wilt inschakelen voor exemplaren die deel uitmaken van een failovergroep, schakelt u eerst het beleid altijd-up-to-datumupdate op het secundaire exemplaar in, wacht u totdat de wijziging van kracht wordt en werkt u vervolgens het beleid voor het primaire exemplaar bij.

Als u het updatebeleid voor het primaire exemplaar in de failovergroep wijzigt, wordt het exemplaar overgedragen naar een ander lokaal knooppunt (vergelijkbaar met beheerbewerkingen op exemplaren die geen deel uitmaken van een failovergroep). Dit zorgt echter niet voor een failover van de failovergroep, waardoor het primaire exemplaar de primaire rol behoudt.

Waarschuwing

Zodra het bijgewerkte beleid is gewijzigd in Always-up-to-date, is het niet meer mogelijk om het beleid voor SQL Server 2022-updates te wijzigen.

Scenario's inschakelen die afhankelijk zijn van objecten uit de systeemdatabases

Systeemdatabases worden niet gerepliceerd naar het secundaire exemplaar in een failovergroep. Als u scenario's wilt inschakelen die afhankelijk zijn van objecten uit de systeemdatabases, moet u dezelfde objecten maken op het secundaire exemplaar en deze gesynchroniseerd houden met het primaire exemplaar.

Als u bijvoorbeeld van plan bent om dezelfde aanmeldingen op het secundaire exemplaar te gebruiken, moet u deze maken met de identieke SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Voor meer informatie, zie Replicatie van aanmeldingen en agenttaken.

Exemplaareigenschappen en bewaarbeleidexemplaren synchroniseren

Exemplaren in een failovergroep blijven afzonderlijke Azure-resources en er worden geen wijzigingen in de configuratie van het primaire exemplaar automatisch gerepliceerd naar het secundaire exemplaar. Zorg ervoor dat u alle relevante wijzigingen uitvoert op zowel de primaire als secundaire instantie. Als u bijvoorbeeld redundantie van back-upopslag of bewaarbeleid voor langetermijnretentie voor back-ups op een primair exemplaar wijzigt, moet u deze ook wijzigen op het secundaire exemplaar.

Instances schalen

De configuratie van uw primaire en secundaire exemplaar moet hetzelfde zijn. Dit omvat de rekenkracht, de opslaggrootte en de servicelaag. Als u de configuratie van uw failovergroep wilt wijzigen, kunt u dit doen door elk exemplaar dienovereenkomstig te schalen naar dezelfde configuratie.

U kunt het primaire en secundaire exemplaar omhoog of omlaag schalen naar een andere rekenkracht binnen dezelfde servicelaag of naar een andere servicelaag. Houd rekening met het volgende:

Wanneer u omhoog schaalt binnen dezelfde servicelaag, schaalt u eerst de geo-secundaire laag omhoog en schaalt u vervolgens de primaire laag omhoog.
Wanneer u omlaag schaalt binnen dezelfde servicelaag, keert u de volgorde om: schaal eerst de primaire laag omlaag en schaal vervolgens de secundaire laag omlaag.

Volg dezelfde volgorde wanneer u een exemplaar schaalt naar een andere servicelaag of wanneer u de geheugentoewijzing van uw Next-gen General Purpose-exemplaar wijzigt.

Deze reeks wordt aanbevolen om problemen van de lagere geo-secundaire SKU te voorkomen, overbelast te raken en opnieuw te moeten worden verzonden tijdens een upgrade- of downgradeproces.

Machtigingen

Machtigingen voor een failovergroep worden beheerd via op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC).

De rol Bijdrager voor SQL Managed Instance, toegepast op de resourcegroepen van zowel het primaire als het secundaire beheerde exemplaar, is voldoende om alle beheerbewerkingen op failovergroepen uit te voeren.

De volgende tabel biedt een gedetailleerde weergave van minimaal vereiste machtigingen en de bijbehorende minimale vereiste bereikniveaus voor beheerbewerkingen voor failovergroepen:

Beheerbewerking	Machtiging	Omvang
Failovergroep maken/bijwerken	`Microsoft.Sql/locations/instanceFailoverGroups/write`	Resourcegroepen van primaire en secundaire beheerde instanties
Failovergroep maken/bijwerken	`Microsoft.Sql/managedInstances/write`	Primair en secundair beheerd exemplaar
Failover failovergroep	`Microsoft.Sql/locations/instanceFailoverGroups/failover/action`	Resourcegroepen van primaire en secundaire beheerde instanties
Geforceerd omschakelen van failovergroep	`Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action`	Resourcegroepen van primaire en secundaire beheerde instanties
Failovergroep verwijderen	`Microsoft.Sql/locations/instanceFailoverGroups/delete`	Resourcegroepen van primaire en secundaire beheerde instanties

Beperkingen

Houd rekening met de volgende beperkingen bij het maken van een nieuwe failovergroep:

Failovergroepen kunnen niet worden gemaakt tussen twee exemplaren in dezelfde Azure-regio.
Een exemplaar kan op elk moment slechts deelnemen aan één failovergroep.
Er kan geen failovergroep worden gemaakt tussen twee exemplaren die deel uitmaken van verschillende Azure-tenants.
Het maken van een failovergroep tussen twee exemplaren in verschillende resourcegroepen of abonnementen wordt alleen ondersteund met Azure PowerShell of de REST API, en niet de Azure-portal of de Azure CLI. Zodra de failovergroep is gemaakt, is deze zichtbaar in Azure Portal en worden alle bewerkingen ondersteund in Azure Portal of met de Azure CLI.
Als de eerste seeding van alle databases niet binnen 7 dagen wordt voltooid, mislukt het maken van de failovergroep en worden alle gerepliceerde databases verwijderd uit het secundaire exemplaar.
Het maken van een failovergroep met een exemplaar dat is geconfigureerd met een koppeling naar een beheerd exemplaar , wordt momenteel niet ondersteund.
Failovergroepen kunnen niet worden gemaakt tussen exemplaren als een of meer van hen zich in een instantiepool bevindt.
Databases die zijn gemigreerd naar Azure SQL Managed Instance met behulp van de Log Replay Service (LRS) kunnen pas worden toegevoegd aan een failovergroep nadat de cutover-stap is uitgevoerd.

Houd rekening met de volgende beperkingen bij het gebruik van failovergroepen:

Namen van failovergroepen kunnen niet worden gewijzigd. U moet de groep verwijderen en opnieuw maken met een andere naam.
Een failovergroep bevat precies twee beheerde exemplaren. Het toevoegen van extra instanties aan de failovergroep wordt niet ondersteund.
Volledige back-ups worden automatisch gemaakt:
- voor de initiële zaaiing en kan het begin van het initiële zaaiingsproces aanzienlijk vertragen.
- na een failover en kan een volgende failover vertragen of voorkomen.
Het hernoemen van de database wordt niet ondersteund voor databases in een failovergroep. U moet de failovergroep tijdelijk verwijderen om de naam van een database te kunnen wijzigen.
Systeemdatabases worden niet gerepliceerd naar het secundaire exemplaar in een failovergroep. Daarom moeten voor scenario's die afhankelijk zijn van objecten van de systeemdatabases, zoals serveraanmeldings- en agenttaken, objecten handmatig worden gemaakt op de secundaire exemplaren en ook handmatig gesynchroniseerd blijven nadat er wijzigingen zijn aangebracht in het primaire exemplaar. De enige uitzondering is Service master Key (SMK) voor SQL Managed Instance die automatisch wordt gerepliceerd naar een secundair exemplaar tijdens het maken van een failovergroep. Eventuele volgende wijzigingen van SMK op het primaire exemplaar worden echter niet gerepliceerd naar een secundair exemplaar. Zie Scenario's inschakelen die afhankelijk zijn van objecten uit de systeemdatabases voor meer informatie.
Voor exemplaren binnen een failovergroep wordt het wijzigen van de servicelaag naar of van de Next-gen algemene doellaag niet ondersteund. U moet eerst de failovergroep verwijderen voordat u een van beide replica's wijzigt en vervolgens de failovergroep opnieuw maken nadat de wijziging is doorgevoerd.
Beheerde SQL-exemplaren in een failovergroep moeten hetzelfde updatebeleid hebben, maar het is mogelijk om het updatebeleid voor exemplaren binnen een failovergroep te wijzigen.

Failovergroepen programmatisch beheren

Failovergroepen kunnen ook programmatisch worden beheerd met behulp van Azure PowerShell, Azure CLI en REST API. In de volgende tabellen wordt de set opdrachten beschreven die beschikbaar zijn. Failovergroepen bevatten een set Azure Resource Manager-API's voor beheer, waaronder de Azure SQL Database REST API en Azure PowerShell-cmdlets. Deze API's vereisen het gebruik van resourcegroepen en ondersteunen op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). Raadpleeg voor meer informatie over hoe u toegangsrollen kunt implementeren Azure rolgebaseerd toegangsbeheer (Azure RBAC).

Cmdlet	Beschrijving
New-AzSqlDatabaseInstanceFailoverGroup	Met deze opdracht maakt u een failovergroep en registreert u deze op zowel primaire als secundaire exemplaren
Set-AzSqlDatabaseInstanceFailoverGroup	Wijzigt de configuratie van een failovergroep
Get-AzSqlDatabaseInstanceFailoverGroup	Hiermee wordt de configuratie van een failovergroep opgehaald
Switch-AzSqlDatabaseInstanceFailoverGroup	Hiermee wordt een failover van een failovergroep naar het secundaire exemplaar geactiveerd
Remove-AzSqlDatabaseInstanceFailoverGroup	Hiermee verwijdert u een failovergroep

Opdracht	Beschrijving
az sql instance-failover-group create	Met deze opdracht maakt u een failovergroep en registreert u deze op zowel primaire als secundaire servers
az sql instance-failover-groep verwijderen	Hiermee verwijdert u een failovergroep van de server
az sql instance-failover-group show	Hiermee haalt u een configuratie van een failovergroep op
az sql instance-failover-group bijwerken	Wijzigt de configuratie van een failovergroep en/of voegt een of meer databases toe aan een failovergroep
az sql instance-failover-group set-primary (stel de primaire groep in voor SQL-instantiefailover)	Hiermee wordt een failover van een failovergroep naar de secundaire server geactiveerd

API (Application Programming Interface)	Beschrijving
Een failovergroep maken of bijwerken	De configuratie van een failovergroep maken of bijwerken
Failovergroep verwijderen	Hiermee wordt een failovergroep verwijderd uit de instantie
Failover (gepland)	Hiermee wordt een failover van het huidige primaire exemplaar naar dit exemplaar geactiveerd met volledige gegevenssynchronisatie.
Forceer failover en sta gegevensverlies toe	Hiermee wordt een failover van het huidige primaire exemplaar naar het secundaire exemplaar geactiveerd zonder gegevens te synchroniseren. Deze bewerking kan leiden tot gegevensverlies.
Failovergroep ophalen	Haalt de configuratie van een failovergroep op.
Failovergroepen weergeven - Lijst op locatie	Geeft een lijst weer van de failovergroepen op een locatie.

Delen via

Een failovergroep configureren voor Azure SQL Managed Instance

Vereiste voorwaarden

Configuratievereisten

Het secundaire exemplaar maken

Virtueel netwerk maken

Secundair exemplaar maken

Connectiviteit tussen de exemplaren tot stand brengen

Poorten en NSG-regels configureren

De failovergroep maken

Failover testen

Failover bijhouden in het activiteitenlogboek

Bestaande failovergroep wijzigen

Listener-eindpunt zoeken

Failovergroep maken tussen instanties in verschillende abonnementen

Verlies van kritieke gegevens voorkomen

De secundaire regio wijzigen

De primaire regio wijzigen

Updatebeleid wijzigen

Scenario's inschakelen die afhankelijk zijn van objecten uit de systeemdatabases

Exemplaareigenschappen en bewaarbeleidexemplaren synchroniseren

Instances schalen

Machtigingen

Beperkingen

Failovergroepen programmatisch beheren

Verwante inhoud

Feedback

Aanvullende resources