Hos Citymobil bruger vi en MySQL-database som vores primære vedvarende datalagring. Vi har flere databaseklynger til forskellige tjenester og formål.

Masterens konstante tilgængelighed er en kritisk indikator for ydeevnen af ​​hele systemet og dets individuelle dele. Automatisk klyngendannelse i tilfælde af en masterfejl reducerer i høj grad hændelsens responstid og systemets nedetid. I denne artikel vil jeg se på et design med høj tilgængelighed (HA) til en MySQL-klynge baseret på MySQL Orchestrator og virtuelle IP-adresser (VIP).

HA-løsning baseret på VIP

Først vil jeg kort fortælle dig, hvad vores datalagringssystem er.

Vi bruger et klassisk replikeringsskema med én skrivetilgængelig master og flere skrivebeskyttede replikaer. En klynge kan indeholde en mellemliggende master - en node, der både er en replika og en master for andre. Klienter får adgang til replikaer gennem HAProxy, som giver mulighed for jævn belastningsfordeling og nem skalering. Brugen af ​​HAProxy skyldes historiske årsager, og vi er i øjeblikket i gang med at migrere til ProxySQL.

Replikering udføres i semi-synkron tilstand baseret på GTID. Det betyder, at mindst én replika skal logge en transaktion, før den anses for at være vellykket. Denne replikeringstilstand giver en optimal balance mellem ydeevne og datasikkerhed i tilfælde af en masterknudefejl. Grundlæggende overføres alle ændringer fra masteren til replikaerne vha Row Based Replication (RBR), men nogle noder kan have mixed binlog format.

Orkestratoren opdaterer med jævne mellemrum klyngetopologiens tilstand, analyserer den modtagne information, og hvis der opstår problemer, kan den starte en automatisk gendannelsesprocedure. Udvikleren er ansvarlig for selve proceduren, da den kan implementeres på forskellige måder: baseret på VIP, DNS, ved hjælp af serviceopdagelsestjenester eller selvskrevne mekanismer.

En enkel måde at gendanne en master, hvis den mislykkes, er at bruge flydende VIP-adresser.

Hvad du skal vide om denne løsning, før du går videre:

• En VIP er en IP-adresse, der ikke er knyttet til en bestemt fysisk netværksgrænseflade. Hvis en node fejler eller under planlagt vedligeholdelse, kan vi skifte VIP'en til en anden ressource med minimal nedetid.
• Frigivelse og udstedelse af en virtuel IP-adresse er en billig og hurtig operation.
• For at arbejde med VIP skal du have adgang til serveren via SSH eller brug af specielle hjælpeprogrammer, f.eks. keepalived.

Lad os se på mulige problemer med vores guide og forestille os, hvordan den automatiske gendannelsesmekanisme skal fungere.

Netværksforbindelsen til masteren er forsvundet, eller der er opstået et problem på hardwareniveau, og serveren er ikke tilgængelig

1. Orchestratoren opdaterer klyngetopologien, hver replika rapporterer, at masteren ikke er tilgængelig. Orkestratoren starter processen med at vælge en replika, der er egnet til rollen som den nye mester og begynder at genoprette.
2. Vi forsøger at fjerne VIP'en fra den gamle mester - uden held.
3. Replikaen skifter til rollen som mester. Topologien bliver genopbygget.
4. Tilføjelse af en ny netværksgrænseflade med VIP. Da det ikke var muligt at fjerne VIP'en, begynder vi med jævne mellemrum at sende en anmodning i baggrunden gratis ARP. Denne type anmodning/svar giver dig mulighed for at opdatere IP- og MAC-adressemapping-tabellen på de tilsluttede switches, og derved give dig besked om, at vores VIP er flyttet. Dette minimerer sandsynligheden split brain ved tilbagelevering af den gamle mester.
5. Alle nye forbindelser omdirigeres straks til den nye master. Gamle forbindelser mislykkes, og gentagne opkald til databasen foretages på applikationsniveau.

Serveren kører i normal tilstand, der opstod en fejl på DBMS-niveau

Algoritmen ligner det tidligere tilfælde: opdatering af topologien og start af gendannelsesprocessen. Da serveren er tilgængelig, frigiver vi VIP'en på den gamle master, overfører den til den nye og sender flere ARP-anmodninger. Den mulige tilbagevenden af ​​den gamle master bør ikke påvirke den genopbyggede klynge og applikationens drift.

Andre problemer

Fejl i replikaer eller mellemliggende mastere fører ikke til automatiske handlinger og kræver manuel indgriben.

En virtuel netværksgrænseflade tilføjes altid midlertidigt, det vil sige, efter en servergenstart tildeles VIP'en ikke automatisk. Hver databaseinstans starter i skrivebeskyttet tilstand som standard, orkestratoren skifter automatisk den nye master til at skrive og forsøger at installere read only på den gamle mester. Disse handlinger har til formål at reducere sandsynligheden split brain.

Der kan opstå problemer under gendannelsesprocessen, som også skal underrettes via orkestratorens brugergrænseflade ud over standardovervågningsværktøjer. Vi har udvidet REST API ved at tilføje denne funktion (PR i øjeblikket under revision).

Det generelle diagram af HA-løsningen er præsenteret nedenfor.

At vælge en ny mester

Orkestratoren er klog nok og prøver at vælge den bedst egnede kopi som ny mester efter følgende kriterier:

• replikken halter bagefter mesteren;
• MySQL-version af master og replika;
• replikationstype (RBR, SBR eller blandet);
• placering i samme eller forskellige datacentre;
• tilgængelighed errant GTID — transaktioner, der blev udført på replikaen og ikke er på masteren
• tilpassede udvælgelsesregler tages også i betragtning.

Ikke enhver cue er en ideel kandidat til en mester. For eksempel kan en replika bruges til at sikkerhedskopiere data, eller serveren har en svagere hardwarekonfiguration. Orkester bakker op manuelle regler, hvormed du kan tilpasse dine præferencer for kandidatudvælgelse fra mest foretrukket til ignoreret.

Respons og restitutionstid

I tilfælde af en hændelse er det vigtigt at minimere systemets nedetid, så lad os overveje de MySQL-parametre, der påvirker orkestratorens oprettelse og opdatering af klyngetopologien:

• slave_net_timeout — antallet af sekunder, hvor replikaen venter på, at der kommer nye data eller et hjerteslagsignal fra masteren, før forbindelsen genkendes som tabt og genoprettes. Jo lavere værdien er, jo hurtigere kan replikaen fastslå, at kommunikationen med masteren er brudt. Vi indstiller denne værdi til 5 sekunder.
• MASTER_CONNECT_RETRY — antal sekunder mellem genforbindelsesforsøg. I tilfælde af netværksproblemer vil en lav værdi for denne parameter tillade hurtig genforbindelse og forhindre klyngendannelsesprocessen i at starte. Den anbefalede værdi er 1 sekund.
• MASTER_RETRY_COUNT — maksimalt antal genforbindelsesforsøg.
• MASTER_HEARTBEAT_PERIOD — interval i sekunder, hvorefter masteren sender et hjerteslagssignal. Standard til halvdelen af ​​værdien slave_net_timeout.

Orchestrator parametre:

• DelayMasterPromotionIfSQLThreadNotUpToDate - hvis lige true, så vil masterrollen ikke blive anvendt på kandidatreplikaen, før replikaens SQL-tråd har gennemført alle ikke-anvendte transaktioner fra relæloggen. Vi bruger denne mulighed for at undgå at miste transaktioner, når alle kandidatreplikaer kommer bagud.
• InstancePollSeconds — hyppighed af opbygning og opdatering af topologien.
• RecoveryPollSeconds — hyppighed af topologianalyse. Hvis der opdages et problem, startes topologigendannelse. Det her konstant, lig med 1 sekund.

Hver klynge node bliver pollet af orkestratoren én gang hver InstancePollSeconds sekunder Når et problem opdages, tvinges klyngetilstanden opdateret, og derefter træffes den endelige beslutning om at udføre gendannelse. Ved at eksperimentere med forskellige database- og orkestratorparametre var vi i stand til at reducere respons- og gendannelsestiden til 30 sekunder.

Prøvestativ

Vi begyndte at teste HA-ordningen med udvikling af en lokal prøvebænk og yderligere implementering i test- og produktionsmiljøer. Den lokale stand er fuldautomatisk baseret på Docker og giver dig mulighed for at eksperimentere med konfigurationen af ​​orkestratoren og netværket, skalere klyngen fra 2-3 servere til flere dusin og udføre øvelser i et sikkert miljø.

Under øvelserne vælger vi en af ​​problememuleringsmetoderne: skyd øjeblikkeligt mesteren vha kill -9, afbryd forsigtigt processen og stop serveren (docker-compose stop), simulere netværksproblemer ved hjælp af iptables -j REJECT eller iptables -j DROP. Vi forventer følgende resultater:

• orkestratoren vil opdage problemer med masteren og opdatere topologien på ikke mere end 10 sekunder;
• gendannelsesproceduren starter automatisk: netværkskonfigurationen ændres, masterens rolle overføres til replikaen, topologien genopbygges;
• den nye master vil blive skrivbar, levende replikaer vil ikke gå tabt under genopbygningsprocessen;
• data vil begynde at blive skrevet til den nye master og replikeret;
• Den samlede restitutionstid vil ikke være mere end 30 sekunder.

Som du ved, kan systemet opføre sig anderledes i test- og produktionsmiljøer på grund af forskellige hardware- og netværkskonfigurationer, forskelle i syntetisk og reel belastning osv. Derfor udfører vi med jævne mellemrum øvelser under virkelige forhold, hvor vi tjekker, hvordan systemet opfører sig, når netværksforbindelsen mistes, eller dets individuelle dele forringes. I fremtiden ønsker vi at bygge en fuldstændig identisk infrastruktur til begge miljøer og automatisere dens test.

Fund

Sundheden for hovedlagersystemknudepunktet er en af ​​hovedopgaverne for SRE- og driftsteamet. Implementeringen af ​​orkestrator- og HA-løsningen baseret på VIP gjorde det muligt for os at opnå følgende resultater:

• pålidelig påvisning af problemer med databaseklyngens topologi;
• automatisk og hurtig reaktion på master-relaterede hændelser, hvilket reducerer systemets nedetid.

Løsningen har dog sine begrænsninger og ulemper:

• skalering af HA-ordningen til flere datacentre vil kræve et enkelt L2-netværk mellem dem;
• Før vi tildeler VIP på den nye master, skal vi frigive den på den gamle. Processen er sekventiel, hvilket øger restitutionstiden;
• frigivelse af VIP kræver SSH-adgang til serveren eller enhver anden metode til at kalde fjernprocedurer. Da serveren eller databasen oplever problemer, der forårsagede gendannelsesprocessen, kan vi ikke være sikre på, at VIP-fjernelsen fuldføres. Og dette kan føre til fremkomsten af ​​to servere med den samme virtuelle IP-adresse og et problem split brain.

At undgå split brain, kan du bruge metoden STONITH ("Skyd den anden knude i hovedet"), som fuldstændigt isolerer eller deaktiverer problemknuden. Der er andre måder at implementere klyngehøj tilgængelighed på: en kombination af VIP og DNS, serviceopdagelse og proxytjenester, synkron replikering og andre metoder, der har deres egne ulemper og fordele.

Jeg talte om vores tilgang til at skabe en MySQL failover-klynge. Det er nemt at implementere og giver et acceptabelt niveau af pålidelighed under de nuværende forhold. Efterhånden som hele systemet generelt og infrastrukturen i særdeleshed udvikler sig, vil denne tilgang uden tvivl udvikle sig.

Kilde: www.habr.com