In deze driedelige blogserie hebben we een High Availability (HA)-framework voor MySQL-hosting geïntroduceerd in Deel I, en hebben we de details van de semisynchrone MySQL-replicatie in Deel II besproken. Nu, in deel III, bekijken we hoe het framework omgaat met enkele van de belangrijke MySQL-foutscenario's en herstelt om hoge beschikbaarheid te garanderen.
MySQL-foutscenario's
Scenario 1 – Master MySQL verdwijnt
- Het Corosync- en Pacemaker-framework detecteert dat de master MySQL niet langer beschikbaar is. Pacemaker verlaagt de hoofdbron en probeert te herstellen met een herstart van de MySQL-service, indien mogelijk.
- Op dit moment zijn, vanwege de semisynchrone aard van de replicatie, alle transacties die op de master zijn vastgelegd, ontvangen door ten minste één van de slaven.
- Pacemaker wacht totdat alle ontvangen transacties op de slaves zijn toegepast en laat de slaves hun promotiescores rapporteren. De scoreberekening wordt zo gedaan dat de score '0' is als een slave volledig synchroon loopt met de master, en anders een negatief getal is.
- Pacemaker kiest de slaaf die de 0-score heeft gerapporteerd en promoot die slaaf die nu de rol van master MySQL op zich neemt waarop schrijven is toegestaan.
- Na slave-promotie activeert de Resource Agent een DNS-herrouteringsmodule. De module werkt de proxy-DNS-invoer bij met het IP-adres van de nieuwe master, waardoor alle schrijfbewerkingen naar de nieuwe master gemakkelijker kunnen worden doorgestuurd.
- Pacemaker stelt ook de beschikbare slaves in om te beginnen met repliceren vanaf deze nieuwe master.
Dus, wanneer een master MySQL uitvalt (of het nu is als gevolg van een MySQL-crash, OS-crash, herstart van het systeem, enz.), detecteert ons HA-framework dit en promoot een geschikte slave voor de rol van de meester overnemen. Dit zorgt ervoor dat het systeem beschikbaar blijft voor de applicaties.
#MySQL High Availability Framework Explained – Part III:Failure ScenariosClick To Tweet
Scenario 2 – Slave MySQL verdwijnt
- Het Corosync- en Pacemaker-framework detecteert dat de slave MySQL niet langer beschikbaar is.
- Pacemaker probeert de bron te herstellen door MySQL op het knooppunt opnieuw te starten. Als het verschijnt, wordt het weer als slaaf toegevoegd aan de huidige master en gaat de replicatie verder.
- Als het herstel mislukt, rapporteert Pacemaker die resource als down - op basis waarvan waarschuwingen of meldingen kunnen worden gegenereerd. Indien nodig zal het ScaleGrid-ondersteuningsteam het herstel van dit knooppunt afhandelen.
- In dit geval is er geen invloed op de beschikbaarheid van MySQL-services.
Scenario 3 – Netwerkpartitie – Netwerkverbinding valt weg tussen master- en slave-knooppunten
Dit is een klassiek probleem in elk gedistribueerd systeem waarbij elk knooppunt denkt dat de andere knooppunten niet beschikbaar zijn, terwijl in werkelijkheid alleen de netwerkcommunicatie tussen de knooppunten wordt verbroken. Dit scenario is beter bekend als een split-brain-scenario en kan, als het niet goed wordt afgehandeld, ertoe leiden dat meer dan één node beweert een master MySQL te zijn, wat op zijn beurt leidt tot inconsistenties en corruptie van gegevens.
Laten we een voorbeeld gebruiken om te bekijken hoe ons raamwerk omgaat met split-brain-scenario's in het cluster. We nemen aan dat vanwege netwerkproblemen het cluster is opgedeeld in twee groepen – master in de ene groep en 2 slaves in de andere groep, en we zullen dit aanduiden als [(M), (S1,S2)].
- Corosync detecteert dat de master node niet kan communiceren met de slave nodes, en de slave nodes kunnen wel met elkaar communiceren, maar niet met de master .
- Het masterknooppunt kan geen transacties vastleggen omdat de semisynchrone replicatie bevestiging van ten minste één van de slaves verwacht voordat de master kan vastleggen. Tegelijkertijd sluit Pacemaker MySQL op het masterknooppunt af vanwege een gebrek aan quorum op basis van de Pacemaker-instelling 'no-quorum-policy =stop'. Quorum betekent hier een meerderheid van de knooppunten, of twee van de drie in een clusterconfiguratie met 3 knooppunten. Aangezien er slechts één masterknooppunt actief is in deze partitie van het cluster, wordt de instelling voor geen quorumbeleid geactiveerd, wat leidt tot het afsluiten van de MySQL-master.
- Nu detecteert Pacemaker op de partitie [(S1), (S2)] dat er geen master beschikbaar is in het cluster en start een promotieproces. Ervan uitgaande dat S1 up-to-date is met de master (zoals gegarandeerd door semisynchrone replicatie), wordt het dan gepromoot als de nieuwe master.
- Toepassingsverkeer wordt omgeleid naar deze nieuwe master MySQL-node en de slave S2 begint te repliceren vanaf de nieuwe master.
We zien dus dat het MySQL HA-framework split-brain-scenario's effectief afhandelt, waardoor zowel gegevensconsistentie als beschikbaarheid wordt gegarandeerd in het geval dat de netwerkverbinding tussen master- en slave-knooppunten wordt verbroken.
Dit besluit onze driedelige blogserie over het MySQL High Availability (HA)-framework met semi-synchrone replicatie en de Corosync plus Pacemaker-stack. Bij ScaleGrid bieden we zeer beschikbare hosting voor MySQL op AWS en MySQL op Azure die is geïmplementeerd op basis van de concepten die in deze blogserie worden uitgelegd. Bezoek de ScaleGrid Console voor een gratis proefversie van onze oplossingen.
