Delen via

Richtlijnen voor herstel na noodgevallen - Azure SQL Database

  • Artikel

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:

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • 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 .

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • 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ë:

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • 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.

Notitie

Voor een failover is volledige gegevenssynchronisatie vereist voordat u schakelt tussen rollen en leidt dit niet tot gegevensverlies. Afhankelijk van het type servicestoring is er geen garantie dat failover zonder gegevensverlies slaagt, maar het is de moeite waard om te proberen als eerste hersteloptie.

Gebruik de volgende koppelingen om een failover te starten:

Technologie Wijze Stappen
Actieve geo-replicatie PowerShell Failover naar secundaire geo-replicatie via PowerShell
T-SQL Failover naar secundaire geo-replicatie via T-SQL
Failover-groepen Azure-CLI Failover naar secundaire server via Azure CLI
Azure Portal Failover naar secundaire server via Azure Portal
PowerShell Failover naar secundaire server via PowerShell

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:

Technologie Wijze Stappen
Actieve geo-replicatie Azure-CLI Geforceerde failover naar secundaire geo-replicatie via Azure CLI
Azure Portal Geforceerde failover naar secundaire geo-replicatie via Azure Portal
PowerShell Geforceerde failover naar secundaire geo-replicatie via PowerShell
T-SQL Geforceerde failover naar secundaire geo-replicatie via T-SQL
failovergroepen Azure Portal Geforceerde failover naar secundaire server via Azure Portal , maar kies Geforceerde failover.
Azure-CLI Geforceerde failover naar secundaire server via Azure CLI , maar gebruik --allow-data-loss
PowerShell Geforceerde failover naar secundaire server via PowerShell , maar gebruik -AllowDataLoss

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.

Belangrijk

Het wordt aanbevolen om periodieke analyses uit te voeren van uw strategie voor herstel na noodgevallen om toepassingstolerantie te controleren, evenals alle operationele aspecten van de herstelprocedure. Voor de andere lagen van uw toepassingsinfrastructuur is mogelijk herconfiguratie vereist. Raadpleeg de controlelijst voor hoge beschikbaarheid en herstel na noodgevallen in Azure SQL Database voor meer informatie over flexibele architectuurstappen.

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