I denne tredelte blogserie vil vi forklare detaljerne og funktionaliteten af en High Availability (HA)-ramme til MySQL-hosting ved hjælp af MySQL semisynkron replikering og Corosync plus Pacemaker-stakken. I del I vil vi guide dig gennem det grundlæggende i High Availability, komponenterne i en HA-ramme, og derefter introducere dig til HA-rammeværket til MySQL.
Hvad er høj tilgængelighed?
Tilgængeligheden af et computersystem er den procentdel af tid, dets tjenester er oppe i en periode. Det er generelt udtrykt som en serie af 9'ere. For eksempel viser tabellen nedenfor tilgængelighed og den tilsvarende nedetid målt over et år.
| Tilgængelighed % | Nedetid pr. år |
| 90 % ("one 9 “) | 36,53 dage |
| 99 % ("to 9'ere “) | 3,65 dage |
| 99,9 % ("tre 9'ere “) | 8,77 timer |
| 99,99 % ("fire 9'ere “) | 52,60 minutter |
| 99,999 % ("fem 9'ere “) | 5,26 minutter |
| 99,9999 % ("seks 9'ere “) | 31,56 sekunder |
Betydningen af High Availability varierer afhængigt af kravene til din applikation og virksomhed. For eksempel, hvis du ikke har råd til en nedetid på mere end et par minutter om året i din tjeneste, siger vi, at tjenesten skal have 99,999 % høj tilgængelighed.
Komponenter af et HA Framework
essensen af at være yderst tilgængelig er evnen til øjeblikkeligt at komme sig efter fejl, der kan ske i enhver del af et system. Der er fire meget essentielle komponenter i enhver HA-ramme, der skal arbejde sammen på en automatiseret måde for at muliggøre denne gendannelse. Lad os gennemgå disse komponenter i detaljer:
1. Redundans i infrastruktur og data
For at en tjeneste skal være yderst tilgængelig, er vi nødt til at sikre, at der er en redundans i infrastrukturhostingen samt en opdateret redundant kopi af data, som tjenesten bruger eller leverer. Dette fungerer som en standby-tjeneste, der er klar til at tage over, hvis den primære bliver påvirket af fejl.
2. Fejldetekterings- og korrektionsmekanisme
Det er ekstremt vigtigt straks at opdage eventuelle fejl i enhver del af det primære system, der kan påvirke dets tilgængelighed. Dette vil gøre det muligt for rammerne enten at tage korrigerende handlinger på det samme primære system eller failover tjenesterne til et standby-system.
3. Failover-mekanisme
Denne komponent håndterer ansvaret for at failover tjenesterne til din standby-infrastruktur. Bemærk venligst, at hvis der er flere redundante systemer tilgængelige, skal denne failover-mekanisme-komponent identificere det bedst egnede system blandt disse og promovere det som den primære tjeneste.
4. Applikations-/brugeromdirigeringsmekanisme
Når standby-systemerne har overtaget som det primære, sikrer denne komponent, at alle applikations- og brugerforbindelser begynder at ske med den nye primære.
MySQL High Availability Framework Forklaret - Del IClick To Tweet
HA Framework for MySQL
Baseret på ovenstående model bruger vi følgende HA-ramme til vores MySQL-hosting hos ScaleGrid:
- En 3-Node Master-Slave-opsætning, der bruger MySQL semisynkron replikering til at levere infrastruktur og dataredundans.
- Corosync plus Pacemaker-stakken giver fejlregistrering, korrektion og failover-mekanisme.
- En DNS-kortlægning eller virtuel IP-komponent til at levere applikationen og brugeromdirigeringsmekanismen.
Tjek nedenstående diagram for at visualisere softwarestakken i denne arkitektur:
Lad os gennemgå funktionaliteten af nogle af nøglekomponenterne i denne ramme.
-
Corosync
Corosync giver en kommunikationsramme for noderne med pålidelig meddelelsesoverførsel mellem dem. Den danner en klyngering af noder og holder styr på de noder, der slutter sig til og forlader klyngen gennem klyngemedlemskab. Corosync arbejder tæt sammen med Pacemaker for at kommunikere om nodernes tilgængelighed, så Pacemaker kan træffe passende beslutninger.
-
Pacemaker
Også kendt som Cluster Resource Manager (CRM), sikrer Pacemaker den høje tilgængelighed for MySQL, der kører på klyngen, og registrerer og håndterer fejl på nodeniveau ved at interface med Corosync. Den registrerer og håndterer også fejl i MySQL ved at interface med Resource Agent (RA). Pacemaker konfigurerer og administrerer MySQL-ressourcen gennem start, stop, overvågning, promovering og nedrykning.
-
Ressourceagent
Resource Agenten fungerer som en grænseflade mellem MySQL og Pacemaker. Den implementerer start, stop, fremme, degradere og overvåge operationer, der påkaldes af pacemakeren. Der er en fuldt funktionel ressourceagent kaldet Percona Replication Manager (PRM) til MySQL implementeret af Percona. Dette er blevet forbedret af ScaleGrid og er tilgængeligt på vores GitHub-side.
-
DNS-kortlægningskomponent
Resource-agenten kalder, efter at have fuldført en vellykket failover, denne komponent, som opdaterer master-MySQL-serverens DNS-poster med IP-adressen på den nye master. Bemærk, at klienter altid bruger et master DNS-navn til at oprette forbindelse til MySQL-serveren, og ved at administrere tilknytningen af dette DNS-navn til IP-adressen på den aktuelle master, kan vi sikre, at klienter ikke skal ændre deres forbindelsesstrenge eller egenskaber, når der er en failover.
I del II af denne blogserie lærer du om den kritiske dataredundanskomponent, som opnås ved hjælp af MySQL semisynkron replikering. Vi vil også dykke dybt ned i de semisynkrone replikeringsdetaljer og konfigurationer, som vi bruger til at opnå vores høje tilgængelighedsunderstøttelse, og til sidst gennemgår vi forskellige fejlscenarier i del III og den måde, som rammeværket reagerer på og genopretter efter disse forhold.
