Delen via

Controlelijst voor hoge beschikbaarheid en herstel na noodgevallen - 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 de gepubliceerde SLA-.

Deze handleiding biedt een gedetailleerd overzicht van proactieve stappen die u kunt nemen om de beschikbaarheid te maximaliseren, herstel te waarborgen en u voor te bereiden op Azure-storingen. 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 te verwerken.
  • Gebruik onderhoudsvensters om impactvolle onderhoudsbeurtenissen voorspelbaar en minder verstorend te maken.
  • Test fouttolerantie van toepassingen 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 deze beschikbaar is 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 een noodgeval herstelproces starten.

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 alleen-lezen-schrijven en alleen-lezen-listener in de verbindingsreeks van uw toepassing, zodat toepassingen automatisch verbinding maken met de server en database die de huidige primaire server is.
    • Stel het failoverbeleid in op , beheerd door de klant,.
  • Gebruik in plaats van failovergroepen ook actieve geo-replicatie om een leesbare secundaire database in een andere Azure-regio te hebben.
  • Zorg ervoor dat de geo-secundaire database wordt gemaakt met hetzelfde serviceniveau, rekenniveau (voorzien of serverloos) en rekencapaciteit (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, keert u de volgorde om: schaal eerst de primaire omlaag en schaal vervolgens de secundaire waarde 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 een transactie aan te roepen. 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.
  • Controleer vertraging met betrekking tot RPO (Recovery Point Objective) met behulp van de kolom replication_lag_sec van de sys.dm_geo_replication_link_status dynamische beheerweergave (DMV) op de primaire database. De DMV toont de vertraging in seconden tussen de transacties die zijn vastgelegd op de primaire en bevestigd in het transactielogboek op de secundaire. Stel dat de vertraging één seconde is op een bepaald moment. Als het primaire systeem door een storing wordt getroffen 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, overweeg dan de optie voor redundantie van back-upopslag in te stellen op geografisch redundante back-upopslag, zodat u geo-herstel voor Azure SQL Databasekunt gebruiken.
  • Plan en voer regelmatig noodherstelanalyses uit zodat u beter voorbereid bent in geval van een echte storing.

Bereid secundaire systemen voor op een storing

Om succesvol te herstellen 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 een server in een andere regio om de nieuwe primaire server te worden. Als uw primaire regio een gekoppelde regio heeft, is het gebruikelijk om de gekoppelde regio als secundaire regio te gebruiken. Hierdoor vermindert u doorgaans de latentie voor replicatie- en geo-herstelbewerkingen.
  • Bepaal hoe u gebruikers omleidt naar de nieuwe primaire server. U kunt gebruikers omleiden door handmatig toepassingsverbindingsreeksen of DNS-vermeldingen te wijzigen. Als u failovergroepen hebt geconfigureerd en de lees-schrijf- en alleen-lezen-listeners in verbindingsreeksen gebruikt, is er geen verdere actie nodig. Verbindingen worden na een failover automatisch omgeleid naar een nieuwe primaire server.
  • Identificeer en definieer desgewenst de firewallregels die gebruikers nodig hebben voor toegang tot de nieuwe primaire database.
  • Identificeer en maak desgewenst 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 beschikken in de master-database, indien van toepassing. Zie Azure SQL Database-beveiliging na herstel na noodgevalvoor meer informatie.
  • Identificeer waarschuwingsregels die moeten worden bijgewerkt om toe te wijzen aan de nieuwe primaire versie.
  • Documenteer de controleconfiguratie op de huidige primaire server en maak deze identiek op de secundaire server.

Verwante inhoud