I denne tredelte blogserie introducerede vi en High Availability (HA) Framework for MySQL-hosting i del I og diskuterede detaljerne i MySQL semisynkron replikering i del II. Nu i del III gennemgår vi, hvordan rammeværket håndterer nogle af de vigtige MySQL-fejlscenarier og genopretter for at sikre høj tilgængelighed.
MySQL-fejlscenarier
Scenarie 1 – Master MySQL går ned
- Corosync- og Pacemaker-rammerne registrerer, at master MySQL ikke længere er tilgængelig. Pacemaker degraderer masterressourcen og forsøger at genoprette med en genstart af MySQL-tjenesten, hvis det er muligt.
- På dette tidspunkt, på grund af replikeringens semisynkrone karakter, er alle transaktioner begået på masteren blevet modtaget af mindst én af slaverne.
- Pacemaker venter, indtil alle de modtagne transaktioner anvendes på slaverne og lader slaverne rapportere deres forfremmelsesscore. Scoreberegningen udføres på en sådan måde, at scoren er '0', hvis en slave er fuldstændig synkroniseret med masteren, og ellers er et negativt tal.
- Pacemaker vælger den slave, der har rapporteret 0-scoren, og promoverer den slave, som nu påtager sig rollen som master MySQL, hvorpå skrivning er tilladt.
- Efter slavepromovering udløser ressourceagenten et DNS-omdirigeringsmodul. Modulet opdaterer proxy-DNS-indgangen med IP-adressen på den nye master, hvilket gør det lettere at omdirigere alle applikationsskrivninger til den nye master.
- Pacemaker sætter også de tilgængelige slaver op til at begynde at replikere fra denne nye master.
Når en master MySQL går ned (uanset om det skyldes et MySQL-nedbrud, OS-nedbrud, systemgenstart osv.), registrerer vores HA-ramme det og promoverer en passende slave til overtage mesterens rolle. Dette sikrer, at systemet fortsat er tilgængeligt for applikationerne.
#MySQL High Availability Framework Forklaret – Del III:FejlscenarierKlik for at tweete
Scenarie 2 – Slave MySQL går ned
- Corosync- og Pacemaker-rammeværket registrerer, at slaven MySQL ikke længere er tilgængelig.
- Pacemaker forsøger at gendanne ressourcen ved at prøve at genstarte MySQL på noden. Hvis den dukker op, føjes den tilbage til den aktuelle master som en slave, og replikeringen fortsætter.
- Hvis gendannelse mislykkes, rapporterer Pacemaker, at ressourcen er nede – baseret på hvilke advarsler eller meddelelser, der kan genereres. Hvis det er nødvendigt, vil ScaleGrid-supportteamet håndtere gendannelsen af denne node.
- I dette tilfælde er der ingen indflydelse på tilgængeligheden af MySQL-tjenester.
Scenarie 3 – Netværkspartition – Netværksforbindelse går i stykker mellem master- og slaveknudepunkter
Dette er et klassisk problem i ethvert distribueret system, hvor hver node tror, at de andre noder er nede, mens det i virkeligheden kun er netværkskommunikationen mellem noderne, der er brudt. Dette scenarie er mere almindeligt kendt som et split-brain scenario, og hvis det ikke håndteres korrekt, kan det føre til, at mere end én node hævder at være en master MySQL, hvilket igen fører til datainkonsekvens og korruption.
Lad os bruge et eksempel til at gennemgå, hvordan vores framework håndterer split-brain-scenarier i klyngen. Vi antager, at klyngen på grund af netværksproblemer er opdelt i to grupper – master i den ene gruppe og 2 slaver i den anden gruppe, og vi vil betegne dette som [(M), (S1,S2)].
- Corosync registrerer, at masterknuden ikke er i stand til at kommunikere med slaveknuderne, og slavenoderne kan kommunikere med hinanden, men ikke med masteren .
- Masternoden vil ikke være i stand til at foretage transaktioner, da den semisynkrone replikering forventer bekræftelse fra mindst én af slaverne, før masteren kan forpligte sig. Samtidig lukker Pacemaker ned for MySQL på masterknudepunktet på grund af manglende quorum baseret på Pacemaker-indstillingen 'no-quorum-policy =stop'. Kvorum betyder her et flertal af noderne eller to ud af tre i en 3-node klyngeopsætning. Da der kun kører én masterknude i denne partition af klyngen, udløses indstillingen for no-quorum-politik, hvilket fører til nedlukning af MySQL-masteren.
- Nu registrerer Pacemaker på partitionen [(S1), (S2)], at der ikke er nogen master tilgængelig i klyngen og starter en forfremmelsesproces. Hvis det antages, at S1 er opdateret med masteren (som garanteret af semisynkron replikering), promoveres den derefter som den nye master.
- Applikationstrafik vil blive omdirigeret til denne nye master MySQL node, og slaven S2 vil begynde at replikere fra den nye master.
Således ser vi, at MySQL HA-rammeværket håndterer split-brain-scenarier effektivt, hvilket sikrer både datakonsistens og tilgængelighed i tilfælde af, at netværksforbindelsen går i stykker mellem master- og slaveknudepunkter.
Dette afslutter vores 3-delte blogserie om MySQL High Availability (HA) frameworket ved hjælp af semisynkron replikering og Corosync plus Pacemaker-stakken. Hos ScaleGrid tilbyder vi meget tilgængelig hosting til MySQL på AWS og MySQL på Azure, der er implementeret baseret på koncepterne forklaret i denne blogserie. Besøg venligst ScaleGrid-konsollen for en gratis prøveversion af vores løsninger.
