I den här bloggserien i tre delar introducerade vi ett ramverk med hög tillgänglighet (HA) för MySQL-värd i del I, och diskuterade detaljerna om MySQL semisynkron replikering i del II. Nu i del III granskar vi hur ramverket hanterar några av de viktiga MySQL-felscenarierna och återställer för att säkerställa hög tillgänglighet.
MySQL-felscenarier
Scenario 1 – Master MySQL går ner
- Corosync och Pacemaker-ramverket upptäcker att master MySQL inte längre är tillgänglig. Pacemaker degraderar huvudresursen och försöker återställa med en omstart av MySQL-tjänsten, om möjligt.
- Vid denna tidpunkt, på grund av replikeringens semisynkrona karaktär, har alla transaktioner som begåtts på mastern tagits emot av minst en av slavarna.
- Pacemaker väntar tills alla mottagna transaktioner tillämpas på slavarna och låter slavarna rapportera sina kampanjresultat. Poängberäkningen görs på ett sådant sätt att poängen är '0' om en slav är helt synkroniserad med mastern och är ett negativt tal annars.
- Pacemaker väljer den slav som har rapporterat 0-poängen och främjar den slav som nu tar rollen som master MySQL där skrivning tillåts.
- Efter slavkampanj utlöser resursagenten en DNS-omdirigeringsmodul. Modulen uppdaterar proxy-DNS-posten med IP-adressen för den nya mastern, vilket gör det lättare att omdirigera alla programskrivningar till den nya mastern.
- Pacemaker ställer också in de tillgängliga slavarna för att börja replikera från denna nya master.
Alltså, när en master MySQL går ner (oavsett om det beror på en MySQL-krasch, OS-krasch, systemomstart, etc.), upptäcker vårt HA-ramverk det och främjar en lämplig slav till ta över rollen som mästare. Detta säkerställer att systemet fortsätter att vara tillgängligt för applikationerna.
#MySQL High Availability Framework Explained – Del III:Failure ScenariosClick To Tweet
Scenario 2 – Slave MySQL går ner
- Corosync och Pacemaker-ramverket upptäcker att slaven MySQL inte längre är tillgänglig.
- Pacemaker försöker återställa resursen genom att försöka starta om MySQL på noden. Om den dyker upp läggs den tillbaka till den nuvarande mastern som en slav och replikeringen fortsätter.
- Om återställningen misslyckas rapporterar Pacemaker att resursen är nere – baserat på vilka varningar eller meddelanden som kan genereras. Vid behov kommer ScaleGrid-supportteamet att hantera återställningen av denna nod.
- I det här fallet påverkas inte tillgängligheten av MySQL-tjänster.
Scenario 3 – Nätverkspartition – Nätverksanslutning går sönder mellan master- och slavnoder
Detta är ett klassiskt problem i alla distribuerade system där varje nod tror att de andra noderna är nere, medan det i verkligheten bara är nätverkskommunikationen mellan noderna som är bruten. Det här scenariot är mer känt som ett split-brain-scenario, och om det inte hanteras på rätt sätt kan det leda till att mer än en nod påstår sig vara en master MySQL, vilket i sin tur leder till datainkonsekvenser och korruption.
Låt oss använda ett exempel för att granska hur vårt ramverk hanterar scenarier med split-brain i klustret. Vi antar att klustret på grund av nätverksproblem har delats upp i två grupper – master i en grupp och 2 slavar i den andra gruppen, och vi kommer att beteckna detta som [(M), (S1,S2)].
- Corosync upptäcker att masternoden inte kan kommunicera med slavnoderna och slavnoderna kan kommunicera med varandra, men inte med mastern .
- Masternoden kommer inte att kunna utföra några transaktioner eftersom den semisynkrona replikeringen förväntar sig bekräftelse från minst en av slavarna innan mastern kan utföra. Samtidigt stänger Pacemaker av MySQL på masternoden på grund av brist på kvorum baserat på Pacemaker-inställningen 'no-quorum-policy =stop'. Quorum betyder här en majoritet av noderna, eller två av tre i en klusteruppsättning med tre noder. Eftersom det bara finns en huvudnod som körs i den här partitionen av klustret, utlöses inställningen för no-quorum-policy, vilket leder till att MySQL-mastern stängs av.
- Nu upptäcker Pacemaker på partitionen [(S1), (S2)] att det inte finns någon master tillgänglig i klustret och initierar en marknadsföringsprocess. Om vi antar att S1 är uppdaterad med mastern (vilket garanteras av semisynkron replikering), marknadsförs den sedan som den nya mastern.
- Programtrafik kommer att omdirigeras till denna nya master MySQL-nod och slaven S2 kommer att börja replikera från den nya mastern.
Därför ser vi att MySQL HA-ramverket hanterar scenarier med split-brain effektivt, vilket säkerställer både datakonsistens och tillgänglighet i händelse av att nätverksanslutningen bryter mellan master- och slavnoder.
Detta avslutar vår tredelade bloggserie om ramverket MySQL High Availability (HA) som använder semisynkron replikering och Corosync plus Pacemaker-stacken. På ScaleGrid erbjuder vi mycket tillgänglig hosting för MySQL på AWS och MySQL på Azure som implementeras baserat på koncepten som förklaras i denna bloggserie. Besök ScaleGrid-konsolen för en kostnadsfri provversion av våra lösningar.
