In deze driedelige blogserie leggen we de details en functionaliteit uit van een High Availability (HA)-framework voor MySQL-hosting met behulp van MySQL semi-synchrone replicatie en de Corosync plus Pacemaker-stack. In deel I leiden we je door de basisprincipes van hoge beschikbaarheid, de componenten van een HA-framework, en laten we je kennismaken met het HA-framework voor MySQL.
Wat is hoge beschikbaarheid?
De beschikbaarheid van een computersysteem is het percentage van de tijd dat de services in een bepaalde periode beschikbaar zijn. Het wordt over het algemeen uitgedrukt als een reeks van 9′s. De onderstaande tabel toont bijvoorbeeld de beschikbaarheid en de bijbehorende uitvaltijd gemeten over een jaar.
| Beschikbaarheid % | Stilstand per jaar |
| 90% (“één 9 ") | 36,53 dagen |
| 99% ("twee 9s ") | 3,65 dagen |
| 99,9% ("drie 9s ") | 8,77 uur |
| 99,99% ("vier 9s ") | 52,60 minuten |
| 99,999% ("vijf 9s ") | 5,26 minuten |
| 99,9999% ("zes 9s ") | 31,56 seconden |
De betekenis van hoge beschikbaarheid is afhankelijk van de vereisten van uw toepassing en bedrijf. Als u zich bijvoorbeeld geen downtime van meer dan een paar minuten per jaar van uw service kunt veroorloven, zeggen we dat de service 99,999% hoge beschikbaarheid moet hebben.
Onderdelen van een HA-framework
De essentie van hoge beschikbaarheid is de mogelijkheid om onmiddellijk te herstellen van storingen die zich in elk deel van een systeem kunnen voordoen. Er zijn vier zeer essentiële componenten in elk HA-framework die op een geautomatiseerde manier moeten samenwerken om deze herstelbaarheid mogelijk te maken. Laten we deze componenten in detail bekijken:
1. Redundantie in infrastructuur en data
Om ervoor te zorgen dat een service maximaal beschikbaar is, moeten we ervoor zorgen dat er een redundantie is in de infrastructuurhosting en een up-to-date redundant kopie van gegevens die de service gebruikt of verstrekt. Dit fungeert als een standby-service die klaar is om het over te nemen in het geval dat de primaire wordt beïnvloed door storingen.
2. Foutdetectie- en correctiemechanisme
Het is uiterst belangrijk om eventuele storingen in een deel van het primaire systeem die van invloed kunnen zijn op de beschikbaarheid, onmiddellijk te detecteren. Hierdoor kan het raamwerk corrigerende maatregelen nemen op hetzelfde primaire systeem of de services overzetten naar een stand-bysysteem.
3. Failover-mechanisme
Dit onderdeel zorgt voor de verantwoordelijkheid voor het failoveren van de services naar uw stand-by-infrastructuur. Houd er rekening mee dat als er meerdere redundante systemen beschikbaar zijn, dit onderdeel van het failovermechanisme het meest geschikte systeem moet identificeren en dit als de primaire service moet promoten.
4. Applicatie/gebruikersomleidingsmechanisme
Zodra de standby-systemen het primaire systeem hebben overgenomen, zorgt dit onderdeel ervoor dat alle applicatie- en gebruikersverbindingen met het nieuwe primaire systeem worden uitgevoerd.
MySQL High Availability Framework uitgelegd - Deel IClick To Tweet
Het HA-framework voor MySQL
Op basis van het bovenstaande model gebruiken we het volgende HA-framework voor onze MySQL-hosting bij ScaleGrid:
- Een 3-Node Master-Slave setup die gebruik maakt van MySQL semi-synchrone replicatie om infrastructuur en dataredundantie te bieden.
- De Corosync plus Pacemaker-stack voor foutdetectie, correctie en failover-mechanisme.
- Een DNS-toewijzing of Virtual IP-component om het mechanisme voor het omleiden van applicaties en gebruikers te bieden.
Bekijk het onderstaande diagram om de softwarestack van deze architectuur te visualiseren:
Laten we eens kijken naar de functionaliteit van enkele van de belangrijkste componenten in dit raamwerk.
-
Corosync
Corosync biedt een communicatieraamwerk voor de knooppunten met betrouwbare berichtenuitwisseling tussen hen. Het vormt een clusterring van knooppunten en houdt de knooppunten bij die het cluster binnenkomen en verlaten via clusterlidmaatschap. Corosync werkt nauw samen met Pacemaker om te communiceren over de beschikbaarheid van de node, zodat Pacemaker de juiste beslissingen kan nemen.
-
Pacemaker
Ook bekend als Cluster Resource Manager (CRM), zorgt Pacemaker voor hoge beschikbaarheid voor MySQL die op het cluster wordt uitgevoerd en detecteert en verwerkt storingen op knooppuntniveau door te communiceren met Corosync. Het detecteert en behandelt ook fouten van MySQL door te communiceren met de Resource Agent (RA). Pacemaker configureert en beheert de MySQL-bron door middel van start-, stop-, monitor-, promotie- en degradatiebewerkingen.
-
Bronagent
De Resource Agent fungeert als een interface tussen MySQL en Pacemaker. Het implementeert start-, stop-, promotie-, degradatie- en bewakingsbewerkingen die worden aangeroepen door de pacemaker. Er is een volledig functionele Resource Agent genaamd Percona Replication Manager (PRM) voor MySQL, geïmplementeerd door Percona. Dit is verbeterd door ScaleGrid en is beschikbaar op onze GitHub-pagina.
-
DNS-toewijzingscomponent
De Resource Agent roept bij het voltooien van een succesvolle failover deze component aan die de DNS-records van de master MySQL-server bijwerkt met het IP-adres van de nieuwe master. Houd er rekening mee dat clients altijd een master-DNS-naam gebruiken om verbinding te maken met de MySQL-server, en door de toewijzing van deze DNS-naam aan het IP-adres van de huidige master te beheren, kunnen we ervoor zorgen dat clients hun verbindingsreeksen of eigenschappen niet hoeven te wijzigen wanneer er is een failover.
In deel II van deze blogreeks leert u over de essentiële gegevensredundantiecomponent die wordt bereikt met behulp van semi-synchrone MySQL-replicatie. We zullen ook diep ingaan op de details en configuraties van semi-synchrone replicatie die we gebruiken om onze ondersteuning voor hoge beschikbaarheid te bereiken, en tot slot bekijken we verschillende faalscenario's in Deel III en de manier waarop het framework reageert en herstelt van deze omstandigheden.
