Hoge beschikbaarheid in Azure Database for MariaDB

  • Artikel

Belangrijk

Azure Database for MariaDB bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan om te migreren naar Azure Database for MySQL. Zie Wat gebeurt er met Azure Database for MariaDB voor meer informatie over migreren naar Azure Database for MySQL.

De Azure Database for MariaDB-service is geschikt voor het uitvoeren van bedrijfskritieke databases waarvoor een hoge uptime is vereist. Het biedt hoge beschikbaarheid tijdens:

  • Geplande gebeurtenissen, zoals door de gebruiker geïnitieerde schaalbewerkingen.
  • Niet-geplande gebeurtenissen, zoals onderliggende hardware, software of netwerkfouten.

Azure Database for MariaDB biedt een service level agreement met financiële ondersteuning voor uptime. Omdat de service is gebouwd op Azure-architectuur, kunt u profiteren van de mogelijkheden voor hoge beschikbaarheid, redundantie en tolerantie zonder extra onderdelen te configureren.

Onderdelen in Azure Database for MariaDB

Onderdeel Beschrijving
MariaDB-databaseserver Azure Database for MariaDB biedt beveiliging, isolatie, resourcebeveiliging en snel opnieuw opstarten voor databaseservers. Deze mogelijkheden vereenvoudigen bewerkingen zoals schalen en databaseserverherstel (in seconden) na een storing.
Gegevenswijzigingen in de databaseserver vinden doorgaans plaats in de context van een databasetransactie. Alle databasewijzigingen worden synchroon vastgelegd in de vorm van write-ahead-logboeken (ib_log bestanden) 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 MariaDB-gegevensbestanden en logboekbestanden worden opgeslagen in Azure Storage, waarin drie kopieën van gegevens in een regio worden opgeslagen om gegevensredundantie, beschikbaarheid en betrouwbaarheid te bieden. De opslaglaag is onafhankelijk van de databaseserver. Deze kan binnen enkele seconden worden losgekoppeld van een mislukte databaseserver en opnieuw worden gekoppeld aan een nieuwe databaseserver.
Azure Storage bewaakt continu op eventuele opslagfouten. Als er een blokbeschadiging wordt gedetecteerd, wordt het probleem automatisch opgelost door een nieuwe opslagkopie te instantiëren.
Gateway De gateway fungeert als een databaseproxy door alle clientverbindingen naar de databaseserver te routeren.

Beperking van geplande downtime

De architectuur van Azure Database for MariaDB biedt hoge beschikbaarheid tijdens geplande downtimebewerkingen.

Diagram of elastic scaling in Azure Database for MariaDB.

Hier volgen enkele scenario's voor gepland onderhoud:

Scenario Beschrijving
Rekenkracht omhoog of omlaag schalen Wanneer u een berekeningsbewerking voor omhoog of omlaag schalen uitvoert, richt Azure Database for MariaDB een nieuwe databaseserver in met behulp van de berekende rekenconfiguratie. Op de oude databaseserver kan de service actieve controlepunten voltooien, clientverbindingen leegmaken en eventuele niet-doorgevoerde transacties annuleren. De service sluit vervolgens de oude databaseserver af. De opslag van de oude databaseserver wordt losgekoppeld en de opslag wordt 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) Implementaties van nieuwe functies of bugfixes vinden automatisch plaats als onderdeel van het geplande onderhoud van de service. Zie de documentatie en controleer uw portal voor meer informatie.
Secundaire versie-upgrades In Azure Database for MariaDB worden databaseservers automatisch gepatcht naar de secundaire versie die door Azure wordt bepaald. Automatische patches worden uitgevoerd als onderdeel van het geplande onderhoud van de service. Er treedt een korte downtime op in seconden en de databaseserver wordt automatisch opnieuw opgestart met de nieuwe secundaire versie. Zie de documentatie en controleer uw portal voor meer informatie.

Beperking van niet-geplande downtime

Niet-geplande downtime kan optreden als gevolg van onvoorziene fouten, waaronder onderliggende hardwarefouten, netwerkproblemen en softwarefouten. Als de databaseserver onverwacht niet beschikbaar is, wordt er binnen enkele seconden automatisch een nieuwe databaseserver ingericht. De externe opslag wordt automatisch gekoppeld aan de nieuwe databaseserver.

De MariaDB-engine voert de herstelbewerking uit met behulp van write-ahead-logboek- en databasebestanden en opent de databaseserver om clients verbinding te laten maken. Niet-doorgevoerde transacties gaan verloren en de toepassing moet deze opnieuw proberen.

Hoewel u niet-geplande downtime niet kunt voorkomen, beperkt Azure Database for MariaDB dit door automatisch herstelbewerkingen uit te voeren op zowel de databaseserver als de opslaglagen zonder menselijke tussenkomst.

Diagram of high availability in Azure Database for MariaDB.

Niet-geplande downtime: Foutscenario's en serviceherstel

Hier volgen twee foutscenario's en hoe Azure Database for MariaDB automatisch wordt hersteld:

Scenario Automatisch herstel
Databaseserverfout Als de databaseserver niet beschikbaar is vanwege een onderliggende hardwarefout, worden actieve verbindingen in Azure Database for MariaDB verwijderd en worden eventuele actieve transacties geannuleerd. De service implementeert automatisch een nieuwe databaseserver en koppelt de externe gegevensopslag aan de nieuwe databaseserver. Nadat het databaseherstel is voltooid, kunnen clients verbinding maken met de nieuwe databaseserver via de gateway.
Toepassingen die gebruikmaken van de MariaDB-databases moeten worden gebouwd op een manier waarop ze verbroken verbindingen en mislukte transacties detecteren en opnieuw proberen. Wanneer de toepassing een verbinding opnieuw probeert uit te voeren, wordt de verbinding transparant omgeleid naar de zojuist gemaakte databaseserver.
Opslagfout Opslaggerelateerde problemen, zoals een schijffout of een fysieke blokbeschadiging, hebben geen invloed op toepassingen. Omdat de gegevens in drie kopieën worden opgeslagen, dient de overlevende opslag de kopie van de gegevens. Azure Database for MariaDB corrigeert automatisch blokbeschadigingen. Als er een kopie van gegevens verloren gaat, maakt de service automatisch een nieuwe kopie van de gegevens.

Hier volgen 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. Zie dit artikel voor meer informatie over het maken en beheren van leesreplica's. Als er een fout op regioniveau optreedt, kunt u handmatig een leesreplica promoveren die is geconfigureerd in een andere regio als uw productiedatabaseserver.
Fout logische/gebruiker Herstel van gebruikersfouten, zoals per ongeluk verwijderde tabellen of onjuist bijgewerkte gegevens, omvat het uitvoeren van herstel naar een bepaald tijdstip. Met deze actie worden de gegevens hersteld en hersteld tot de tijd net 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 deze tabellen vervolgens herstellen in uw database.

Samenvatting

Azure Database for MariaDB heeft inherente mogelijkheden voor hoge beschikbaarheid om uw databases te beschermen tegen veelvoorkomende storingen. Het biedt snel opnieuw opstarten van databaseservers, redundante opslag en efficiënte routering vanaf de gateway. Voor aanvullende gegevensbeveiliging kunt u back-ups configureren voor geo-replicatie en leesreplica's implementeren in andere regio's.

Volgende stappen