Automatiseret failover er stort set et must have for mange applikationer - oppetid tages for givet. Det er ret svært at acceptere, at en ansøgning er nede i 20 eller 30 minutter, fordi nogen skal søges for at logge ind og undersøge situationen, før der gribes ind.
I den virkelige verden har replikeringsopsætninger en tendens til at vokse over tid til at blive komplekse, nogle gange rodede. Og der er begrænsninger. For eksempel er ikke alle noder i en opsætning en god masterkandidat. Måske er hardwaren forskellig, og nogle af replikaerne har mindre kraftfuld hardware, da de er dedikeret til at håndtere nogle specifikke typer af arbejdsbyrden? Måske er du midt i migreringen til en ny MySQL-version, og nogle af slaverne er allerede blevet opgraderet? Du vil helst ikke have en master i nyere version, der replikerer til gamle replikaer, da dette kan bryde replikering. Hvis du har to datacentre, et aktivt og et til katastrofegendannelse, foretrækker du måske kun at vælge masterkandidater i det aktive datacenter for at holde masteren tæt på applikationsværterne. Det er blot eksempler på situationer, hvor du kan finde dig selv i behov for manuel indgriben under failover-processen. Heldigvis har mange failover-værktøjer mulighed for at tage kontrol over processen ved at bruge hvidlister og sortlister. I dette blogindlæg vil vi gerne vise dig nogle eksempler på, hvordan du kan påvirke ClusterControls algoritme til at vælge masterkandidater.
Konfiguration af hvidliste og sortliste
ClusterControl giver dig mulighed for at definere både hvidliste og sortliste over replikaer. En hvidliste er en liste over replikaer, som er beregnet til at blive masterkandidater. Hvis ingen af dem er tilgængelige (enten fordi de er nede, eller der er fejlagtige transaktioner, eller der er andre forhindringer, der forhindrer nogen af dem i at blive forfremmet), vil failover ikke blive udført. På denne måde kan du definere, hvilke værter der er tilgængelige til at blive masterkandidat. Sortlister definerer på den anden side, hvilke replikaer der ikke er egnede til at blive en masterkandidat.
Begge disse lister kan defineres i cmon-konfigurationsfilen for en given klynge. For eksempel, hvis din klynge har id'et '1', vil du redigere '/etc/cmon.d/cmon_1.cnf'. Til hvidliste vil du bruge variabelen 'replikation_failover_hvidliste', for sortliste vil det være en 'replikeringsfejl_sortliste'. Begge accepterer en kommasepareret liste over 'host:port'.
Lad os overveje følgende replikeringsopsætning. Vi har en aktiv master (10.0.0.141) som har to replikaer (10.0.0.142 og 10.0.0.143), begge fungerer som mellemliggende mastere og har en replika hver (10.0.0.144 og 10.0.0.147). Vi har også en standby-master i et separat datacenter (10.0.0.145), som har en replika (10.0.0.146). Disse værter er beregnet til at blive brugt i tilfælde af en katastrofe. Replikaer 10.0.0.146 og 10.0.0.147 fungerer som backup-værter. Se skærmbilledet nedenfor.
Da det andet datacenter kun er beregnet til katastrofegendannelse, ønsker vi ikke, at nogen af disse værter skal promoveres som master. I værste fald vil vi handle manuelt. Det andet datacenters infrastruktur er ikke skaleret til størrelsen af produktionsdatacenteret (der er tre replikaer mindre i DR-datacentret), så der er behov for manuelle handlinger alligevel, før vi kan promovere en vært i DR-datacentret. Vi ønsker heller ikke, at en backup-replika (10.0.0.147) promoveres. Vi ønsker heller ikke, at en tredje replika i kæden skal hentes som en mester (selvom det kunne lade sig gøre med GTID).
Konfiguration af hvidliste
Vi kan konfigurere enten hvidliste eller sortliste for at sikre, at failover vil blive håndteret efter vores smag. I denne særlige opsætning kan brug af hvidliste være mere egnet - vi vil definere, hvilke værter der kan bruges til failover, og hvis nogen tilføjer en ny vært til opsætningen, vil den ikke blive taget i betragtning som masterkandidat, før nogen manuelt beslutter, at det er ok at bruge det og tilføje det til hvidlisten. Hvis vi brugte sortliste, kunne tilføjelse af en ny replika et sted i kæden betyde, at en sådan replika teoretisk kunne bruges automatisk til failover, medmindre nogen udtrykkeligt siger, at den ikke kan bruges. Lad os blive på den sikre side og definere en hvidliste i vores klyngekonfigurationsfil (i dette tilfælde er det /etc/cmon.d/cmon_1.cnf, da vi kun har én klynge):
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306Vi skal sikre os, at cmon-processen er blevet genstartet for at anvende ændringer:
service cmon restartLad os antage, at vores master er gået ned og ikke kan nås af ClusterControl. Et failover-job vil blive påbegyndt:
Topologien vil se ud som nedenfor:
Som du kan se, er den gamle master deaktiveret, og ClusterControl vil ikke forsøge at gendanne den automatisk. Det er op til brugeren at kontrollere, hvad der er sket, kopiere alle data, som måske ikke er blevet replikeret til masterkandidaten og genopbygge den gamle master:
Så er det et spørgsmål om nogle få topologiændringer, og vi kan bringe topologien til den oprindelige tilstand, blot erstatte 10.0.0.141 med 10.0.0.142:
Konfiguration af sortliste
Nu skal vi se, hvordan sortlisten fungerer. Vi nævnte, at det i vores eksempel måske ikke er den bedste mulighed, men vi vil prøve det for illustrationens skyld. Vi sortlister alle værter undtagen 10.0.0.141, 10.0.0.142 og 10.0.0.143, da det er de værter, vi ønsker at se som masterkandidater.
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306Vi genstarter også cmon-processen for at anvende konfigurationsændringer:
service cmon restartFailover-processen ligner. Igen, når hovednedbruddet er opdaget, starter ClusterControl et failover-job.
Når en replika måske ikke er en god masterkandidat
I dette korte afsnit vil vi gerne diskutere mere detaljeret nogle af de tilfælde, hvor du måske ikke ønsker at fremme en given replika til at blive en ny mester. Forhåbentlig vil dette give dig nogle ideer til de tilfælde, hvor du muligvis skal overveje at fremkalde mere manuel kontrol af failover-processen.
Anden MySQL-version
For det første, hvis din replika bruger en anden MySQL-version end masteren, er det ikke en god idé at promovere den. Generelt er en nyere version altid en no-go, da replikering fra den nye til den gamle MySQL-version ikke understøttes og muligvis ikke fungerer korrekt. Dette er for det meste relevant for større versioner (for eksempel 8.0 replikerende til 5.7), men den gode praksis er at undgå denne opsætning helt, selvom vi taler om små versionsforskelle (5.7.x+1 -> 5.7.x). Replikering fra lavere til højere/nyere version er understøttet, da det er et must for opgraderingsprocessen, men alligevel vil du helst undgå dette (hvis din master f.eks. er på 5.7.x+1, vil du helst ikke erstatte den med en replika på 5.7.x).
Forskellige roller
Du kan tildele forskellige roller til dine replikaer. Du kan vælge en af dem til at være tilgængelig for udviklere til at teste deres forespørgsler på et produktionsdatasæt. Du kan bruge en af dem til OLAP-arbejdsbelastning. Du kan bruge en af dem til sikkerhedskopiering. Lige meget hvad det er, vil du typisk ikke ønsker at fremme en sådan replika for at mestre. Alle disse ekstra, ikke-standardiserede arbejdsbelastninger kan forårsage ydeevneproblemer på grund af den ekstra overhead. Et godt valg for en masterkandidat er en replika, som håndterer "normal" belastning, mere eller mindre samme type belastning som den nuværende master. Du kan så være sikker på, at den vil håndtere masterbelastningen efter failover, hvis den håndterede den før det.
Forskellige hardwarespecifikationer
Vi nævnte forskellige roller for replikaer. Det er ikke ualmindeligt også at se forskellige hardwarespecifikationer, især i forbindelse med forskellige roller. For eksempel behøver en backup-slave højst sandsynligt ikke at være så stærk som en almindelig replika. Udviklere kan også teste deres forespørgsler på en langsommere database end produktionen (mest fordi du ikke ville forvente det samme niveau af samtidighed på udviklings- og produktionsdatabasen), og for eksempel kan CPU-kerneantal reduceres. Disaster recovery-opsætninger kan også blive reduceret i størrelse, hvis deres hovedrolle er at følge med replikeringen, og det forventes, at DR-opsætningen skal skaleres (både vertikalt, ved at dimensionere forekomsten og vandret, ved at tilføje flere replikaer) før trafikken kan omdirigeres til den.
Forsinkede replikaer
Nogle af replikaerne kan være forsinkede - det er en meget god måde at reducere genoprettelsestiden på, hvis data er gået tabt, men det gør dem til meget dårlige mesterkandidater. Hvis en replika er forsinket med 30 minutter, vil du enten miste de 30 minutters transaktioner, eller også skal du vente (sandsynligvis ikke 30 minutter, da replikaen højst sandsynligt kan indhente det hurtigere) på, at replikaen anvender alle forsinkede transaktioner. ClusterControl giver dig mulighed for at vælge, om du vil vente, eller om du vil failover med det samme, men dette ville fungere ok for en meget lille forsinkelse - højst ti sekunder. Hvis failover skal tage minutter, nytter det bare ikke noget at bruge sådan en replika, og derfor er det en god idé at blackliste den.
Andet datacenter
Vi nævnte nedskalerede DR-opsætninger, men selvom dit andet datacenter er skaleret til produktionsstørrelsen, kan det stadig være en god idé kun at holde failovers inden for en enkelt DC. Til at begynde med kan dine aktive applikationsværter være placeret i hoveddatacentret, så flytning af masteren til en standby-DC ville øge latensen for skriveforespørgsler betydeligt. I tilfælde af en netværksdeling kan du også ønske at håndtere denne situation manuelt. MySQL har ikke en quorum-mekanisme indbygget, derfor er det lidt vanskeligt at håndtere korrekt (på en automatisk måde) netværkstab mellem to datacentre.