Delen via

Betrouwbaarheid in Azure SQL Database

Azure SQL Database is een volledig beheerde PaaS-database-engine (Platform as a Service) die de meeste databasebeheerfuncties verwerkt, zoals upgraden, patchen, back-ups en bewaking zonder tussenkomst van de gebruiker.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure SQL Database tolerant maakt voor een verscheidenheid aan mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regiostoringen. Ook wordt beschreven hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen, hoe u serviceonderhoud kunt afhandelen en belangrijke informatie over de Service Level Agreement (SLA) van Azure SQL Database kunt bekijken.

Aanbevelingen voor productie-implementatie

Voor meer informatie over het uitrollen van Azure SQL Database ter ondersteuning van de betrouwbaarheidsvereisten van uw oplossing en hoe betrouwbaarheid effect heeft op andere aspecten van uw architectuur, zie de architecturale best practices voor Azure SQL Database in het Azure Well-Architected Framework.

Overzicht van betrouwbaarheidsarchitectuur

SQL Database wordt uitgevoerd op de nieuwste stabiele SQL Server Database-engine van het Windows-besturingssysteem, inclusief alle toepasselijke patches.

SQL Database zorgt voor redundantie door standaard drie kopieën van uw gegevens op te slaan in één datacenter in de primaire regio. Deze benadering beschermt uw gegevens als er een gelokaliseerde fout optreedt, zoals een kleinschalige netwerkstoring of stroomstoring, en ook tijdens de volgende gebeurtenissen:

  • Door de klant geïnitieerde beheerbewerkingen die resulteren in een korte downtime

  • Serviceonderhoudsbewerkingen

  • Problemen en storingen in datacenters, waarbij het datacenter de volgende onderdelen heeft:

    • Racks waar de machines die uw service aandrijven draaien

    • Fysieke machines die als host fungeren voor de virtuele machine (VM) waarop de SQL Database-engine wordt uitgevoerd

  • Andere problemen met de SQL Database-engine

  • Andere potentiële niet-geplande gelokaliseerde storingen

SQL Database maakt gebruik van Azure Service Fabric om de replicatie van uw database te beheren.

Redundantie wordt op verschillende manieren geïmplementeerd voor verschillende servicelagen van SQL Database. Zie Beschikbaarheid via redundantie - SQL Database voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

SQL Database verwerkt automatisch kritieke onderhoudstaken, zoals patches, back-ups, Windows en SQL Database-engineupgrades. Ook worden niet-geplande gebeurtenissen, zoals onderliggende hardware, software of netwerkfouten, automatisch verwerkt. SQL Database is ontworpen om snel te herstellen van kritieke fouten, waardoor uw gegevens altijd beschikbaar zijn. De meeste gebruikers merken niet dat upgrades continu worden uitgevoerd.

Wanneer een database wordt gepatcht of een failover-overschakeling uitvoert, is de downtime niet storend als u logica voor opnieuw proberen in uw toepassing gebruikt.

U kunt de tolerantie van uw toepassing testen op tijdelijke fouten door de richtlijnen in fouttolerantie van testtoepassingen te volgen.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

U kunt een zoneredundante individuele database of elastische pool maken. Zoneredundantie zorgt ervoor dat uw database bestand is tegen een grote set fouten, inclusief onherstelbare storingen in datacenters, zonder dat er wijzigingen in de toepassingslogica zijn.

Voor de servicelaag Algemeen gebruik zorgt zoneredundantie ervoor dat zowel de stateless rekenonderdelen als de stateful gegevensopslagonderdelen van SQL Database bestand zijn tegen een storing in de beschikbaarheidszone.

Voor de Premium-, Bedrijfskritieke en Hyperscale-servicelagen plaatst zoneredundantie replica's van uw SQL-database in meerdere Azure-beschikbaarheidszones in uw primaire regio. Als u een SINGLE Point of Failure (SPOF) wilt elimineren, wordt de besturingsring ook gedupliceerd in meerdere beschikbaarheidszones.

Als u informatie over ondersteuning voor beschikbaarheidszones voor andere servicelagen wilt weergeven, moet u de juiste servicelaag aan het begin van deze pagina selecteren.

Requirements

De Basic- en Standard-servicelagen bieden geen ondersteuning voor zoneredundantie.

Zoneredundantie is beschikbaar voor databases in de servicelagen Bedrijfskritiek, Algemeen gebruik en Hyperscale van het aankoopmodel op basis van vCore en alleen de Premium-servicelaag van het aankoopmodel op basis van DTU.

Voor de servicelaag Algemeen gebruik:

Voor de servicelagen Premium en Bedrijfskritiek:

Voor de Hyperscale-servicelaag:

Als u informatie over ondersteuning voor beschikbaarheidszones voor andere servicelagen wilt weergeven, moet u de juiste servicelaag aan het begin van deze pagina selecteren.

Overwegingen

  • Wachttijd: Zone-redundante databases hebben replica's in afzonderlijke datacenters. De toegevoegde netwerklatentie kan de doorvoertijd van transacties verhogen en de prestaties van bepaalde OLTP-workloads (Online Transaction Processing) beïnvloeden. De meeste toepassingen zijn niet gevoelig voor deze extra latentie.

  • master database: Wanneer een database met een zone-redundante configuratie wordt gemaakt op een logische server, wordt de master database die aan de server is gekoppeld, ook automatisch zone-redundant gemaakt. Voor meer informatie over het controleren of uw master-database zone-redundant is, zie Database zone-redundante beschikbaarheid.

Als u informatie over ondersteuning voor beschikbaarheidszones voor andere servicelagen wilt weergeven, moet u de juiste servicelaag aan het begin van deze pagina selecteren.

Kosten

Voor de servicelaag Algemeen gebruik worden extra kosten in rekening gebracht om zoneredundantie in te schakelen voor SQL Database. Zie Prijzen - SQL Database voor meer informatie.

De servicelagen Premium en Bedrijfskritiek bieden meerdere replica's van uw database. Wanneer u zoneredundantie inschakelt, worden de replica's verdeeld over beschikbaarheidszones. Deze distributie betekent dat er geen extra kosten zijn gekoppeld aan het inschakelen van zoneredundantie op uw SQL-database wanneer deze zich in de servicelaag Premium of Bedrijfskritiek bevindt.

Als u meerdere replica's van uw Hyperscale-servicelaagdatabase inschakelt, kunt u zoneredundantie inschakelen. Wanneer u zoneredundantie inschakelt, worden de replica's verdeeld over beschikbaarheidszones. Deze distributie betekent dat er geen extra kosten verbonden zijn aan het inschakelen van zoneredundantie op uw SQL-database wanneer deze zich in de Hyperscale-servicelaag bevindt, ervan uitgaande dat u meerdere replica's hebt.

Als u informatie over ondersteuning voor beschikbaarheidszones voor andere servicelagen wilt weergeven, moet u de juiste servicelaag aan het begin van deze pagina selecteren.

Ondersteuning voor beschikbaarheidszones configureren

Voor de servicelagen Algemeen gebruik, Premium en Bedrijfskritiek:

  • Nieuwe resources: U kunt een database zo configureren dat deze zoneredundant is wanneer u deze maakt. Zie quickstart: Een individuele database maken - SQL Database voor meer informatie.

  • Bestaande resources: U kunt een bestaande database opnieuw configureren om zone-redundant te zijn. Zie Zoneredundantie inschakelen - SQL Database voor meer informatie.

    Alle schaalbewerkingen van SQL Database, waaronder het inschakelen van zoneredundantie, zijn onlinebewerkingen en vereisen minimale tot geen downtime. Voor meer informatie, zie Databaseresources dynamisch schalen met minimale downtime.

  • Zoneredundantie uitschakelen: U kunt zoneredundantie uitschakelen. Dit proces is een onlinebewerking die vergelijkbaar is met een reguliere upgrade van de servicelaagdoelstelling. Aan het einde van het proces wordt de database gemigreerd van een zoneredundante ring naar een ring met één zone.

Voor de Hyperscale-servicelaag:

  • Nieuwe resources: Voor Hyperscale-databases en elastische pools moet zoneredundantie worden geconfigureerd wanneer de database wordt gemaakt. Zie Een zoneredundante Hyperscale-database maken voor meer informatie.

  • Migratie of zoneredundantie uitschakelen: Als u zoneredundantie wilt in- of uitschakelen voor een bestaande Hyperscale-database of elastische pool, moet u deze opnieuw implementeren. Het proces voegt een secundaire replica toe voor hoge beschikbaarheid en plaatst deze in een andere beschikbaarheidszone.

    Zie Een zoneredundante Hyperscale-database opnieuw implementeren - SQL Database voor meer informatie

Als u informatie over ondersteuning voor beschikbaarheidszones voor andere servicelagen wilt weergeven, moet u de juiste servicelaag aan het begin van deze pagina selecteren.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer databases zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

Voor de servicelaag Algemeen gebruik:

  • Verkeersroutering tussen zones: Aanvragen worden doorgestuurd naar een knooppunt waarop uw SQL Database-rekenlaag wordt uitgevoerd. Wanneer zoneredundantie is ingeschakeld, bevindt dit knooppunt zich mogelijk in een beschikbaarheidszone.

  • Gegevensreplicatie tussen zones: Gegevens- en logboekbestanden worden synchroon gerepliceerd in beschikbaarheidszones met behulp van ZRS. Schrijfbewerkingen worden pas als voltooid beschouwd als de gegevens zijn gerepliceerd in alle beschikbaarheidszones. Deze synchrone replicatie zorgt voor sterke consistentie en nul gegevensverlies tijdens zonefouten. Het kan echter leiden tot iets hogere schrijflatentie in vergelijking met lokaal redundante opslag (LRS).

Voor de servicelagen Premium en Bedrijfskritiek:

  • Verkeersroutering tussen zones: Replica's worden verdeeld over beschikbaarheidszones en een van deze replica's wordt aangewezen als de primaire replica. Aanvragen worden doorgestuurd naar de primaire replica van uw database.

  • Gegevensreplicatie tussen zones: De primaire replica pusht voortdurend wijzigingen in de secundaire replica's sequentieel om ervoor te zorgen dat gegevens op een voldoende aantal secundaire replica's worden bewaard voordat elke transactie wordt doorgevoerd. Dit proces garandeert dat als de primaire replica of een leesbare secundaire replica om welke reden dan ook niet beschikbaar is, een volledig gesynchroniseerde replica altijd beschikbaar is voor failover. Wanneer zoneredundantie is ingeschakeld, bevinden deze replica's zich in verschillende beschikbaarheidszones. Het proces kan echter leiden tot iets hogere schrijflatentie vanwege de netwerklatentie in doorkruisingszones.

Voor de Hyperscale-servicelaag:

  • Verkeersroutering tussen zones: Databasereplica's worden verdeeld over beschikbaarheidszones en een van deze replica's wordt aangewezen als de primaire replica. Aanvragen worden doorgestuurd naar de primaire replica van uw database.

  • Gegevensreplicatie tussen zones: De primaire databasereplica pusht wijzigingen via een zone-redundante logboekservice, waarmee alle wijzigingen synchroon worden gerepliceerd in beschikbaarheidszones. Paginaservers bevinden zich in elke beschikbaarheidszone en slaan de status van de database op. Dit proces garandeert dat als de primaire replica of een leesbare secundaire replica om welke reden dan ook niet meer beschikbaar is, een volledig gesynchroniseerde replica altijd beschikbaar is voor failover. Het proces kan echter leiden tot iets hogere schrijflatentie in vergelijking met LRS.

Als u informatie over ondersteuning voor beschikbaarheidszones voor andere servicelagen wilt weergeven, moet u de juiste servicelaag aan het begin van deze pagina selecteren.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer databases zijn geconfigureerd voor zoneredundantie en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: SQL Database is verantwoordelijk voor het detecteren en reageren op een fout in een beschikbaarheidszone. U hoeft niets te doen om een zonefailover te starten.
  • Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.
  • Actieve aanvragen: Wanneer een beschikbaarheidszone offline gaat, worden alle aanvragen die worden verwerkt in de defecte beschikbaarheidszone beëindigd en moeten ze opnieuw worden geprobeerd. Zie de richtlijnen voor tolerantie voor tijdelijke fouten voor meer informatie over hoe u uw toepassingen tolerant maakt voor dit soort problemen.

  • Verkeer omleiden: Voor de servicelaag Algemeen gebruik verplaatst SQL Database de database-engine naar een ander staatloos rekenknooppunt dat zich in een andere beschikbaarheidszone bevindt en voldoende vrije capaciteit heeft. Nadat de failover is voltooid, worden nieuwe verbindingen automatisch omgeleid naar het nieuwe primaire rekenknooppunt.

    Zie de servicelaag Algemeen gebruik voor meer informatie.

  • Verkeer omleiden: Voor de servicelagen Premium en Bedrijfskritiek selecteert SQL Database een replica in een andere beschikbaarheidszone om de primaire replica te worden. Nadat een secundaire replica de nieuwe primaire replica wordt, wordt er een andere secundaire replica gemaakt om ervoor te zorgen dat het cluster voldoende replica's heeft om een quorum te behouden. Nadat de failover is voltooid, worden nieuwe verbindingen automatisch omgeleid naar de nieuwe primaire replica (of leesbare secundaire replica op basis van de verbindingsreeks).

    Zie Premium- en Bedrijfskritieke servicelagen voor meer informatie.

  • Verkeer omleiden: Als voor de Hyperscale-servicelaag de primaire replica verloren is gegaan vanwege een storing in de zone, bevordert SQL Database een van de replica's met hoge beschikbaarheid in een andere zone als de nieuwe primaire replica.

    Zie Hyperscale-servicelaagvoor meer informatie.

  • Verwachte downtime: Er kan een kleine hoeveelheid downtime optreden tijdens een failover van een beschikbaarheidszone. De downtime is doorgaans minder dan 30 seconden, wat uw toepassing moet tolereren als deze de richtlijnen voor tijdelijke fouten volgt.

  • Verwachte gegevensverlies: Er wordt geen gegevensverlies verwacht tijdens een failover van een beschikbaarheidszone.

Als u informatie over ondersteuning voor beschikbaarheidszones voor andere servicelagen wilt weergeven, moet u de juiste servicelaag aan het begin van deze pagina selecteren.

Zoneherstel

Wanneer de beschikbaarheidszone wordt hersteld, maakt Azure Service Fabric automatisch databasereplica's in de herstelde beschikbaarheidszone, verwijdert u tijdelijke replica's die zijn gemaakt in de andere beschikbaarheidszones en hervat u de normale verkeersroutering naar uw database. Om onderbrekingen te voorkomen, retourneert de primaire replica niet automatisch de oorspronkelijke zone na het zoneherstel.

Testen op zonefouten

Het SQL Database-platform beheert verkeersroutering, failover en zoneherstelprocedures voor zone-redundante databases. Omdat deze functie volledig wordt beheerd, hoeft u geen processen voor fouten in de beschikbaarheidszone te initiëren of valideren. U kunt echter de verwerking van fouten en failovers van uw toepassing valideren door het proces te volgen dat wordt beschreven in Fouttolerantie van testtoepassing.

Tolerantie voor storingen in de hele regio

Deze sectie bevat een overzicht van twee gerelateerde maar afzonderlijke functies die kunnen worden gebruikt voor geo-replicatie in meerdere regio's van SQL Database:

Actieve geo-replicatie

Actieve geo-replicatie maakt een continu gesynchroniseerde leesbare secundaire database (ook wel geo-secundaire of geo-replica genoemd) in elke regio voor één primaire database. Actieve geo-replicatie kan secundaire databases maken in dezelfde regio, maar deze configuratie biedt geen bescherming tegen een regiostoring. Wanneer u actieve geo-replicatie gebruikt om geo-redundantie te bereiken, zoekt u de secundaire database in een andere regio naar de primaire database.

Requirements

Houd rekening met de volgende vereisten wanneer u actieve geo-replicatie gebruikt:

  • Regioondersteuning:Actieve geo-replicatie kan worden ingeschakeld in alle Azure-regio's en u hoeft geen Azure-regioparen te gebruiken.

    Aanbeveling

    SQL Database volgt een veilige implementatiepraktijk waarbij Azure ernaar streeft geen updates te implementeren in gekoppelde regio's tegelijk. Als u actieve geo-replicatie configureert bij gebruik van niet-gepaarde regio’s, stelt u verschillende onderhoudsvensters in voor de servers in elke regio. Deze aanpak helpt de kans te verminderen dat beide regio's connectiviteitsproblemen ondervinden die worden veroorzaakt door onderhoud op hetzelfde moment.

  • Configuratie: Zowel de primaire als de geo-secundaire moet dezelfde servicelaag hebben en dezelfde rekenlaag, rekenkracht en redundantie van back-upopslag moeten hebben.

  • Firewall: Zowel de primaire als de geo-secundaire moeten dezelfde IP-adres firewallregels hebben.

  • Azure-abonnementen: Actieve geo-replicatie wordt ondersteund voor databases in verschillende Azure-abonnementen.

Overwegingen

  • Actieve geo-replicatie is ontworpen om failover van één database te bieden. Als u een failover van meerdere databases wilt uitvoeren, kunt u in plaats daarvan failovergroepen gebruiken.

  • Omdat geo-replicatie asynchroon is, is gegevensverlies mogelijk wanneer een failover plaatsvindt. Als u gegevensverlies van asynchrone replicatie tijdens failovers wilt elimineren, configureert u uw toepassing om de aanroepende thread te blokkeren totdat de laatste doorgevoerde transactie wordt verzonden en beveiligd in het transactielogboek van de secundaire database. Deze aanpak vereist aangepaste ontwikkeling en vermindert de prestaties van uw toepassing. Zie Verlies van kritieke gegevens voorkomen voor meer informatie.

  • Zie Actieve geo-replicatie voor meer informatie over beperkingen en overwegingen.

Kosten

Secundaire databases worden gefactureerd als afzonderlijke databases.

Als u geen secundaire database gebruikt voor lees- en schrijfworkloads, kunt u overwegen of u deze kunt aanwijzen als een standby-replica om uw kosten te verlagen.

Ondersteuning voor meerdere regio's configureren

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een database is geconfigureerd voor het gebruik van actieve geo-replicatie en alle regio's operationeel zijn.

  • Verkeersroutering tussen regio's: Uw toepassing moet zijn geconfigureerd voor het verzenden van lees-/schrijfaanvragen naar de primaire database. U kunt desgewenst alleen-lezenaanvragen verzenden naar een secundaire database, waardoor de impact van alleen-lezenworkloads op uw primaire database wordt verminderd.

  • Gegevensreplicatie tussen regio's: Replicatie tussen de primaire en secundaire databases vindt asynchroon plaats, wat betekent dat er een vertraging kan optreden tussen het moment waarop een wijziging wordt toegepast op de primaire database en wanneer deze wordt gerepliceerd naar de secundaire database.

    Wanneer u een failover uitvoert, besluit u hoe u de mogelijkheid van gegevensverlies kunt afhandelen.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een database is geconfigureerd voor het gebruik van actieve geo-replicatie en er een storing is in uw primaire regio:

  • Detectie en reactie: U bent verantwoordelijk voor het detecteren van de storing van een database of regio en voor het activeren van failover.
  • Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Actieve aanvragen tijdens de failover worden beëindigd en moeten opnieuw worden geprobeerd.

  • Verwachte gegevensverlies: Als uw primaire database beschikbaar is, kunt u eventueel een failover uitvoeren zonder gegevensverlies. Het failoverproces synchroniseert gegevens tussen de primaire en secundaire databases voordat u van rol wisselt.

    Als uw primaire database niet beschikbaar is, moet u mogelijk een geforceerde failover uitvoeren, wat resulteert in gegevensverlies. U kunt de hoeveelheid gegevensverlies schatten door de replicatievertraging te bewaken. Zie SQL Database bewaken met metrische gegevens en waarschuwingen voor meer informatie.

  • Verwachte downtime: Er is meestal maximaal 60 seconden downtime tijdens een failover. Zorg ervoor dat uw toepassing tijdelijke fouten afhandelt , zodat deze kan worden hersteld na korte perioden van downtime. Ook hoe snel u uw toepassing opnieuw configureert om verbinding te maken met de nieuwe primaire database, is van invloed op de downtime die u ondervindt.

  • Verkeer omleiden: U bent verantwoordelijk voor het opnieuw configureren van uw toepassing voor het verzenden van aanvragen naar de nieuwe primaire database. Als u transparante failover moet hebben, kunt u overwegen failovergroepen te gebruiken.

Herstel van de regio

Nadat de primaire regio is hersteld, kunt u handmatig een failback uitvoeren naar de primaire regio door een andere failover uit te voeren.

Test voor regiofouten

U kunt een regiostoring simuleren door op elk gewenst moment een handmatige failover te activeren. U kunt een failover activeren (geen gegevensverlies) of een geforceerde failover.

Failovergroepen

Failovergroepen bouwen voort op actieve geo-replicatie. Met failovergroepen kunt u de volgende bewerkingen uitvoeren:

  • Repliceer een set databases van één logische server in elke combinatie van Azure-regio's.

  • Voer een failover uit op de databases als groep.

  • Gebruik verbindingseindpunten die automatisch verbindingen naar de primaire verbinding richten.

Requirements

  • Regioondersteuning: Failovergroepen kunnen worden gemaakt in alle Azure-regio's en u hoeft geen Azure-regioparen te gebruiken.

    Aanbeveling

    Als u een failovergroep met niet-gekoppelde regio's configureert, overweeg dan verschillende onderhoudsvensters voor de servers in elke regio in te stellen. Deze aanpak helpt de kans te verminderen dat beide regio's connectiviteitsproblemen ondervinden die worden veroorzaakt door onderhoud op hetzelfde moment.

  • Configuratie: Secundaire databases in een failovergroep moeten dezelfde servicelaag, rekenlaag, rekenkracht, firewallregels voor IP-adressen en redundantie van back-upopslag hebben als de primaire database.

Overwegingen

  • Zoneredundantie: Als voor de Hyperscale-servicelaag zoneredundantie is ingeschakeld voor uw primaire database, worden zoneredundantie automatisch ingeschakeld voor secundaire databases.
  • Zoneredundantie: Secundaire databases hebben standaard geen zoneredundantie ingeschakeld, maar u kunt deze later inschakelen.

  • Mogelijk gegevensverlies: Omdat geo-replicatie asynchroon is, is het mogelijk om gegevensverlies te hebben wanneer een failover plaatsvindt. Als u gegevensverlies van asynchrone replicatie tijdens failovers wilt elimineren, kunt u uw toepassing zo configureren dat de aanroepende thread wordt geblokkeerd totdat de laatste doorgevoerde transactie wordt verzonden en beperkt in het transactielogboek van de secundaire database. Deze aanpak vereist aangepaste ontwikkeling en vermindert de prestaties van uw toepassing. Zie Verlies van kritieke gegevens voorkomen voor meer informatie.

  • Zie Failover-groepen voor meer informatie over beperkingen en overwegingen.

Kosten

Secundaire databases worden gefactureerd als afzonderlijke databases.

Als u geen secundaire database gebruikt voor lees- en schrijfworkloads, kunt u overwegen of u deze kunt aanwijzen als een standby-replica om uw kosten te verlagen.

Ondersteuning voor meerdere regio's configureren

  • Failovergroepen inschakelen: U configureert een failovergroep op een logische server. U kunt alle databases op de logische server toevoegen aan de failovergroep of u kunt een subset van databases selecteren die u wilt toevoegen.

    Wanneer u een failovergroep maakt, selecteert u het failoverbeleid, waarmee wordt aangegeven wie verantwoordelijk is voor het detecteren van een storing en het uitvoeren van een failover. U kunt door de klant beheerde failover configureren. Dit wordt aanbevolen of door Microsoft beheerde failover.

    Belangrijk

    Een door Microsoft geïnitieerde failover vindt waarschijnlijk plaats na een aanzienlijke vertraging en wordt uitgevoerd op basis van best effort. Failover van databases kan zich op een ander moment voordoen bij een failover van andere Azure-services. Zie Een failovergroep configureren voor SQL Database voor meer informatie.

    Nadat u de failovergroep hebt geconfigureerd, kan de eerste seedingstap enige tijd duren.

  • Failovergroepen uitschakelen: U kunt een afzonderlijke database verwijderen uit een failovergroep, een hele failovergroep verwijderen of een database verplaatsen naar een andere failovergroep.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een database is geconfigureerd binnen een failovergroep en alle regio's operationeel zijn.

  • Verkeersroutering tussen regio's: Voor workloads met lees- en schrijfbewerkingen en alleen-lezen bieden failovergroepen twee listener-eindpunten waarmee u uw toepassingen kunt verbinden. Gebruik de listener-eindpunten van de failovergroep om downtime tijdens failovers te minimaliseren. Tijdens normale bewerkingen treedt het volgende routeringsgedrag op:

    • Het eindpunt van de listener voor lezen/schrijven stuurt alle aanvragen naar de primaire databases.

    • Het eindpunt van de alleen-lezen listener stuurt alle aanvragen naar een leesbare secundaire database.

  • Gegevensreplicatie tussen regio's: Geo-replicatie tussen de primaire en secundaire databases vindt asynchroon plaats. Deze latentie betekent dat er een vertraging kan optreden tussen een wijziging die wordt toegepast op de primaire database en wanneer deze wordt gerepliceerd naar de secundaire database.

    Wanneer u een failover uitvoert, besluit u hoe u de mogelijkheid van gegevensverlies kunt afhandelen.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een database is geconfigureerd binnen een failovergroep en er een storing optreedt in uw primaire regio:

  • Detectie en reactie is afhankelijk van het failoverbeleid dat u gebruikt.

    • Door de klant geïnitieerde failover: U bent verantwoordelijk voor het detecteren van de storing in een database of regio en voor het activeren van failover.

    • Door Microsoft geïnitieerde failover: Microsoft activeert failover voor alle failovergroepen in de betrokken regio. Microsoft verwacht dit type failover alleen in uitzonderlijke situaties uit te voeren. Vertrouw niet op door Microsoft beheerde failover voor de meeste oplossingen. Zie Failoverbeleid - Door Microsoft beheerd voor meer informatie.

  • Melding: Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

  • Actieve aanvragen: Actieve aanvragen tijdens de failover worden beëindigd en moeten opnieuw worden geprobeerd.

  • Verwachte gegevensverlies: Gegevensverlies is afhankelijk van het failoverbeleid dat u gebruikt.

    • Door de klant geïnitieerde failover: Als uw primaire database beschikbaar is, kunt u eventueel een failover uitvoeren zonder gegevensverlies. Het failoverproces synchroniseert gegevens tussen de primaire en secundaire databases voordat u van rol wisselt.

      Als uw primaire database niet beschikbaar is, moet u mogelijk een geforceerde failover uitvoeren, wat resulteert in gegevensverlies. U kunt de hoeveelheid gegevensverlies schatten door de replicatievertraging te bewaken. Zie SQL Database bewaken met metrische gegevens en waarschuwingen voor meer informatie.

    • Door Microsoft geïnitieerde failover: Een door Microsoft beheerde failover wordt alleen in uitzonderlijke situaties geactiveerd. Door Microsoft beheerde failovers zijn geforceerde failovers, wat betekent dat er gegevensverlies wordt verwacht. U kunt de hoeveelheid gegevensverlies die u mogelijk ondervindt, niet beheren.

  • Verwachte downtime: Downtime is afhankelijk van het failoverbeleid dat u gebruikt.

    • Door de klant geïnitieerde failover: Er is meestal maximaal 60 seconden downtime tijdens een failover. Zorg ervoor dat uw toepassing tijdelijke fouten afhandelt , zodat deze kan worden hersteld na korte perioden van downtime.

    • Door Microsoft geïnitieerde failover: U kunt een respijtperiode opgeven die bepaalt hoe lang Microsoft moet wachten voordat de failover wordt gestart. De minimale respijtperiode is één uur. De reactietijd van Microsoft is echter waarschijnlijk enkele uren.

  • Verkeer omleiden: Tijdens een failover werkt SQL Database de eindpunten voor lezen/schrijven en alleen-lezen-listener bij om verkeer naar de nieuwe primaire en secundaire databases te leiden, indien nodig.

    Als de nieuwe secundaire database (voorheen de primaire database) niet beschikbaar is, kan het alleen-lezen-listenereindpunt pas verbinding maken als de nieuwe secundaire database beschikbaar is.

Herstel van de regio

U bent verantwoordelijk voor het uitvoeren van een failback naar de primaire regio als u dit wilt doen. U kunt handmatig een failback uitvoeren naar de primaire regio door een door de klant beheerde failover uit te voeren.

Zelfs als Microsoft de oorspronkelijke failover heeft gestart, bent u nog steeds verantwoordelijk voor een failback naar de vorige regio, als u ervoor kiest.

Test voor regiofouten

U kunt een regiostoring simuleren door op elk gewenst moment een handmatige failover te activeren. U kunt een failover activeren (geen gegevensverlies) of een geforceerde failover.

Backups en herstel

Maak back-ups van uw databases om te beschermen tegen verschillende risico's, waaronder verlies van gegevens. Back-ups kunnen worden hersteld om te herstellen van onbedoeld gegevensverlies, beschadiging of andere problemen. Back-ups verschillen van zoneredundantie, actieve geo-replicatie of failovergroepen en hebben verschillende doeleinden. Zie Redundantie, replicatie en back-up voor meer informatie.

SQL Database biedt automatische back-ups van uw databases. Zie Automatische back-ups in SQL Database voor meer informatie over de back-upfrequentie, die van invloed kunnen zijn op de hoeveelheid gegevensverlies als u een back-up wilt herstellen.

Backupopslag

U kunt ervoor kiezen om uw geautomatiseerde back-ups op te slaan in LRS of ZRS. Als u een gekoppelde regio gebruikt, kunt u ervoor kiezen om uw geautomatiseerde back-ups te repliceren naar de gekoppelde regio met behulp van geografisch redundante opslag. Met deze mogelijkheid kunt u geo-herstel van uw back-ups in de gekoppelde regio inschakelen. Zie Automatische back-ups in SQL Database voor meer informatie.

Als u een niet-gepaareerde regio gebruikt of als u back-ups wilt repliceren naar een andere regio dan de gekoppelde regio, kunt u overwegen om de database te exporteren en het geëxporteerde bestand op te slaan in een opslagaccount dat gebruikmaakt van blobobjectreplicatie om te repliceren naar een opslagaccount in een andere regio. Zie Een database exporteren voor meer informatie.

Tolerantie voor serviceonderhoud

Wanneer SQL Database onderhoud uitvoert voor uw databases en elastische pools, kan er automatisch een failover van uw database worden uitgevoerd om een secundaire replica te gebruiken. Clienttoepassingen kunnen korte verbindingsonderbrekingen observeren wanneer er een failover plaatsvindt. Uw clienttoepassingen moeten de richtlijnen voor resistentie tegen tijdelijke fouten volgen om de effecten te minimaliseren.

Met SQL Database kunt u een onderhoudsvenster opgeven dat doorgaans wordt gebruikt voor service-upgrades en andere onderhoudsbewerkingen. Het configureren van een onderhoudsvenster kan u helpen bij het minimaliseren van eventuele bijwerkingen, zoals automatische failovers, tijdens uw kantooruren. U kunt ook vooraf meldingen ontvangen over gepland onderhoud.

Het platform onderhoudt automatisch de gateways die worden gebruikt voor het verwerken van verbindingen met SQL Database. Upgrades of onderhoudsbewerkingen kunnen ook korte verbindingsonderbrekingen veroorzaken die clients opnieuw kunnen proberen.

Zie het onderhoudsvenster in SQL Database voor meer informatie.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

De SLA (Service Level Agreement) voor SQL Database beschrijft de verwachte beschikbaarheid van de service en het verwachte herstelpunt en de hersteltijd voor actieve geo-replicatie.

Wanneer u een zoneredundante database of elastische pool implementeert en een ondersteunde servicelaag gebruikt, is de SLA voor uptime hoger.

Verwante inhoud

  • Last updated on