Uw Azure SQL Database of failover herstellen naar een secundaire

  • Artikel
  • 5 minuten om te lezen

VAN TOEPASSING OP: Azure SQL Database

Azure SQL Database biedt de volgende mogelijkheden voor het herstellen na een storing:

Zie Bedrijfscontinuïteit voor meer informatie over scenario's voor bedrijfscontinuïteit en de functies die deze scenario's ondersteunen.

Notitie

Als u zone-redundante Premium of Bedrijfskritiek databases of pools gebruikt, wordt het herstelproces geautomatiseerd en is de rest van dit materiaal niet van toepassing.

Zowel primaire als secundaire databases moeten dezelfde servicelaag hebben. Het wordt ook sterk aanbevolen dat de secundaire database wordt gemaakt met dezelfde rekenkracht (DTUs of vCores) als de primaire database. Zie Upgraden of downgraden als primaire database voor meer informatie.

Gebruik een of meer failovergroepen om failovers van meerdere databases te beheren. Als u een bestaande geo-replicatierelatie aan de failovergroep toevoegt, moet u ervoor zorgen dat de geo-secundaire is geconfigureerd met dezelfde servicelaag en rekenkracht als de primaire. Zie Use auto-failover groups to enable transparent and coordinated failover of multiple databases (Groepenvoor automatische failover gebruiken om transparante en gecoördineerde failover van meerdere databases mogelijk te maken) voor meer informatie.

Voorbereiden op het geval van een storing

Als u herstel naar een andere gegevensregio wilt laten slagen met behulp van failovergroepen of geografisch redundante back-ups, moet u een server in een ander datacentrum voorbereiden om de nieuwe primaire server te worden als dat nodig is. Daarnaast moet u goed gedefinieerde stappen gedocumenteerd en getest hebben om een soepel herstel mogelijk te maken. Deze voorbereidingsstappen omvatten:

  • Identificeer de server in een andere regio om de nieuwe primaire server te worden. Voor geo-herstel is dit doorgaans een server in de gekoppelde regio voor de regio waarin uw database zich bevindt. Dit elimineert de extra verkeerskosten tijdens de geo-herstelbewerkingen.
  • Identificeer en definieer eventueel de IP-firewallregels op serverniveau die gebruikers nodig hebben voor toegang tot de nieuwe primaire database.
  • Bepaal hoe u gebruikers wilt omleiden naar de nieuwe primaire server, bijvoorbeeld door verbindingsreeksen te wijzigen of door DNS-vermeldingen te wijzigen.
  • Identificeer en maak eventueel de aanmeldingen die aanwezig moeten zijn in de hoofddatabase op de nieuwe primaire server en zorg ervoor dat deze aanmeldingen de juiste machtigingen hebben in de hoofddatabase, indien van toepassing. Zie Beveiliging na noodherstel SQL Database meer informatie
  • Identificeer waarschuwingsregels die moeten worden bijgewerkt om toe te passen op de nieuwe primaire database.
  • Documenteren van de controleconfiguratie voor de huidige primaire database
  • Voer een noodhersteloefening uit. Als u een storing voor geo-herstel wilt simuleren, kunt u de brondatabase verwijderen of de naam ervan wijzigen, zodat de verbinding met de toepassing mislukt. Als u een storing wilt simuleren met behulp van failovergroepen, kunt u de webtoepassing of virtuele machine die is verbonden met de database uitschakelen of een failover van de database maken om verbindingsfouten voor de toepassing te veroorzaken.

Wanneer moet het herstel worden gestart?

De herstelbewerking is van invloed op de toepassing. Hiervoor moet de SQL connection string of omleiding met behulp van DNS worden veranderd. Dit kan leiden tot permanent gegevensverlies. Daarom moet dit alleen worden gedaan wanneer de storing waarschijnlijk langer duurt dan de hersteltijddoelstelling van uw toepassing. Wanneer de toepassing in productie is geïmplementeerd, moet u de status van de toepassing regelmatig controleren en de volgende gegevenspunten gebruiken om te controleren of het herstel gerechtvaardigd is:

  1. Permanente verbindingsfout van de toepassingslaag naar de database.
  2. De Azure Portal toont een waarschuwing over een incident in de regio met een brede impact.

Notitie

Als u failovergroepen gebruikt en automatische failover kiest, is het herstelproces geautomatiseerd en transparant voor de toepassing.

Afhankelijk van uw toepassingstolerantie voor downtime en mogelijke bedrijfsaansprakelijkheid kunt u de volgende herstelopties overwegen.

Gebruik get Recoverable Database (LastAvailableBackupDate) om het meest recente geo-gerepliceerde herstelpunt op te halen.

Wachten op serviceherstel

De Azure-teams werken hard om de beschikbaarheid van de service zo snel mogelijk te herstellen, maar afhankelijk van de hoofdoorzaak kan dit uren of dagen duren. Als uw toepassing aanzienlijke downtime kan tolereren, kunt u gewoon wachten tot het herstel is voltooid. In dit geval is er geen actie van uw kant vereist. U kunt de huidige servicestatus bekijken op ons Azure Service Health Dashboard. Na het herstel van de regio wordt de beschikbaarheid van uw toepassing hersteld.

Failover naar geo-gerepliceerde secundaire server in de failovergroep

Als de downtime van uw toepassing tot bedrijfsaansprakelijkheid kan leiden, moet u failovergroepen gebruiken. Hierdoor kan de toepassing snel de beschikbaarheid in een andere regio herstellen in geval van een storing. Zie Implement a geo-distributed database (Een geografisch gedistribueerde database implementeren) voor een zelfstudie.

Als u de beschikbaarheid van de database(s) wilt herstellen, moet u de failover naar de secundaire server initiëren met behulp van een van de ondersteunde methoden.

Gebruik een van de volgende handleidingen om een fail over te slaan naar een secundaire database met geo-replicatie:

Herstellen met geo-herstel

Als de downtime van uw toepassing niet leidt tot bedrijfsaansprakelijkheid, kunt u geo-herstel gebruiken als methode om uw toepassingsdatabase(s) te herstellen. Er wordt een kopie van de database gemaakt op de meest recente geografisch redundante back-up.

Uw database configureren na herstel

Als u geo-herstel gebruikt om te herstellen na een storing, moet u ervoor zorgen dat de verbinding met de nieuwe databases correct is geconfigureerd, zodat de normale toepassingsfunctie kan worden hervat. Dit is een controlelijst met taken om de herstelde database gereed te maken voor productie.

Verbindingsreeksen bijwerken

Omdat de herstelde database zich op een andere server bevindt, moet u de database van uw toepassing bijwerken connection string naar die server te laten wijzen.

Zie de juiste ontwikkelingstaal voor uw verbindingsbibliotheek voor meer informatie over het wijzigen van verbindingsreeksen.

Firewallregels configureren

U moet ervoor zorgen dat de firewallregels die op de server en in de database zijn geconfigureerd, overeenkomen met de regels die zijn geconfigureerd op de primaire server en primaire database. Zie How to: Configure Firewall Instellingen (Azure SQL Database) voor meer informatie.

Aanmeldingen en databasegebruikers configureren

U moet ervoor zorgen dat alle aanmeldingen die door uw toepassing worden gebruikt, bestaan op de server waarop uw herstelde database wordt gehost. Zie Beveiligingsconfiguratie voor geo-replicatie voor meer informatie.

Notitie

Tijdens een noodhersteloefening moet u de firewallregels en aanmeldingen van uw server (en hun machtigingen) configureren en testen. Deze objecten op serverniveau en hun configuratie zijn mogelijk niet beschikbaar tijdens de storing.

Telemetriewaarschuwingen instellen

U moet ervoor zorgen dat uw bestaande waarschuwingsregelinstellingen zijn bijgewerkt om deze toe te passen aan de herstelde database en de andere server.

Zie Waarschuwingsmeldingen ontvangen en Waarschuwingsmeldingen bijhouden voor meer informatie over waarschuwingsregels voor Service Health.

Controle inschakelen

Als controle is vereist voor toegang tot uw database, moet u Controle inschakelen na het herstel van de database. Zie Databasecontrole voor meer informatie.

Volgende stappen