Opties voor bedrijfscontinuïteit en herstel na noodgevallen vergelijken

10 minuten

Azure Database for MySQL - Flexible Server biedt functies voor bedrijfscontinuïteit om uw database te beschermen in geval van geplande of niet-geplande storingen. Als u verschillende soorten storingen wilt aanpakken, kunt u verschillende niveaus van foutbeveiliging toepassen met verschillende hersteltijden of het risico op gegevensverlies.

Voorbeelden van downtime

Hier volgen enkele voorbeeldscenario's voor geplande en ongeplande downtime.

Scenario's met geplande downtime

De twee meest voorkomende scenario's voor geplande downtime zijn het schalen van berekeningen die door de gebruiker worden geïnitieerd en gepland onderhoud uitgevoerd door Azure.

Wanneer u een rekenschaalbewerking uitvoert, richt Azure een nieuwe flexibele MySQL-server in met de aangevraagde rekenconfiguratie. Met de bestaande server kunnen actieve controlepunten worden voltooid, worden bestaande verbindingen leeggemaakt, worden niet-doorgevoerde transacties geannuleerd en wordt de bestaande server afgesloten. Op dit moment koppelt Azure de opslag van de bestaande server aan de nieuwe server en wordt de database gestart. De database voert vervolgens herstel uit die nodig is voordat u doorgaat met het accepteren van clientverbindingen.

Nieuwe functies en bugfixes worden automatisch uitgevoerd als onderdeel van gepland onderhoud van de service. Patches voor secundaire versie-upgrades worden ook toegepast tijdens gepland onderhoud, wat enkele seconden downtime veroorzaakt. U kunt deze activiteiten plannen zoals beschreven in de volgende sectie, 'Geplande downtime en onderhoudsvensters'.

Niet-geplande uitvaltijd

De database kan om verschillende redenen onverwacht omlaag gaan, zoals:

Databasehardwarefout.
Fout met opslagstation.
Toepassings- of gebruikersfouten (bijvoorbeeld per ongeluk tabellen verwijderen).
Beschikbaarheidszone- en regiofouten.

Als hoge beschikbaarheid (HA) niet is ingeschakeld, probeert Azure herstel uit te voeren, zoals het kopiëren van verloren gegevens, het opnieuw opstarten van de server of zelfs het starten van de server op een ander fysiek knooppunt. Het inschakelen van hoge beschikbaarheid kan dit soort downtime verminderen of zelfs elimineren, zoals wordt beschreven in de volgende sectie.

Hoge beschikbaarheid

Azure Database for MySQL – Flexible Server biedt automatische failover, die een oplossing biedt die nooit vastgelegde gegevens kwijtraakt en om te voorkomen dat de database een single point of failure is. Wanneer u hoge beschikbaarheid hebt geconfigureerd, wordt met de flexibele MySQL-server automatisch een stand-byreplica ingericht en beheerd.

Er zijn twee soorten hoge beschikbaarheid met verschillende fouttolerantie- en latentie-afwegingen: zone-redundant en dezelfde zone.

Zone-redundante hoge beschikbaarheid

Zone-redundante hoge beschikbaarheid biedt redundantie in meerdere beschikbaarheidszones, wat het hoogste beschikbaarheidsniveau biedt, zelfs als een hele zone uitvalt. Het gebruik van een zoneredundante HA-configuratie introduceert extra latentie, dus zorg ervoor dat u bepaalt of dit acceptabel is voor uw toepassing. Bovendien vereist het gebruik van een zoneredundante HA-configuratie ook dat databaseclienttoepassingen zone-redundant zijn om ervoor te zorgen dat de algehele bewerkingen worden voortgezet.

Dezelfde zone HA

In een hoge beschikbaarheidsconfiguratie van dezelfde zone bevinden de primaire en stand-byservers zich in dezelfde beschikbaarheidszone, waardoor de latentie wordt geminimaliseerd. Hoewel lage latentie mogelijk vereist is in sommige gebruiksscenario's, met een hoge beschikbaarheidsconfiguratie van dezelfde zone, is de resulterende downtime langer als de flexibele MySQL-server herstelt.

In tegenstelling tot zone-redundante hoge beschikbaarheid is dezelfde zone-HA beschikbaar in alle regio's die ondersteuning bieden voor Azure Database for MySQL - Flexible Server.

Back-ups en herstellen

Serverback-ups zijn een cruciaal onderdeel van elke strategie voor bedrijfscontinuïteit. Azure Database for MySQL - Flexible Server maakt automatisch back-ups die veilig zijn opgeslagen in lokaal redundante opslag in de regio die als host fungeert voor de database. U kunt deze back-ups gebruiken om de database te herstellen naar een bepaald tijdstip, in het geval van storing of beschadiging van gegevens (bijvoorbeeld een fout of een fout bij het ontwikkelen van toepassingen).

Er zijn twee soorten back-ups. Met geautomatiseerde back-ups maakt de flexibele MySQL-server momentopnamen van databasegegevensbestanden en de bijbehorende transactielogboeken. Automatische momentopnameback-ups worden eenmaal per dag uitgevoerd en back-ups van transactielogboeken worden elke vijf minuten uitgevoerd. Als een back-up mislukt, wordt de server elke 20 minuten opnieuw uitgevoerd totdat de back-up is geslaagd.

Met back-ups op aanvraag kunt u op elk gewenst moment een databaseback-up maken. Bij beide typen back-ups worden back-upbestanden standaard zeven dagen bewaard. Op basis van uw bedrijfsbehoeften kunt u echter de waarde van de bewaarperiode van één tot 35 dagen configureren.

U kunt back-ups maximaal 10 jaar bewaren met behulp van de functie voor langetermijnretentie, momenteel in openbare preview. De langetermijnback-upoplossing kan afzonderlijk van of naast de geautomatiseerde Back-ups van Azure Database for MySQL worden gebruikt. Langetermijnback-ups kunnen worden gemaakt volgens een door de klant beheerd schema of op aanvraag. Back-ups worden opgeslagen in door Azure Backup beheerde opslagaccounts, in afzonderlijke beveiligings- en foutdomeinen.

Naast het maken van back-ups van de database, kunt u back-upbestanden exporteren naar Azure Blob Storage, die u vervolgens kunt gebruiken voor migraties, gegevensherstel of archivering. Exports op aanvraag zijn momenteel beschikbaar als openbare preview en zijn alleen beschikbaar in openbare cloudregio's.

Als u de back-upbestanden wilt opslaan, kunt u kiezen uit verschillende opslagopties:

Met lokaal redundante opslag (hetzelfde datacenter, dezelfde zone), worden back-upbestanden opgeslagen in hetzelfde datacenter als de database. Deze optie biedt elf 9's (99,999999999999%) duurzaamheid voor back-upobjecten gedurende een jaar. Servers zonder hoge beschikbaarheid of dezelfde zone maken standaard gebruik van lokaal redundante opslag.
Met zone-redundante back-upopslag (verschillende zone, dezelfde regio) worden back-upbestanden opgeslagen in de beschikbaarheidszone van de server en gerepliceerd naar een andere beschikbaarheidszone in dezelfde regio. Deze optie biedt twaalf 9's (99,9999999999999%) van duurzaamheid gedurende een bepaald jaar. Zone-redundante opslag is belangrijk voor zone-redundante hoge beschikbaarheid en is vereist als gegevens binnen één regio moeten blijven.
Met geografisch redundante back-upopslag (verschillende regio's) worden back-upbestanden opgeslagen in de regio van de server en vervolgens gerepliceerd naar een andere geografisch gekoppelde regio. Deze optie biedt zestien jaren (99,9999999999999999999%) van duurzaamheid gedurende een bepaald jaar. Geografisch redundante opslag wordt alleen ondersteund in gekoppelde Azure-regio's.

Opmerking: Met Azure Database for MySQL - Flexible Server is back-upruimte tot 100% van de ingerichte opslagruimte beschikbaar zonder extra kosten. Extra opslagruimte wordt in GB per maand in rekening gebracht. Zie de prijsdocumentatie voor meer informatie.

Nadat u een back-up hebt, kunt u de back-up herstellen naar een nieuwe flexibele MySQL-server. U kunt de back-up drie manieren selecteren: handmatig een volledige back-up selecteren, automatisch het meest recente herstelpunt selecteren of automatisch het snelste herstelpunt selecteren. Als u geografisch redundante back-ups hebt, kunt u ook herstellen naar de gekoppelde regio (de meerdere regio's).

Geplande downtime en onderhoudsvensters

Periodiek onderhoud is vereist om de beheerde server stabiel, veilig en up-to-date te houden. Tijdens onderhoudsvensters ontvangt de service implementaties van nieuwe functies, updates en patches. Normaal gesproken worden onderhoudsvensters minstens om de 30 dagen uitgevoerd, maar kritieke beveiligingspatches worden binnen zeven dagen of minder toegepast.

U kunt een door het systeem beheerde planning kiezen of een aangepast schema definiëren voor elke flexibele MySQL-server in uw Azure-abonnement.

U kunt op verschillende manieren meldingen over gepland onderhoud ontvangen. Meldingen kunnen het volgende zijn:

E-mail verzonden naar een specifiek adres of een Azure Resource Manager-rol.
Verzonden via tekstbericht (SMS).
Gepusht als een Azure-app-melding.
Bezorgd via spraakbericht.

Aangepaste onderhoudsvensters

Standaard kiest het systeem met een door het systeem beheerde planning een periode van één uur tussen 11:00 en 7:00 uur in de tijdzone van de flexibele MySQL-serverregio. Met een aangepast schema kunt u uw onderhoudsvenster voor de server opgeven door de dag van de week en een tijd van één uur te kiezen.

Onderhoud van bijna nul downtime voor HA-servers (openbare preview)

Servers met hoge beschikbaarheid profiteren van Near Zero Downtime Maintenance, een nieuwe functie, die de onderhoudstijd aanzienlijk vermindert. De verwachte downtime ligt tussen 40 en 60 seconden. Onderhoud van bijna nul downtime is cruciaal voor toepassingen met zeer hoge beschikbaarheidsvereisten, waarvoor minimale onderbrekingen van databaseconnectiviteit nodig zijn.

Onderhoud opnieuw plannen (openbare preview)

U kunt onderhoud opnieuw plannen bij gebruik van de servicelagen Algemeen gebruik of Bedrijfskritiek. In de sectie Onderhoud van Azure Portal kunt u het volgende geplande onderhoud opnieuw plannen naar een andere datum en tijd. U kunt ook onderhoud op aanvraag initiëren door Reschedule naar Now te selecteren.