Toepassingstolerantie inschakelen met Azure SQL Database

Voltooid

Geo-replicatie en groepen voor automatische failover zijn beide mechanismen die worden gebruikt in Azure SQL Database om de beschikbaarheid en herstel na noodgevallen te verbeteren, maar ze hebben enkele belangrijke verschillen.

Inzicht in actieve geo-replicatie

Een methode voor het verhogen van de beschikbaarheid voor een Azure SQL Database is het gebruik van actieve geo-replicatie. Actieve geo-replicatie is ontworpen als een bedrijfscontinuïteitsoplossing waarmee u leesbare secundaire databases van afzonderlijke databases op een server in dezelfde of een andere regio kunt maken. Het ondersteunt maximaal vier secundaire replica's en wordt per database geconfigureerd.

Achter de schermen maakt Azure gebruik van beschikbaarheidsgroepen om deze functionaliteit te bieden. Met actieve geo-replicatie kunnen klanten programmatisch of handmatig primaire databases naar secundaire regio's failovern tijdens grote noodgevallen.

Om replicatieoverhead te voorkomen van een grote schrijfworkload die van invloed kan zijn op de replicatieprestaties, is het raadzaam om de geo-secundaire te configureren met dezelfde servicelaag en rekenkracht als de primaire.

U kunt geo-replicatie voor Azure SQL Database handmatig configureren door toegang te krijgen tot de databasepagina en replica's te selecteren in de sectie Gegevensbeheer .

Nadat de secundaire replica is gemaakt, kunt u handmatig een failover initiëren. Hiermee worden de rollen overgeschakeld, waardoor de secundaire de nieuwe primaire en de oude primaire de nieuwe secundaire worden.

Geo-replicatie is asynchroon, wat betekent dat er mogelijk sprake is van enige gegevensvertraging tussen de primaire en secundaire databases. Bovendien moet de toepassing verbindingsreeks na een failover worden bijgewerkt.

Geo-replicatie tussen abonnementen configureren

In bepaalde scenario's moet u mogelijk een secundaire replica configureren voor een ander abonnement dan de primaire database. Hier komt geo-replicatie tussen abonnementen in het spel. Met deze functie kunt u een secundaire replica instellen in een ander abonnement, wat meer flexibiliteit en verbeterde opties voor herstel na noodgevallen biedt. Door geo-replicatie tussen abonnementen te gebruiken, kunt u ervoor zorgen dat uw gegevens worden beveiligd en toegankelijk, zelfs als één abonnement problemen ondervindt. Deze instelling is handig voor organisaties met meerdere abonnementen of organisaties die een robuust plan voor bedrijfscontinuïteit willen implementeren.

Zie Geo-replicatie tussen abonnementen voor meer informatie over de stappen die nodig zijn voor het configureren van geo-replicatie tussen abonnementen.

Groepen voor automatische failover inschakelen

Een groep voor automatische failover is een beschikbaarheidsfunctie die kan worden gebruikt met zowel Azure SQL Database als Azure SQL Managed Instance. Met groepen voor automatische failover kunt u beheren hoe databases worden gerepliceerd naar een andere regio en kunt u beheren hoe failover kan plaatsvinden. De naam die is toegewezen aan de groep voor automatische failover, moet uniek zijn binnen het domein *.database.windows.net .

Groepen voor automatische failover bieden ag-achtige functionaliteit via een listener, waardoor zowel lezen-schrijven als alleen-lezen activiteiten worden ingeschakeld. Deze functionaliteit verschilt enigszins van actieve geo-replicatie. Er zijn twee soorten listeners: één voor lezen/schrijven-verkeer en een andere voor alleen-lezen verkeer. Tijdens een failover kunnen clients via DNS-updates verbinding maken met de naam van de listener zonder dat er aanvullende informatie nodig is. De databaseserver met de lees-/schrijfkopieën is de primaire server, terwijl de server die transacties van de primaire server ontvangt, de secundaire is.

Groepen voor automatische failover hebben twee verschillende beleidsregels die kunnen worden geconfigureerd.

• Door de klant beheerde (aanbevolen) - klanten kunnen handmatig een failover initiëren wanneer ze een onverwachte storing detecteren die van invloed is op een of meer databases in de failovergroep. Deze handmatige failover kan worden uitgevoerd met opdrachtregelprogramma's zoals PowerShell, de Azure CLI of de Rest API.
• Door Microsoft beheerd : ze worden automatisch door Microsoft geïnitieerd tijdens een wijdverspreide storing die van invloed is op een primaire regio. Deze automatische failover is van toepassing op alle betrokken failovergroepen met hun failoverbeleid ingesteld op door Microsoft beheerd.

Niet-geplande failover kan leiden tot gegevensverlies als geforceerd en de secundaire niet volledig is gesynchroniseerd met de primaire. Het configureren van GracePeriodWithDataLossHours besturingselementen hoe lang Azure wacht voordat een failover wordt uitgevoerd. De standaardwaarde is één uur. Als u een strakke RPO hebt en u zich niet veel gegevensverlies kunt veroorloven, stelt u de waarde hoger in. Hoewel Azure langer wacht voordat er een failover wordt uitgevoerd, kan deze aanpak leiden tot minder gegevensverlies, omdat de secundaire methode meer tijd heeft om volledig te synchroniseren met de primaire.

Daarnaast kan een groep voor automatische failover een of meer databases bevatten, met dezelfde grootte en editie op zowel de primaire als de secundaire servers. De database op de secundaire server wordt automatisch gemaakt via een proces dat seeding wordt genoemd. Dit kan enige tijd duren, afhankelijk van de grootte van de database. Het is belangrijk om dienovereenkomstig te plannen en rekening te houden met factoren zoals netwerksnelheid.

hoe u kunt kiezen

Geo-replicatie is geschikt voor scenario's waarbij u meerdere leesbare replica's nodig hebt en handmatige failover acceptabel is, terwijl automatische failovergroepen ideaal zijn voor scenario's waarvoor automatische failover en synchrone replicatie voor een groep databases is vereist.

In de volgende tabel worden de functies van geo-replicatie en groepen voor automatische failover vergeleken, samen met andere relevante details.

Functie	Geo-replicatie	Groepen voor automatische failover
Aantal replica's	Ondersteunt maximaal vier secundaire replica's.	Ondersteunt slechts één secundaire replica
Configuratieniveau	Geconfigureerd per database.	Geconfigureerd voor een groep databases
Replicatietype	Asynchroon, wat betekent dat er mogelijk sprake is van enige gegevensvertraging tussen primaire en secundaire databases	Synchroon, zodat de secundaire database altijd gesynchroniseerd is met de primaire database.
Failover	Hiervoor is handmatige failover vereist. De toepassing verbindingsreeks moet worden bijgewerkt na een failover	Biedt ondersteuning voor automatische en handmatige failover, zonder dat u verbindingsreeks s hoeft te wijzigen na een failover
Leesbaarheid	Biedt leesbare secundaire databases.	Biedt leesbare secundaire databases en fungeert als hot-stand-by voor failover
Gebruikssituatie	Geschikt voor scenario's waarvoor meerdere leesbare replica's en handmatige failover nodig zijn	Ideaal voor scenario's die automatische failover en synchrone replicatie vereisen voor een groep databases