Richtlijnen voor herstel na noodgevallen - Azure SQL Database

Van toepassing op: Azure SQL Database

Azure SQL Database biedt een toonaangevende garantie voor hoge beschikbaarheid van ten minste 99,99% ter ondersteuning van een groot aantal toepassingen, waaronder bedrijfskritiek, die altijd beschikbaar moeten zijn. Azure SQL Database heeft ook belangrijke bedrijfscontinuïteitsmogelijkheden die u snel herstel na noodgevallen uitvoert in het geval van een regionale storing. Dit artikel bevat waardevolle informatie die u kunt bekijken voorafgaand aan de implementatie van de toepassing.

Hoewel we voortdurend streven naar hoge beschikbaarheid, zijn er momenten waarop de Azure SQL Database-service storingen veroorzaakt die de onbeschikbaarheid van uw database veroorzaken en dus van invloed zijn op uw toepassing. Wanneer onze servicebewaking problemen detecteert die wijdverspreide connectiviteitsfouten, fouten of prestatieproblemen veroorzaken, declareert de service automatisch een storing om u op de hoogte te houden.

Service-onderbreking

In het geval van een storing in de Azure SQL Database-service vindt u aanvullende informatie met betrekking tot de storing op de volgende plaatsen:

• Azure Portal-banner

  Als uw abonnement wordt geïdentificeerd als beïnvloed, is er een storingswaarschuwing van een serviceprobleem in uw Azure Portal-meldingen:

  

• Help + ondersteuning of ondersteuning en probleemoplossing

  Wanneer u een ondersteuningsticket maakt vanuit Help + ondersteuning of ondersteuning en probleemoplossing, vindt u informatie over eventuele problemen die van invloed zijn op uw resources. Selecteer Onderbrekingsdetails weergeven voor meer informatie en een samenvatting van de impact. Er is ook een waarschuwing op de pagina Nieuwe ondersteuningsaanvraag .

  

• Servicestatus

  De servicestatuspagina in Azure Portal bevat informatie over de status van het Azure-datacenter wereldwijd. Zoek in de zoekbalk in Azure Portal naar servicestatus en bekijk vervolgens serviceproblemen in de categorie Actieve gebeurtenissen . U kunt ook de status van afzonderlijke resources bekijken op de pagina Resourcestatus van elke resource in het menu Help . Hieronder ziet u een voorbeeldschermopname van de pagina ServiceStatus , met informatie over een actief serviceprobleem in Zuidoost-Azië:

  

• E-mailmelding

  Als u waarschuwingen hebt ingesteld, wordt er een e-mailmelding verzonden vanaf azure-noreply@microsoft.com wanneer een servicestoring van invloed is op uw abonnement en resource. De hoofdtekst van het e-mailbericht begint meestal met 'De waarschuwing voor het activiteitenlogboek... is geactiveerd door een serviceprobleem voor het Azure-abonnement...". Zie Waarschuwingen voor activiteitenlogboeken ontvangen in Azure-servicemeldingen met behulp van de Azure-portal voor meer informatie over servicestatuswaarschuwingen.

Wanneer moet u herstel na noodgevallen initiëren tijdens een storing

In het geval van een servicestoring die van invloed is op toepassingsbronnen, moet u rekening houden met de volgende acties:

• De Azure-teams werken ijverig om de beschikbaarheid van de service zo snel mogelijk te herstellen, maar afhankelijk van de hoofdoorzaak kan het soms uren duren. Als uw toepassing aanzienlijke downtime tolereert, kunt u gewoon wachten totdat het herstel is voltooid. In dit geval is er geen actie voor uw onderdeel vereist. Bekijk de status van afzonderlijke resources op de pagina Resourcestatus van een resource in het menu Help . Raadpleeg de pagina Resourcestatus voor updates en de meest recente informatie over een storing. Nadat de regio is hersteld, wordt de beschikbaarheid van uw toepassing hersteld.

• Herstel naar een andere Azure-regio vereist mogelijk het wijzigen van de toepassing verbindingsreeks s of het gebruik van DNS-omleiding. Dit kan leiden tot permanent gegevensverlies. Herstel na noodgevallen mag daarom alleen worden uitgevoerd wanneer de duur van de storing de beoogde hersteltijd (RTO) van uw toepassing nadert. Wanneer de toepassing wordt geïmplementeerd in productie, moet u regelmatig de status van de toepassing controleren en bevestigen dat het herstel alleen gerechtvaardigd is wanneer er langdurige connectiviteitsfouten zijn van de toepassingslaag naar de database. Afhankelijk van uw toepassingstolerantie voor downtime en mogelijke bedrijfsaansprakelijkheid, kunt u zelf beslissen of u wilt wachten totdat de service herstel na noodgevallen herstelt of initieert.

Richtlijnen voor herstel na een storing

Als de Azure SQL Database-storing in een regio gedurende langere tijd niet is verzacht en van invloed is op de sla (Service Level Agreement) van uw toepassing, moet u de volgende stappen overwegen:

Failover (geen gegevensverlies) naar geo-gerepliceerde secundaire server

Als actieve geo-replicatie of failovergroepen zijn ingeschakeld, controleert u of de resourcestatus van de primaire en secundaire database online is in Azure Portal. Zo ja, dan is het gegevensvlak voor zowel de primaire als de secundaire database in orde. Start een failover van actieve geo-replicatie of failovergroepen naar de secundaire regio met behulp van Azure Portal, T-SQL, PowerShell of Azure CLI.

Gebruik de volgende koppelingen om een failover te starten:

Geforceerde failover (mogelijk gegevensverlies) naar secundaire geo-gerepliceerde server

Als failover niet correct wordt voltooid en fouten optreedt, of als de status van de primaire database nietonline is, moet u zorgvuldig geforceerde failover overwegen met mogelijk gegevensverlies naar de secundaire regio.

Gebruik de volgende koppelingen om een geforceerde failover te starten:

Geo-herstel

Als u actieve geo-replicatie of failovergroepen niet hebt ingeschakeld, kunt u als laatste redmiddel geo-herstel gebruiken om te herstellen na een storing. Geo-herstel maakt gebruik van geo-gerepliceerde back-ups als bron. U kunt een database herstellen op elke logische server in elke Azure-regio vanuit de meest recente geo-gerepliceerde back-ups. U kunt een geo-herstel aanvragen, zelfs als een storing de database of de hele regio niet toegankelijk heeft gemaakt.

Zie geo-herstel van Azure SQL Database voor meer informatie over geo-herstel via Azure CLI, Azure Portal, PowerShell of de REST API.

Uw database configureren na herstel

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

Verbindingsreeks s bijwerken

• Als u actieve geo-replicatie of geo-herstel gebruikt, moet u ervoor zorgen dat de verbinding met de nieuwe databases correct is geconfigureerd, zodat de normale toepassingsfunctie kan worden hervat. Omdat de herstelde database zich op een andere server bevindt, moet u de verbindingsreeks van uw toepassing bijwerken om naar die server te verwijzen. Zie de juiste ontwikkeltaal voor uw verbindingsbibliotheek voor meer informatie over het wijzigen van verbindingsreeks s.
• Als u failovergroepen gebruikt om te herstellen na een storing en lees-/schrijf- en alleen-lezen-listeners in uw toepassing verbindingsreeks s gebruikt, is er geen verdere actie nodig omdat verbindingen automatisch worden omgeleid naar een nieuwe primaire.

Firewallregels configureren

U moet ervoor zorgen dat de firewallregels die zijn geconfigureerd op de server en in de database overeenkomen met de regels die zijn geconfigureerd op de primaire server en de primaire database. Zie Voor meer informatie: Firewall-Instellingen (Azure SQL Database) configureren.

Aanmeldingen en databasegebruikers configureren

Maak 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 noodgeval voor meer informatie.

Telemetriewaarschuwingen instellen

U moet ervoor zorgen dat uw bestaande instellingen voor waarschuwingsregels worden bijgewerkt om toe te wijzen aan de nieuwe primaire database en de andere server. Zie Waarschuwingsmeldingen ontvangen en Servicestatus bijhouden voor meer informatie over databasewaarschuwingsregels.

Controleren inschakelen

Als controle is vereist voor toegang tot uw database, moet u Controle inschakelen na het herstellen van de database. Zie Azure SQL Auditing voor Azure SQL Database voor meer informatie.

Volgende stappen

• De SLA voor Azure SQL Database controleren
• Zie geautomatiseerde back-ups van SQL Database voor meer informatie over geautomatiseerde back-ups van Azure SQL Database
• Zie Continuïteitsscenario's voor meer informatie over ontwerp- en herstelscenario's voor bedrijfscontinuïteit
• Zie een database herstellen vanuit de door de service geïnitieerde back-ups voor meer informatie over het gebruik van geautomatiseerde back-ups voor herstel
• Meer informatie over actieve geo-replicatie
• Meer informatie over failovergroepen
• Meer informatie over geo-herstel
• Meer informatie over zoneredundante databases