Overzicht van bedrijfscontinuïteit met Azure Database for MySQL - Flexibele server

VAN TOEPASSING OP: Azure Database for MySQL - Flexibele server

Azure Database for MySQL flexibele server maakt bedrijfscontinuïteitsmogelijkheden mogelijk die uw databases beschermen in geval van geplande en ongeplande uitval. Functies zoals geautomatiseerde back-ups en hoge beschikbaarheid hebben betrekking op verschillende niveaus van foutbeveiliging met verschillende hersteltijd en blootstelling aan gegevensverlies. Wanneer u uw toepassing ontwerpt om te beschermen tegen fouten, moet u rekening houden met de beoogde hersteltijd (RTO) en RPO (Recovery Point Objective) voor elke toepassing. RTO is de downtimetolerantie en RPO is de gegevensverliestolerantie na een onderbreking van de databaseservice.

In de volgende tabel ziet u de functies die azure Database for MySQL flexibele server biedt.

Functie	Beschrijving	Beperkingen
Back-up en herstel	De service voert automatisch dagelijkse back-ups van uw databasebestanden uit en maakt continu een back-up van transactielogboeken. Back-ups kunnen gedurende elke periode tussen 1 en 35 dagen worden bewaard. U kunt uw databaseserver herstellen naar een bepaald tijdstip binnen de bewaarperiode voor back-ups. Hersteltijd is afhankelijk van de grootte van de gegevens die moeten worden hersteld + de tijd die nodig is om logboekherstel uit te voeren. Raadpleeg Concepten - Back-up en herstel voor meer informatie.	Back-upgegevens blijven binnen de regio
Lokale redundante back-up	De serviceback-ups worden automatisch en veilig opgeslagen in een lokale redundante opslag binnen een regio en in dezelfde beschikbaarheidszone. De lokaal redundante back-ups repliceren de back-upgegevensbestanden van de server drie keer binnen één fysieke locatie in de primaire regio. Lokaal redundante back-upopslag biedt ten minste 99,999999999% (11 negens) duurzaamheid van objecten gedurende een bepaald jaar. Raadpleeg Concepten - Back-up en herstel voor meer informatie.	Van toepassing in alle regio's
Geografisch redundante back-up	De serviceback-ups kunnen tijdens het maken worden geconfigureerd als geografisch redundant. Door georedundantie in te schakelen, worden de back-upgegevensbestanden van de server in de gekoppelde regio van de primaire regio ™gerepliceerd om regionale tolerantie te bieden. Geografisch redundante back-upopslag biedt ten minste 99,99999999999999% (16 negens) duurzaamheid van objecten gedurende een bepaald jaar. Raadpleeg Concepten - Back-up en herstel voor meer informatie.	Beschikbaar in alle gekoppelde Azure-regio's
Zone-redundante hoge beschikbaarheid	De service kan worden geïmplementeerd in de modus voor hoge beschikbaarheid, waarmee primaire en stand-byservers in twee verschillende beschikbaarheidszones binnen een regio worden geïmplementeerd. Zone-redundante hoge beschikbaarheid beschermt tegen storingen op zoneniveau en helpt ook bij het verminderen van de downtime van toepassingen tijdens geplande en ongeplande downtimegebeurtenissen. Gegevens van de primaire server worden synchroon naar de stand-byreplica gerepliceerd. Tijdens een downtimegebeurtenis wordt voor de databaseserver automatisch een Failover-overschakeling uitgevoerd naar de stand-byreplica. Raadpleeg Concepten - Hoge beschikbaarheid voor meer informatie.	Ondersteund in algemene en Bedrijfskritiek rekenlagen. Alleen beschikbaar in regio's waar meerdere zones beschikbaar zijn.
Premium-bestandsshares	Databasebestanden worden opgeslagen in een zeer duurzame en betrouwbare Azure Premium-bestandsshares die gegevensredundantie bieden met drie kopieën van replica's die zijn opgeslagen in een beschikbaarheidszone met automatische mogelijkheden voor gegevensherstel. Raadpleeg Premium-bestandsshares voor meer informatie.	Gegevens die zijn opgeslagen in een beschikbaarheidszone

Beperking van geplande downtime

Hier volgen enkele geplande onderhoudsscenario's die downtime veroorzaken:

Scenario	Verwerken
Rekenkracht schalen (gebruiker)	Wanneer u de schaalbewerking voor berekeningen uitvoert, wordt een nieuwe flexibele server ingericht met behulp van de geschaalde rekenconfiguratie. In de bestaande databaseserver kunnen actieve controlepunten worden voltooid, clientverbindingen worden leeggemaakt, worden alle niet-doorgevoerde transacties geannuleerd en wordt deze afgesloten. De opslag wordt vervolgens gekoppeld aan de nieuwe server en de database wordt gestart, waarmee zo nodig herstel wordt uitgevoerd voordat clientverbindingen worden geaccepteerd.
Nieuwe software-implementatie (Azure)	Nieuwe functies worden automatisch geïmplementeerd of opgeloste fouten als onderdeel van gepland onderhoud van de service en u kunt plannen wanneer deze activiteiten plaatsvinden. Zie de documentatie voor meer informatie en controleer ook uw portal
Secundaire versie-upgrades (Azure)	Met Azure Database for MySQL Flexibele server worden databaseservers automatisch gepatcht naar de secundaire versie die wordt bepaald door Azure. Dit gebeurt als onderdeel van gepland onderhoud van de service. Dit zou een korte downtime in seconden veroorzaken en de databaseserver wordt automatisch opnieuw opgestart met de nieuwe secundaire versie. Zie de documentatie voor meer informatie en controleer ook uw portal.

Wanneer de flexibele server is geconfigureerd met zone-redundante hoge beschikbaarheid, voert de flexibele server eerst bewerkingen uit op de stand-byserver en vervolgens op de primaire server zonder failover. Raadpleeg Concepten - Hoge beschikbaarheid voor meer informatie.

Niet-geplande uitvaltijd beperken

Niet-geplande downtime kan optreden als gevolg van onvoorziene fouten, waaronder onderliggende hardwarestoringen, netwerkproblemen en softwarefouten. Als de databaseserver onverwacht uitvalt, als deze is geconfigureerd met hoge beschikbaarheid [HA], wordt de stand-byreplica geactiveerd. Zo niet, dan wordt automatisch een nieuwe databaseserver ingericht. Hoewel een niet-geplande downtime niet kan worden vermeden, beperkt de flexibele server de downtime door automatisch herstelbewerkingen uit te voeren op zowel databaseserver- als opslaglagen zonder menselijke tussenkomst.

Niet-geplande downtime: foutscenario's en serviceherstel

Hier volgen enkele niet-geplande foutscenario's en het herstelproces:

Scenario	Herstelproces [niet-HA]	Herstelproces [HA]
Databaseserverfout	Als de databaseserver niet beschikbaar is vanwege een onderliggende hardwarefout, worden actieve verbindingen verbroken en worden alle actieve transacties afgebroken. Azure probeert de databaseserver opnieuw op te starten. Als dat lukt, wordt het databaseherstel uitgevoerd. Als het opnieuw opstarten mislukt, wordt geprobeerd de databaseserver opnieuw op te starten op een ander fysiek knooppunt. De hersteltijd (RTO) is afhankelijk van verschillende factoren, waaronder de activiteit op het moment van fout, zoals een grote transactie en de hoeveelheid herstel die moet worden uitgevoerd tijdens het opstarten van de databaseserver. De RPO is nul omdat er geen gegevensverlies wordt verwacht voor de vastgelegde transacties. Toepassingen die gebruikmaken van de MySQL-databases moeten worden gebouwd op een manier waarop ze verbroken verbindingen en mislukte transacties detecteren en opnieuw proberen. Wanneer de toepassing opnieuw probeert, worden de verbindingen omgeleid naar de zojuist gemaakte databaseserver. Andere beschikbare opties worden hersteld vanuit een back-up. U kunt zowel PITR als Geo-herstel vanuit gekoppelde regio gebruiken. PITR : RTO: Varieert, RPO=0sec Geo-herstel : RTO: varieert RPO <1 h. U kunt leesreplica ook gebruiken als dr-oplossing. U kunt de replicatie stoppen, waardoor de leesreplica lezen/schrijven wordt gemaakt (zelfstandig en vervolgens het toepassingsverkeer omleiden naar deze database). De RTO is in de meeste gevallen een paar minuten en RPO < 1 uur. RTO en RPO kunnen in sommige gevallen veel hoger zijn, afhankelijk van verschillende factoren, waaronder latentie tussen sites, de hoeveelheid gegevens die moet worden verzonden en belangrijk de werkbelasting voor het schrijven van de primaire database.	Als er fouten in de databaseserver of niet-herstelbare fouten worden gedetecteerd, wordt de stand-bydatabaseserver geactiveerd, waardoor de downtime wordt verminderd. Raadpleeg de pagina concepten voor hoge beschikbaarheid voor meer informatie. RTO is naar verwachting 60-120 s, met RPO=0. Opmerking: De opties voor herstelproces [niet-HA] zijn hier ook van toepassing.
Opslagfout	Toepassingen zien geen gevolgen voor opslaggerelateerde problemen, zoals een schijffout of een beschadiging van een fysiek blok. Omdat de gegevens in drie kopieën worden opgeslagen, wordt de kopie van de gegevens geleverd door de overlevende opslag. Blokbeschadigingen worden automatisch gecorrigeerd. Als er een kopie van gegevens verloren gaat, wordt automatisch een nieuwe kopie van de gegevens gemaakt. In een zeldzame of slechtste situatie als alle kopieën beschadigd zijn, kunnen we herstellen vanuit geo-herstel (gekoppelde regio). RPO zou 1 uur zijn < en RTO zou variëren. U kunt leesreplica ook gebruiken als dr-oplossing zoals hierboven beschreven.	Voor dit scenario zijn de opties hetzelfde als voor herstelproces [niet-HA] .
Logische/gebruikersfouten	Herstel van gebruikersfouten, zoals per ongeluk verwijderde tabellen of onjuist bijgewerkte gegevens, omvat het uitvoeren van een herstel naar een bepaald tijdstip (PITR) door de gegevens te herstellen en te herstellen tot de tijd voordat de fout is opgetreden. U kunt binnen vijf dagen na het verwijderen van de server een verwijderde flexibele serverresource herstellen. Raadpleeg gedocumenteerde stappen voor een gedetailleerde handleiding over het herstellen van een verwijderde server (.. /flexible-server/how-to-restore-dropped-server.md). Beheerders kunnen beheervergrendelingen gebruiken om serverbronnen na de implementatie te beschermen tegen onbedoelde verwijdering of onverwachte wijzigingen.	Deze gebruikersfouten worden niet beveiligd met hoge beschikbaarheid, omdat alle gebruikersbewerkingen ook naar de stand-by worden gerepliceerd. Voor dit scenario zijn de opties hetzelfde als voor herstelproces [niet-HA]
Fout in beschikbaarheidszone	Hoewel het een zeldzame gebeurtenis is, kunt u geo-herstel uitvoeren van een gekoppelde regio als u wilt herstellen van een fout op zoneniveau. RPO zou 1 uur zijn <en RTO zou variëren. U kunt leesreplica ook gebruiken als dr-oplossing door replica's te maken in een andere beschikbaarheidszone. RTO\RPO lijkt op wat hierboven wordt beschreven.	Als u zone-redundante hoge beschikbaarheid hebt ingeschakeld, voert de flexibele server automatische failover uit naar de stand-bysite. Raadpleeg ha-concepten voor meer informatie. RTO is naar verwachting 60-120 s, met RPO=0. Andere beschikbare opties worden hersteld vanuit een back-up. U kunt zowel PITR als Geo-herstel vanuit gekoppelde regio gebruiken. PITR : RTO: Varieert, RPO=0 sec. Geo-herstel : RTO: varieert, RPO <1 h Opmerking:Als u dezelfde zone HA hebt ingeschakeld, zijn de opties hetzelfde als voor herstelproces [niet-HA].
Regiofout	Hoewel het een zeldzame gebeurtenis is, kunt u databaseherstel uitvoeren door een nieuwe server te maken met behulp van de meest recente geografisch redundante back-up die beschikbaar is in hetzelfde abonnement om toegang te krijgen tot de meest recente gegevens. Er wordt een nieuwe flexibele server geïmplementeerd in de geselecteerde regio. De tijd die nodig is om te herstellen, is afhankelijk van de vorige back-up en het aantal transactielogboeken dat moet worden hersteld. RPO zou in de meeste gevallen 1 uur zijn <en RTO zou variëren.	Voor dit scenario zijn de opties hetzelfde als voor herstelproces [niet-HA] .

Vereisten en beperkingen

Regiogegevenslocatie

Standaard worden klantgegevens niet verplaatst of opgeslagen uit de regio waarin deze is geïmplementeerd. Klanten kunnen er echter voor kiezen om geografisch redundante back-ups in te schakelen of replicatie tussen regio's in te stellen voor het opslaan van gegevens in een andere regio.

Volgende stappen

• Meer informatie over zoneredundante hoge beschikbaarheid
• Meer informatie over back-up en herstel