Delen via

Controlelijst voor hoge beschikbaarheid en herstel na noodgevallen in Azure SQL Database

  • Artikel

Van toepassing op: Azure SQL Database

De Azure SQL Database-service zorgt ervoor dat alle databases online, in orde zijn en voortdurend streven naar het bereiken van de gepubliceerde SLA.

Deze handleiding biedt een gedetailleerde beoordeling van proactieve stappen die u kunt uitvoeren om de beschikbaarheid te maximaliseren, ervoor te zorgen dat azure-storingen worden hersteld en voorbereid. Deze richtlijnen zijn van toepassing op alle aankoopmodellen en servicelagen van Azure SQL Database.

Controlelijst voor beschikbaarheid

Hier volgen de aanbevolen configuraties om de beschikbaarheid te maximaliseren:

  • Neem logica voor opnieuw proberen op in de toepassing om tijdelijke fouten af te handelen.
  • Gebruik onderhoudsvensters om impactvolle onderhoudsevenementen voorspelbaar en minder verstorend te maken.
  • Test de fouttolerantie van de toepassing door handmatig een failover te activeren om tolerantie in actie te zien.

Controlelijst voor hoge beschikbaarheid

Hier volgt de aanbevolen configuratie om hoge beschikbaarheid te bereiken:

  • Schakel zoneredundantie in waar beschikbaar voor de database of elastische pool om tolerantie voor zonefouten te garanderen.

Controlelijst voor herstel na noodgevallen

Hoewel Azure SQL Database automatisch beschikbaarheid onderhoudt, zijn er exemplaren wanneer zelfs hoge beschikbaarheid (zoneredundantie) geen tolerantie garandeert omdat de gevolgen voor storingen een hele regio omvatten. Voor een regionale Azure SQL Database-storing moet u mogelijk herstel na noodgevallen initiëren.

Volg deze aanbevelingen om u het beste voor te bereiden op herstel na noodgevallen:

  • Schakel failovergroepen in voor een groep databases.
    • Gebruik de eindpunten voor lezen/schrijven en alleen-lezen-listener in uw toepassing verbindingsreeks zodat toepassingen automatisch verbinding maken met de server en database die primair is.
    • Stel het failoverbeleid in op door de klant beheerd.
  • U kunt ook actieve geo-replicatie inschakelen voor een leesbare secundaire database in een andere Azure-regio.
  • Zorg ervoor dat de geo-secundaire database wordt gemaakt met dezelfde servicelaag, rekenlaag (ingericht of serverloos) en rekengrootte (DTU's of vCores) als de primaire database.
  • Wanneer u omhoog schaalt, moet u eerst de geo-secundaire schaal omhoog schalen en vervolgens de primaire omhoog schalen.
  • Wanneer u omlaag schaalt, draait u de volgorde om: schaal eerst de primaire database omlaag en schaal vervolgens de secundaire database omlaag.
  • Herstel na noodgevallen is van nature ontworpen om gebruik te maken van asynchrone replicatie van gegevens tussen de primaire en secundaire regio. Als u de beschikbaarheid van gegevens wilt prioriteren ten opzichte van een hogere doorvoerlatentie, kunt u overwegen de sp_wait_for_database_copy_sync opgeslagen procedure onmiddellijk na het doorvoeren van de transactie aan te roepen. Het aanroepen sp_wait_for_database_copy_sync blokkeert de aanroepende thread totdat de laatste doorgevoerde transactie is verzonden en beperkt in het transactielogboek van de secundaire database.
  • Controleer vertraging met betrekking tot RPO (Recovery Point Objective) met behulp van de replication_lag_sec kolom van de sys.dm_geo_replication_link_status dynamische beheerweergave (DMV) op de primaire database. De DMV toont vertraging in seconden tussen de transacties die zijn doorgevoerd op de primaire en beperkt tot het transactielogboek op de secundaire. Stel dat de vertraging één seconde op een bepaald moment is, als de primaire waarde wordt beïnvloed door een storing en er op dat moment een geo-failover wordt gestart, gaan transacties die in de laatste seconde zijn vastgelegd verloren.
  • Als het inschakelen van failovergroepen of actieve geo-replicatie niet mogelijk is, kunt u overwegen de optie back-upopslagredundantie in te stellen op geografisch redundante back-upopslag om de mogelijkheid voor geo-herstel te gebruiken.
  • Plan regelmatig noodherstelanalyses en voer deze uit, zodat u beter voorbereid bent in geval van een echte storing.

Secundaire voorbereiden op een storing

Voor een geslaagd herstel naar een andere gegevensregio met behulp van actieve geo-replicatie, failovergroepen of geo-herstel moet u een secundaire logische Azure SQL Database-server in een andere regio voorbereiden. Deze secundaire server kan indien nodig de nieuwe primaire server worden. U moet ook goed gedefinieerde stappen hebben gedocumenteerd en getest om een soepel herstel te garanderen. Deze voorbereidingsstappen zijn onder andere:

  • Voor geo-herstel identificeert u de server in een andere regio om de nieuwe primaire server te worden. Dit is doorgaans een server in de gekoppelde regio voor de regio waarin uw primaire database zich bevindt. Het gebruik van een server in dezelfde regio elimineert de extra verkeerskosten tijdens geo-herstelbewerkingen.
  • Bepaal hoe u gebruikers omleidt naar de nieuwe primaire server. Het omleiden van gebruikers kan worden uitgevoerd door de toepassing verbindingsreeks s of DNS-vermeldingen handmatig te wijzigen. Als u failovergroepen hebt geconfigureerd en de listener lezen/schrijven en alleen-lezen-listener in toepassings-verbindingsreeks s gebruikt, is er geen verdere actie nodig: verbindingen worden automatisch omgeleid naar een nieuwe primaire na een failover.
  • Identificeer en definieer desgewenst de firewallregels die nodig zijn voor gebruikers om toegang te krijgen tot de nieuwe primaire database.
  • Identificeer en maak eventueel de aanmeldingen die aanwezig moeten zijn in de master database op de nieuwe primaire server en zorg ervoor dat deze aanmeldingen over de juiste machtigingen in de master database beschikken, indien van toepassing. Zie Azure SQL Database-beveiliging na herstel na noodgeval voor meer informatie.
  • Identificeer waarschuwingsregels die moeten worden bijgewerkt om toe te wijzen aan de nieuwe primaire versie.
  • Documenteer de controleconfiguratie op de huidige primaire.

Gerelateerde inhoud