Hoge beschikbaarheid voor Azure SQL Database en SQL Managed Instance

Van toepassing op: Azure SQL Database Azure SQL Managed Instance

In dit artikel worden hoge beschikbaarheid in Azure SQL Database en Azure SQL Managed Instance beschreven.

Zone-redundante configuratie is momenteel in preview voor SQL Managed Instance en alleen beschikbaar voor de Bedrijfskritiek servicelaag.

Overzicht

Het doel van de architectuur voor hoge beschikbaarheid in Azure SQL Database en SQL Managed Instance is om ervoor te zorgen dat uw database minimaal 99,99% van de tijd actief is zonder dat u zich zorgen hoeft te maken over de gevolgen van onderhoudsbewerkingen en storingen. Raadpleeg SLA voor Azure SQL Database en SLA voor Azure SQL Managed Instance voor meer informatie over specifieke SLA's voor verschillende lagen.

Azure verwerkt automatisch kritieke onderhoudstaken, zoals patching, back-ups, Windows- en Azure SQL-upgrades en niet-geplande gebeurtenissen, zoals onderliggende hardware-, software- of netwerkfouten. Wanneer de onderliggende database in Azure SQL Database wordt gepatcht of een failover wordt uitgevoerd, is de downtime niet merkbaar als u logica voor opnieuw proberen in uw app gebruikt. SQL Database en SQL Managed Instance kunnen snel herstellen, zelfs in de meest kritieke omstandigheden, zodat uw gegevens altijd beschikbaar zijn.

De oplossing voor hoge beschikbaarheid is ontworpen om ervoor te zorgen dat vastgelegde gegevens nooit verloren gaan als gevolg van storingen, dat onderhoudsbewerkingen geen invloed hebben op uw workload en dat de database geen Single Point of Failure in uw softwarearchitectuur is. Er zijn geen onderhoudsvensters of downtime waarvoor u de workload moet stoppen terwijl de database wordt bijgewerkt of onderhouden.

Er zijn twee architectuurmodellen voor hoge beschikbaarheid:

  • Standaard beschikbaarheidsmodel dat is gebaseerd op een scheiding van rekenkracht en opslag. Het is afhankelijk van hoge beschikbaarheid en betrouwbaarheid van de externe opslaglaag. Deze architectuur is gericht op budgetgerichte zakelijke toepassingen die prestatievermindering tijdens onderhoudsactiviteiten kunnen tolereren.
  • Premium-beschikbaarheidsmodel dat is gebaseerd op een cluster van database-engineprocessen. Het is afhankelijk van het feit dat er altijd een quorum van beschikbare database-engineknooppunten is. Deze architectuur is gericht op bedrijfskritieke toepassingen met hoge I/O-prestaties en hoge transactiesnelheid en garandeert minimale impact op de prestaties van uw workload tijdens onderhoudsactiviteiten.

SQL Database en SQL Managed Instance beide worden uitgevoerd op de meest recente stabiele versie van de SQL Server-database-engine en het Windows-besturingssysteem. De meeste gebruikers merken niet dat er continu upgrades worden uitgevoerd.

Lokaal redundante beschikbaarheid van de servicelaag Basic, Standard en Algemeen

De servicelagen Basic, Standard en Algemeen maken gebruik van de standaard beschikbaarheidsarchitectuur voor zowel serverloze als ingerichte rekenkracht. In de volgende afbeelding ziet u vier verschillende knooppunten met de gescheiden reken- en opslaglagen.

Scheiding van rekenkracht en opslag

Het standaard beschikbaarheidsmodel bevat twee lagen:

  • Een staatloze rekenlaag die het sqlservr.exe proces uitvoert en alleen tijdelijke en in de cache opgeslagen gegevens bevat, zoals TempDB, modeldatabases op de gekoppelde SSD en plancache, buffergroep en columnstore-pool in het geheugen. Dit stateless knooppunt wordt beheerd door Azure Service Fabric dat de status van het knooppunt initialiseert sqlservr.exe, beheert en indien nodig een failover naar een ander knooppunt uitvoert.
  • Een stateful gegevenslaag met de databasebestanden (.mdf/.ldf) die zijn opgeslagen in Azure Blob Storage. Azure Blob Storage beschikt over een ingebouwde functie voor beschikbaarheid en redundantie van gegevens. Het garandeert dat elke record in het logboekbestand of de pagina in het gegevensbestand behouden blijft, zelfs als sqlservr.exe het proces vastloopt.

Wanneer de database-engine of het besturingssysteem wordt bijgewerkt of wanneer er een fout wordt gedetecteerd, verplaatst Azure Service Fabric het staatloze sqlservr.exe proces naar een ander staatloos rekenknooppunt met voldoende vrije capaciteit. Gegevens in Azure Blob Storage worden niet beïnvloed door de verplaatsing en de gegevens/logboekbestanden worden gekoppeld aan het zojuist geïnitialiseerde sqlservr.exe proces. Dit proces garandeert een beschikbaarheid van 99,99%, maar een zware workload kan enige prestatievermindering ondervinden tijdens de overgang omdat het nieuwe sqlservr.exe proces begint met een koude cache.

zoneredundante beschikbaarheid van Algemeen-servicelaag

Zone-redundante configuratie voor de Algemeen servicelaag wordt aangeboden voor zowel serverloze als ingerichte rekenkracht. Deze configuratie maakt gebruik van Azure Beschikbaarheidszones om databases te repliceren op meerdere fysieke locaties binnen een Azure-regio. Door zoneredundantie te selecteren, kunt u uw nieuwe en bestaande serverloze en ingerichte individuele databases en elastische pools voor algemeen gebruik bestand maken tegen een veel grotere reeks storingen, waaronder onherstelbare datacentrumstoringen, zonder wijzigingen in de toepassingslogica.

Zone-redundante configuratie voor de Algemeen-laag heeft twee lagen:

  • Een stateful gegevenslaag met de databasebestanden (.mdf/.ldf) die zijn opgeslagen in ZRS (zone-redundante opslag). Met behulp van ZRS worden de gegevens en logboekbestanden synchroon gekopieerd in drie fysiek geïsoleerde Azure-beschikbaarheidszones.
  • Een stateless rekenlaag die het sqlservr.exe-proces uitvoert en alleen tijdelijke en in de cache opgeslagen gegevens bevat, zoals TempDB, modeldatabases op de gekoppelde SSD en plancache, buffergroep en columnstore-pool in het geheugen. Dit stateless knooppunt wordt beheerd door Azure Service Fabric dat sqlservr.exe initialiseert, de status van het knooppunt beheert en indien nodig failover naar een ander knooppunt uitvoert. Voor zone-redundante serverloze en ingerichte Algemeen databases zijn knooppunten met reservecapaciteit direct beschikbaar in andere Beschikbaarheidszones voor failover.

De zone-redundante versie van de architectuur voor hoge beschikbaarheid voor de servicelaag Algemeen wordt geïllustreerd door het volgende diagram:

Zone-redundante configuratie voor Algemeen

Belangrijk

  • Voor Algemeen laag is de zone-redundante configuratie algemeen beschikbaar in de volgende regio's: Europa - west, Europa - noord, VS - west 2, Frankrijk - centraal, VS - oost 2 & VS - oost. Dit is in preview in de volgende regio's: Azië - zuidoost, Australië - oost, Japan - oost en VK - zuid.
  • Voor zone-redundante beschikbaarheid is het kiezen van een ander onderhoudsvenster dan het standaardvenster momenteel beschikbaar in bepaalde regio's.
  • Zone-redundante configuratie is alleen beschikbaar in SQL Database wanneer Gen5-hardware is geselecteerd. Zone-redundante configuratie is momenteel in preview voor SQL Managed Instance en alleen beschikbaar voor de Bedrijfskritiek servicelaag.

Lokaal redundante beschikbaarheid van premium- en Bedrijfskritiek-servicelaag

Premium- en Bedrijfskritiek-servicelagen maken gebruik van het Premium-beschikbaarheidsmodel, dat rekenresources (sqlservr.exeproces) en opslag (lokaal gekoppelde SSD) op één knooppunt integreert. Hoge beschikbaarheid wordt bereikt door zowel rekenkracht als opslag te repliceren naar extra knooppunten, waardoor een cluster van drie tot vier knooppunten wordt gemaakt.

Cluster van database-engineknooppunten

De onderliggende databasebestanden (.mdf/.ldf) worden op de gekoppelde SSD-opslag geplaatst om een I/O met een zeer lage latentie te bieden voor uw workload. Hoge beschikbaarheid wordt geïmplementeerd met behulp van een technologie die vergelijkbaar is met SQL Server AlwaysOn-beschikbaarheidsgroepen. Het cluster bevat één primaire replica die toegankelijk is voor lees-/schrijfworkloads van klanten, en maximaal drie secundaire replica's (berekening en opslag) met kopieën van gegevens. Het primaire knooppunt pusht voortdurend wijzigingen naar de secundaire knooppunten in de juiste volgorde en zorgt ervoor dat de gegevens op ten minste één secundaire replica worden bewaard voordat elke transactie wordt doorgevoerd. Dit proces garandeert dat als het primaire knooppunt om welke reden dan ook vastloopt, er altijd een volledig gesynchroniseerd knooppunt is waarnaar een failover moet worden uitgevoerd. De failover wordt geïnitieerd door de Azure Service Fabric. Zodra de secundaire replica het nieuwe primaire knooppunt wordt, wordt er een andere secundaire replica gemaakt om ervoor te zorgen dat het cluster voldoende knooppunten (quorumset) heeft. Zodra de failover is voltooid, worden Azure SQL verbindingen automatisch omgeleid naar het nieuwe primaire knooppunt.

Als extra voordeel biedt het Premium-beschikbaarheidsmodel de mogelijkheid om alleen-lezen Azure SQL verbindingen om te leiden naar een van de secundaire replica's. Deze functie heet Uitschalen lezen. Het biedt 100% extra rekencapaciteit zonder extra kosten voor off-load alleen-lezen bewerkingen, zoals analytische workloads, van de primaire replica.

Zone-redundante beschikbaarheid van premium- en Bedrijfskritiek-servicelagen

Standaard wordt het cluster met knooppunten voor het Premium-beschikbaarheidsmodel gemaakt in hetzelfde datacenter. Met de introductie van Azure Beschikbaarheidszones kunnen SQL Database verschillende replica's van de Bedrijfskritiek-database in verschillende beschikbaarheidszones in dezelfde regio plaatsen. Om een Single Point of Failure te elimineren, wordt de besturingsring ook gedupliceerd in meerdere zones als drie gatewayringen (GW). De routering naar een specifieke gatewayring wordt beheerd door Azure Traffic Manager (ATM). Omdat de zone-redundante configuratie in de servicelagen Premium of Bedrijfskritiek geen extra databaseredundantie creëert, kunt u deze zonder extra kosten inschakelen. Door een zone-redundante configuratie te selecteren, kunt u ervoor zorgen dat uw Premium- of Bedrijfskritiek-databases bestand zijn tegen een veel grotere set fouten, waaronder onherstelbare datacentrumstoringen, zonder wijzigingen in de toepassingslogica. U kunt ook alle bestaande Premium- of Bedrijfskritiek-databases of -pools converteren naar de zone-redundante configuratie.

Omdat de zone-redundante databases replica's hebben in verschillende datacenters met enige afstand ertussen, kan de verhoogde netwerklatentie de doorvoertijd verhogen en zo de prestaties van sommige OLTP-workloads beïnvloeden. U kunt altijd terugkeren naar de configuratie met één zone door de instelling zoneredundantie uit te schakelen. Dit proces is een onlinebewerking die vergelijkbaar is met de normale upgrade van de servicelaag. Aan het einde van het proces wordt de database of pool gemigreerd van een zone-redundante ring naar één zonering of omgekeerd.

Belangrijk

Deze functie is niet beschikbaar in SQL Managed Instance. Wanneer u in SQL Database de Bedrijfskritiek-laag gebruikt, is zone-redundante configuratie alleen beschikbaar wanneer de hardware van de standaardserie (Gen5) is geselecteerd. Zie Services ondersteunen per regio voor actuele informatie over de regio's die zone-redundante databases ondersteunen.

De zone-redundante versie van de architectuur voor hoge beschikbaarheid wordt geïllustreerd door het volgende diagram:

Diagram van de zone-redundante architectuur voor hoge beschikbaarheid.

Belangrijk

  • Deze functie is momenteel in preview voor SQL Managed Instance en alleen beschikbaar in de Bedrijfskritiek servicelaag. Wanneer u in SQL Database de Bedrijfskritiek laag gebruikt, is zone-redundante configuratie alleen beschikbaar wanneer de Gen5-hardware is geselecteerd. Zie Services ondersteunen per regio voor actuele informatie over de regio's die zone-redundante databases ondersteunen.
  • Voor zone-redundante beschikbaarheid is het kiezen van een ander onderhoudsvenster dan het standaardvenster momenteel beschikbaar in bepaalde regio's.

Belangrijk

Voor zone-redundante beschikbaarheid is het kiezen van een ander onderhoudsvenster dan het standaardvenster momenteel beschikbaar in bepaalde regio's.

Tijdens de preview is zoneredundantie voor SQL Managed Instance beschikbaar in de servicelaag Bedrijfskritiek en wordt deze ondersteund in de volgende regio's:

  • Brazilië - zuid
  • VS - oost
  • Japan - oost
  • Noorwegen - oost
  • VAE - noord
  • Zuid-Afrika - noord
  • Australië - oost
  • Korea - centraal

Lokaal redundante beschikbaarheid van de Hyperscale-servicelaag

De architectuur van de Hyperscale-servicelaag wordt beschreven in Gedistribueerde-functiearchitectuur en is momenteel alleen beschikbaar voor SQL Database, niet SQL Managed Instance.

Functionele architectuur van Hyperscale

Het beschikbaarheidsmodel in Hyperscale bevat vier lagen:

  • Een staatloze rekenlaag die de sqlservr.exe processen uitvoert en alleen tijdelijke en in de cache opgeslagen gegevens bevat, zoals RBPEX-cache, TempDB, modeldatabase, enzovoort op de gekoppelde SSD, en plancache, buffergroep en columnstore-pool in het geheugen. Deze staatloze laag bevat de primaire rekenreplica en optioneel een aantal secundaire rekenreplica's die als failoverdoelen kunnen dienen.
  • Een staatloze opslaglaag die wordt gevormd door paginaservers. Deze laag is de gedistribueerde opslag-engine voor de sqlservr.exe processen die worden uitgevoerd op de rekenreplica's. Elke paginaserver bevat alleen tijdelijke gegevens en gegevens in de cache, zoals de RBPEX-cache op de gekoppelde SSD en gegevenspagina's die in het geheugen zijn opgeslagen. Elke paginaserver heeft een gekoppelde paginaserver in een actief-actief-configuratie voor taakverdeling, redundantie en hoge beschikbaarheid.
  • Een stateful opslaglaag voor transactielogboeken die wordt gevormd door het rekenknooppunt waarop het logserviceproces wordt uitgevoerd, de landingszone van het transactielogboek en de langetermijnopslag van het transactielogboek. Landingszone en langetermijnopslag maken gebruik van Azure Storage, dat beschikbaarheid en redundantie biedt voor transactielogboeken, waardoor de duurzaamheid van gegevens voor vastgelegde transacties wordt gegarandeerd.
  • Een stateful gegevensopslaglaag met de databasebestanden (.mdf/.ndf) die zijn opgeslagen in Azure Storage en worden bijgewerkt door paginaservers. Deze laag maakt gebruik van de functies voor beschikbaarheid en redundantie van gegevens van Azure Storage. Het garandeert dat elke pagina in een gegevensbestand behouden blijft, zelfs als processen in andere lagen van de Hyperscale-architectuur vastlopen of als rekenknooppunten mislukken.

Rekenknooppunten in alle Hyperscale-lagen worden uitgevoerd op Azure Service Fabric, waarmee de status van elk knooppunt wordt beheerd en indien nodig failovers worden uitgevoerd naar beschikbare gezonde knooppunten.

Zie Hoge beschikbaarheid van databases in Hyperscale voor meer informatie over hoge beschikbaarheid in Hyperscale.

Zone-redundante beschikbaarheid van Hyperscale-servicelaag

Het inschakelen van deze configuratie zorgt voor tolerantie op zoneniveau via replicatie tussen Beschikbaarheidszones voor alle Hyperscale-lagen. Door zoneredundantie te selecteren, kunt u uw Hyperscale-databases bestand maken tegen een veel grotere set fouten, waaronder onherstelbare datacentrumstoringen, zonder wijzigingen in de toepassingslogica. Alle Azure-regio's met Beschikbaarheidszones ondersteunen zoneredundante Hyperscale-database.

Houd rekening met de volgende beperkingen:

  • Zone-redundante configuratie kan alleen worden opgegeven tijdens het maken van de database. Deze instelling kan niet worden gewijzigd nadat de resource is ingericht. Gebruik Databasekopie, herstel naar een bepaald tijdstip of maak een geo-replica om de zone-redundante configuratie voor een bestaande Hyperscale-database bij te werken. Wanneer u een van deze bijwerkopties gebruikt en de doeldatabase zich in een andere regio dan de bron bevindt of als de redundantie van de back-upopslag van de database afwijkt van het doel van de brondatabase, is de kopieerbewerking een grootte van de gegevensbewerking.
  • Alleen standaardhardware (Gen5) wordt ondersteund.
  • Benoemde replica's worden momenteel niet ondersteund.
  • Zoneredundantie kan momenteel niet worden opgegeven bij het migreren van een bestaande database van een andere Azure SQL Database-servicelaag naar Hyperscale.
  • Ten minste 1 rekenreplica met hoge beschikbaarheid en het gebruik van zone-redundante of geografisch zone-redundante back-upopslag is vereist voor het inschakelen van de zone-redundante configuratie voor Hyperscale.

Belangrijk

Voor zone-redundante beschikbaarheid is het kiezen van een ander onderhoudsvenster dan het standaardvenster momenteel beschikbaar in bepaalde regio's.

Een zoneredundante Hyperscale-database maken

Gebruik Azure PowerShell of de Azure CLI om een zoneredundante Hyperscale-database te maken. Controleer of u de nieuwste versie van de API hebt om ondersteuning voor recente wijzigingen te garanderen.

Geef de -ZoneRedundant parameter op voor het inschakelen van zoneredundantie voor uw Hyperscale-database met behulp van Azure PowerShell. De database moet ten minste 1 replica met hoge beschikbaarheid hebben en zone-redundante back-upopslag moet worden opgegeven.

Als u zoneredundantie wilt inschakelen met behulp van Azure PowerShell, gebruikt u de volgende voorbeeldopdracht:

New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" `
    -Edition "Hyperscale" -HighAvailabilityReplicaCount 1 -ZoneRedundant -BackupStorageRedundancy Zone -RequestedServiceObjectiveName HS_Gen5_2'

Een zoneredundante Hyperscale-database maken door een geo-replica te maken

Als u een bestaande Hyperscale-databasezone redundant wilt maken, gebruikt u Azure PowerShell of de Azure CLI om een zoneredundante Hyperscale-database te maken met behulp van actieve geo-replicatie. De geo-replica kan zich in dezelfde of een andere regio bevinden als de bestaande Hyperscale-database.

Geef de -ZoneRedundant parameter op om zoneredundantie in te schakelen voor de secundaire Hyperscale-database. De secundaire database moet ten minste 1 replica met hoge beschikbaarheid hebben en zone-redundante back-upopslag moet worden opgegeven.

Gebruik de volgende voorbeeldopdracht om uw zone-redundante database te maken met behulp van Azure PowerShell:

New-AzSqlDatabaseSecondary -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -PartnerResourceGroupName "myPartnerResourceGroup" -PartnerServerName $targetserver -PartnerDatabaseName "zoneRedundantCopyOfMySampleDatabase" -ZoneRedundant -BackupStorageRedundancy Zone -HighAvailabilityReplicaCount 1

Een zoneredundante Hyperscale-database maken door een databasekopie te maken

Als u een bestaande Hyperscale-databasezone redundant wilt maken, gebruikt u Azure PowerShell of de Azure CLI om een zoneredundante Hyperscale-database te maken met behulp van databasekopie. De databasekopie kan zich in dezelfde of een andere regio bevinden als de bestaande Hyperscale-database.

Geef de -ZoneRedundant parameter op om zoneredundantie in te schakelen voor uw Hyperscale-databasekopie. De databasekopie moet ten minste 1 replica met hoge beschikbaarheid hebben en er moet zone-redundante back-upopslag worden opgegeven.

Gebruik de volgende voorbeeldopdracht om uw zone-redundante database te maken met behulp van Azure PowerShell:

New-AzSqlDatabaseCopy -ResourceGroupName "myResourceGroup" -ServerName $sourceserver -DatabaseName "databaseName" -CopyResourceGroupName "myCopyResourceGroup" -CopyServerName $copyserver -CopyDatabaseName "zoneRedundantCopyOfMySampleDatabase" -ZoneRedundant -BackupStorageRedundancy Zone 

Redundante beschikbaarheid van hoofddatabasezone

In Azure SQL Database is een server een logische constructie die fungeert als een centraal beheerpunt voor een verzameling databases. Op serverniveau kunt u aanmeldingen, Azure Active Directory-verificatie, firewallregels, controleregels, beleidsregels voor bedreigingsdetectie en groepen voor automatische failover beheren. Gegevens met betrekking tot sommige van deze functies, zoals aanmeldingen en firewallregels, worden opgeslagen in de hoofddatabase. Op dezelfde manier worden gegevens voor sommige DMV's, bijvoorbeeld sys.resource_stats, ook opgeslagen in de hoofddatabase.

Wanneer een database met een zone-redundante configuratie wordt gemaakt op een logische server, wordt de hoofddatabase die aan de server is gekoppeld, ook automatisch zone-redundant gemaakt. Dit zorgt ervoor dat in een zonegebonden storing toepassingen die de database gebruiken, niet worden beïnvloed omdat functies die afhankelijk zijn van de hoofddatabase, zoals aanmeldingen en firewallregels, nog steeds beschikbaar zijn. Het zone-redundant maken van de hoofddatabase is een asynchroon proces en duurt enige tijd om op de achtergrond te worden voltooid.

Wanneer geen van de databases op een server zone-redundant zijn of wanneer u een lege server maakt, is de hoofddatabase die aan de server is gekoppeld , niet zone-redundant.

U kunt Azure PowerShell of de Azure CLI of de REST API gebruiken om de ZoneRedundant eigenschap voor de hoofddatabase te controleren:

Gebruik de volgende voorbeeldopdracht om de waarde van de eigenschap ZoneRedundant voor de hoofddatabase te controleren.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

Versneld databaseherstel (ADR)

Accelerated Database Recovery (ADR) is een functie van de database-engine die de beschikbaarheid van databases aanzienlijk verbetert, met name bij langdurige transacties. ADR is momenteel beschikbaar voor Azure SQL Database, Azure SQL Managed Instance en Azure Synapse Analytics.

Fouttolerantie van toepassing testen

Hoge beschikbaarheid is een fundamenteel onderdeel van het SQL Database- en SQL Managed Instance-platform dat transparant werkt voor uw databasetoepassing. We erkennen echter dat u wellicht wilt testen hoe de automatische failoverbewerkingen die worden geïnitieerd tijdens geplande of niet-geplande gebeurtenissen van invloed zijn op een toepassing voordat u deze implementeert voor productie. U kunt handmatig een failover activeren door een speciale API aan te roepen om een database, een elastische pool of een beheerd exemplaar opnieuw te starten. In het geval van een zone-redundante serverloze of ingerichte Algemeen database of elastische pool, zou de API-aanroep ertoe leiden dat clientverbindingen worden omgeleid naar de nieuwe primaire in een beschikbaarheidszone die verschilt van de beschikbaarheidszone van de oude primaire. Dus naast het testen van de invloed van failover op bestaande databasesessies, kunt u ook controleren of de end-to-end-prestaties worden gewijzigd als gevolg van wijzigingen in de netwerklatentie. Omdat de herstartbewerking opdringerig is en een groot aantal hiervan het platform kan belasten, wordt slechts één failover-aanroep elke 15 minuten toegestaan voor elke database, elastische pool of beheerd exemplaar.

Een failover kan worden gestart met behulp van PowerShell, REST API of Azure CLI:

Implementatietype PowerShell REST-API Azure CLI
Database Invoke-AzSqlDatabaseFailover Databasefailover az rest kan worden gebruikt om een REST API-aanroep aan te roepen vanuit Azure CLI
Elastische pool Invoke-AzSqlElasticPoolFailover Failover van elastische pool az rest kan worden gebruikt om een REST API-aanroep aan te roepen vanuit Azure CLI
SQL Managed Instance Invoke-AzSqlInstanceFailover SQL Managed Instance - Failover az sql mi failover kan worden gebruikt voor het aanroepen van een REST API-aanroep vanuit Azure CLI

Belangrijk

De opdracht Failover is niet beschikbaar voor leesbare secundaire replica's van Hyperscale-databases.

Conclusie

Azure SQL Database en Azure SQL Managed Instance beschikken over een ingebouwde oplossing voor hoge beschikbaarheid, die diep is geïntegreerd met het Azure-platform. Het is afhankelijk van Service Fabric voor foutdetectie en -herstel, op Azure Blob-opslag voor gegevensbeveiliging en op Beschikbaarheidszones voor een hogere fouttolerantie (zoals eerder vermeld in het document dat nog niet van toepassing is op Azure SQL Managed Instance). Daarnaast gebruiken SQL Database en SQL Managed Instance de AlwaysOn-technologie van de SQL Server-instantie voor replicatie en failover. De combinatie van deze technologieën stelt toepassingen in staat om de voordelen van een model voor gemengde opslag volledig te benutten en ondersteuning te bieden voor de meest veeleisende SLA's.

Volgende stappen