Hoge beschikbaarheid in Azure Database for MySQL

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - enkele server

Belangrijk

Azure Database for MySQL enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan een upgrade uit te voeren naar een flexibele Azure Database for MySQL-server. Zie Wat gebeurt er met Azure Database for MySQL Enkele server voor meer informatie over migreren naar Azure Database for MySQL Flexibele server ?

De Azure Database for MySQL-service biedt een gegarandeerd hoog beschikbaarheidsniveau met de SLA (Service Level Agreement) met een beschikbaarheid van 99,99% . Azure Database for MySQL biedt hoge beschikbaarheid tijdens geplande gebeurtenissen, zoals door de gebruiker geïnitieerde schaalbewerking, en ook wanneer er niet-geplande gebeurtenissen zoals onderliggende hardware, software of netwerkfouten optreden. Met Azure Database for MySQL kunt u snel herstellen van de meest kritieke omstandigheden, waardoor vrijwel geen time voor toepassingen in gebruik wordt genomen bij het gebruik van deze service.

Azure Database for MySQL is geschikt voor het uitvoeren van bedrijfskritieke databases waarvoor een hoge uptime is vereist. De service is gebouwd op Azure-architectuur en heeft inherente mogelijkheden voor hoge beschikbaarheid, redundantie en tolerantie om de downtime van databases te beperken door geplande en ongeplande storingen, zonder dat u extra onderdelen hoeft te configureren.

Onderdelen in Azure Database for MySQL

Onderdeel Beschrijving
MySQL-databaseserver Azure Database for MySQL biedt beveiliging, isolatie, resourcebeveiliging en snelle herstartmogelijkheden voor databaseservers. Deze mogelijkheden vereenvoudigen bewerkingen zoals schalen en databaseserverherstel na een storing in 60-120 seconden, afhankelijk van de transactionele activiteit in de database.
Gegevenswijzigingen in de databaseserver vinden doorgaans plaats in de context van een databasetransactie. Alle databasewijzigingen worden synchroon vastgelegd in de vorm van vooruitschrijvende logboeken (ib_log) in Azure Storage, die is gekoppeld aan de databaseserver. Tijdens het controlepunt van de database worden gegevenspagina's uit het geheugen van de databaseserver ook leeggemaakt naar de opslag.
Externe opslag Alle fysieke MySQL-gegevensbestanden en logboekbestanden worden opgeslagen in Azure Storage, dat is ontworpen om drie kopieën van gegevens in een regio op te slaan om gegevensredundantie, beschikbaarheid en betrouwbaarheid te garanderen. De opslaglaag is ook onafhankelijk van de databaseserver. Deze kan binnen 60 seconden worden losgekoppeld van een mislukte databaseserver en opnieuw worden gekoppeld aan een nieuwe databaseserver. Daarnaast controleert Azure Storage continu op eventuele opslagfouten. Als een blokbeschadiging wordt gedetecteerd, wordt deze automatisch opgelost door een nieuwe opslagkopie te instantiëren.
Gateway De gateway fungeert als een databaseproxy en stuurt alle clientverbindingen naar de databaseserver.

Beperking van geplande downtime

Azure Database for MySQL is ontworpen om hoge beschikbaarheid te bieden tijdens geplande downtimebewerkingen.

view of Elastic Scaling in Azure MySQL

Hier volgen enkele geplande onderhoudsscenario's:

Scenario Beschrijving
Rekenkracht omhoog/omlaag schalen Wanneer de gebruiker rekenkracht omhoog/omlaag schaalt, wordt een nieuwe databaseserver ingericht met behulp van de geschaalde rekenconfiguratie. In de oude databaseserver zijn actieve controlepunten toegestaan om te voltooien, clientverbindingen worden leeggemaakt, eventuele niet-doorgevoerde transacties worden geannuleerd en wordt het afgesloten. De opslag wordt vervolgens losgekoppeld van de oude databaseserver en gekoppeld aan de nieuwe databaseserver. Wanneer de clienttoepassing de verbinding opnieuw probeert uit te voeren of een nieuwe verbinding probeert te maken, stuurt de gateway de verbindingsaanvraag door naar de nieuwe databaseserver.
Opslag omhoog schalen Het omhoog schalen van de opslag is een onlinebewerking en onderbreekt de databaseserver niet.
Nieuwe software-implementatie (Azure) Nieuwe functies worden automatisch geïmplementeerd of opgeloste fouten als onderdeel van gepland onderhoud van de service. Raadpleeg de documentatie voor meer informatie en controleer ook uw portal.
Secundaire versie-upgrades In Azure Database for MySQL worden databaseservers automatisch gepatcht naar de secundaire versie die wordt bepaald door Azure. Dit gebeurt als onderdeel van gepland onderhoud van de service. Tijdens gepland onderhoud kunnen er databaseservers opnieuw worden opgestart of failovers, wat kan leiden tot een korte onbeschikbaarheid van de databaseservers voor eindgebruikers. Azure Database for MySQL-servers worden uitgevoerd in containers, zodat het opnieuw opstarten van de databaseserver doorgaans snel verloopt, normaal gesproken in 60-120 seconden. De volledige geplande onderhoudsbeurt, inclusief elke server die opnieuw wordt opgestart, wordt zorgvuldig bewaakt door het technische team. De serverfailovertijd is afhankelijk van de hersteltijd van de database, waardoor de database langer online komt als u een zware transactionele activiteit op de server hebt op het moment van failover. Om langere herstarttijd te voorkomen, is het raadzaam om langdurige transacties (bulkbelastingen) tijdens geplande onderhoudsgebeurtenissen te voorkomen. Raadpleeg de documentatie voor meer informatie en controleer ook uw portal.

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, wordt een nieuwe databaseserver automatisch ingericht in 60-120 seconden. De externe opslag wordt automatisch gekoppeld aan de nieuwe databaseserver. MySQL-engine voert de herstelbewerking uit met behulp van WAL- en databasebestanden en opent de databaseserver om clients verbinding te laten maken. Niet-doorgevoerde transacties gaan verloren en moeten opnieuw worden geprobeerd door de toepassing. Hoewel een niet-geplande downtime niet kan worden vermeden, beperkt Azure Database for MySQL de downtime door automatisch herstelbewerkingen uit te voeren op zowel databaseserver- als opslaglagen zonder menselijke tussenkomst.

view of High Availability in Azure MySQL

Niet-geplande downtime: foutscenario's en serviceherstel

Hier volgen enkele foutscenario's en hoe Azure Database for MySQL automatisch wordt hersteld:

Scenario Automatisch herstel
Databaseserverfout Als de databaseserver niet beschikbaar is vanwege een onderliggende hardwarefout, worden actieve verbindingen verbroken en worden alle actieve transacties afgebroken. Er wordt automatisch een nieuwe databaseserver geïmplementeerd en de externe gegevensopslag wordt gekoppeld aan de nieuwe databaseserver. Nadat het herstel van de database is voltooid, kunnen clients via de gateway verbinding maken met de nieuwe databaseserver.

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, wordt de verbinding met de zojuist gemaakte databaseserver transparant door de gateway omgeleid.
Opslagfout Toepassingen zien geen gevolgen voor opslaggerelateerde problemen, zoals een schijffout of een beschadiging van een fysiek blok. Omdat de gegevens worden opgeslagen in 3 kopieën, 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.

Hier volgen enkele foutscenario's waarvoor gebruikersactie moet worden hersteld:

Scenario Herstelplan
Regiofout Het mislukken van een regio is een zeldzame gebeurtenis. Als u echter bescherming nodig hebt tegen een regiofout, kunt u een of meer leesreplica's configureren in andere regio's voor herstel na noodgevallen (DR). (Zie dit artikel over het maken en beheren van leesreplica's voor meer informatie). In het geval van een storing op regioniveau kunt u de leesreplica die is geconfigureerd op de andere regio handmatig promoveren als uw productiedatabaseserver.
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.

Als u alleen een subset van databases of specifieke tabellen wilt herstellen in plaats van alle databases op de databaseserver, kunt u de databaseserver in een nieuw exemplaar herstellen, de tabellen exporteren via mysqldump en vervolgens herstellen gebruiken om deze tabellen in uw database te herstellen.

Samenvatting

Azure Database for MySQL biedt snel opnieuw opstarten van databaseservers, redundante opslag en efficiënte routering vanuit de gateway. Voor aanvullende gegevensbeveiliging kunt u back-ups configureren voor geo-replicatie en ook een of meer leesreplica's implementeren in andere regio's. Met inherente mogelijkheden voor hoge beschikbaarheid beschermt Azure Database for MySQL uw databases tegen de meest voorkomende storingen en biedt een toonaangevende, financiële ondersteuning van 99,99% van de SLA voor uptime. Met al deze beschikbaarheids- en betrouwbaarheidsmogelijkheden kan Azure het ideale platform zijn om uw bedrijfskritieke toepassingen uit te voeren.

Volgende stappen