I den här bloggserien i tre delar kommer vi att förklara detaljerna och funktionaliteten i ett ramverk med hög tillgänglighet (HA) för MySQL-värd som använder MySQL semisynkron replikering och Corosync plus Pacemaker-stacken. I del I går vi igenom grunderna för High Availability, komponenterna i ett HA-ramverk, och introducerar dig sedan för HA-ramverket för MySQL.
Vad är hög tillgänglighet?
Tillgängligheten för ett datorsystem är den procentandel av tiden dess tjänster är uppe under en viss tidsperiod. Det uttrycks vanligtvis som en serie av 9:or. Tabellen nedan visar till exempel tillgänglighet och motsvarande stilleståndstid mätt över ett år.
| Tillgänglighet % | Nedtid per år |
| 90 % ("en 9 ") | 36,53 dagar |
| 99 % ("två 9:or ") | 3,65 dagar |
| 99,9 % ("tre 9:or ") | 8,77 timmar |
| 99,99 % ("fyra 9:or ") | 52,60 minuter |
| 99,999 % ("fem 9:or ") | 5,26 minuter |
| 99,9999 % ("sex 9s ") | 31,56 sekunder |
Betydningen av High Availability varierar beroende på kraven i din applikation och din verksamhet. Om du till exempel inte har råd med en stilleståndstid på mer än några minuter per år i din tjänst, säger vi att tjänsten måste ha 99,999 % hög tillgänglighet.
Komponenter i ett HA-ramverk
Käran i att vara högt tillgänglig är förmågan att omedelbart återhämta sig från fel som kan inträffa i vilken del av ett system som helst. Det finns fyra mycket väsentliga komponenter i alla HA-ramverk som behöver arbeta tillsammans på ett automatiserat sätt för att möjliggöra denna återställningsbarhet. Låt oss granska dessa komponenter i detalj:
1. Redundans i infrastruktur och data
För att en tjänst ska vara högst tillgänglig måste vi se till att det finns en redundans i infrastrukturvärdskapet samt en uppdaterad redundant kopia av data som tjänsten använder eller tillhandahåller. Detta fungerar som en standby-tjänst som är redo att ta över om den primära skulle påverkas av fel.
2. Mekanism för feldetektering och korrigering
Det är extremt viktigt att omedelbart upptäcka eventuella fel i någon del av det primära systemet som kan påverka dess tillgänglighet. Detta gör det möjligt för ramverket att antingen vidta korrigerande åtgärder på samma primära system, eller failover tjänsterna till ett standbysystem.
3. Failover-mekanism
Denna komponent hanterar ansvaret för att överlåta tjänsterna till din standby-infrastruktur. Observera att om det finns flera redundanta system tillgängliga måste denna komponent för failover-mekanism identifiera det mest lämpliga systemet bland dessa och marknadsföra det som den primära tjänsten.
4. Applikations-/användaromdirigeringsmekanism
När standbysystemen har tagit över som det primära, säkerställer den här komponenten att alla program- och användaranslutningar börjar ske med den nya primära.
MySQL High Availability Framework Explained - Del IClick To Tweet
HA-ramverket för MySQL
Baserat på ovanstående modell använder vi följande HA-ramverk för vår MySQL-hosting hos ScaleGrid:
- En 3-Node Master-Slave-installation som använder MySQL semisynkron replikering för att tillhandahålla infrastruktur och dataredundans.
- Corosync plus Pacemaker-stacken för att tillhandahålla feldetektering, korrigering och felmekanism.
- En DNS-mappning eller virtuell IP-komponent för att tillhandahålla applikationen och användarens omdirigeringsmekanism.
Kolla in diagrammet nedan för att visualisera programvarustapeln för denna arkitektur:
Låt oss se över funktionen hos några av nyckelkomponenterna i detta ramverk.
-
Corosync
Corosync tillhandahåller ett kommunikationsramverk för noderna med tillförlitlig meddelandeöverföring mellan dem. Den bildar en klusterring av noder och håller reda på noderna som går med i och lämnar klustret genom klustermedlemskap. Corosync har ett nära samarbete med Pacemaker för att kommunicera om nodens tillgänglighet så att Pacemaker kan fatta lämpliga beslut.
-
Pacemaker
Även känd som Cluster Resource Manager (CRM), säkerställer Pacemaker hög tillgänglighet för MySQL som körs på klustret och upptäcker och hanterar fel på nodnivå genom att samverka med Corosync. Den upptäcker och hanterar även fel i MySQL genom gränssnitt med resursagenten (RA). Pacemaker konfigurerar och hanterar MySQL-resursen genom att starta, stoppa, övervaka, främja och sänka operationer.
-
Resursagent
Resursagenten fungerar som ett gränssnitt mellan MySQL och Pacemaker. Den implementerar start, stopp, främja, nedgradera och övervaka operationer som anropas av pacemakern. Det finns en fullt fungerande resursagent som heter Percona Replication Manager (PRM) för MySQL implementerad av Percona. Detta har förbättrats av ScaleGrid och är tillgängligt på vår GitHub-sida.
-
DNS-mappningskomponent
Resursagenten, efter att ha slutfört en lyckad failover, anropar denna komponent som uppdaterar DNS-posterna för master MySQL-servern med IP-adressen för den nya mastern. Observera att klienter alltid använder ett master-DNS-namn för att ansluta till MySQL-servern, och genom att hantera mappningen av detta DNS-namn till IP-adressen för den aktuella mastern kan vi säkerställa att klienter inte behöver ändra sina anslutningssträngar eller egenskaper när det finns en failover.
I del II av den här bloggserien kommer du att lära dig om den kritiska dataredundanskomponenten som uppnås med MySQL semisynkron replikering. Vi kommer också att dyka djupt in i de semisynkrona replikeringsdetaljerna och konfigurationerna som vi använder för att uppnå vårt stöd för hög tillgänglighet, och slutligen granska olika felscenarier i del III och hur ramverket reagerar och återställer sig från dessa tillstånd.
