Hos Citymobil bruker vi en MySQL-database som vår viktigste vedvarende datalagring. Vi har flere databaseklynger for ulike tjenester og formål.

Den konstante tilgjengeligheten til masteren er en kritisk indikator på ytelsen til hele systemet og dets individuelle deler. Automatisk klyngegjenoppretting i tilfelle hovedfeil reduserer responstid og systemnedetid betraktelig. I denne artikkelen vil jeg se på et design med høy tilgjengelighet (HA) for en MySQL-klynge basert på MySQL Orchestrator og virtuelle IP-adresser (VIP).

HA-løsning basert på VIP

Først vil jeg kort fortelle deg hva datalagringssystemet vårt er.

Vi bruker et klassisk replikeringsskjema med én skrivetilgjengelig master og flere skrivebeskyttede replikaer. En klynge kan inneholde en mellomliggende master – en node som både er en replika og en master for andre. Klienter får tilgang til kopier gjennom HAProxy, som muliggjør jevn lastfordeling og enkel skalering. Bruken av HAProxy skyldes historiske årsaker, og vi er for tiden i ferd med å migrere til ProxySQL.

Replikering utføres i semi-synkron modus basert på GTID. Dette betyr at minst én replika må logge en transaksjon før den anses som vellykket. Denne replikeringsmodusen gir en optimal balanse mellom ytelse og datasikkerhet i tilfelle en masternodefeil. I utgangspunktet overføres alle endringer fra masteren til replikaene ved hjelp av Row Based Replication (RBR), men noen noder kan ha mixed binlog format.

Orkestratoren oppdaterer med jevne mellomrom tilstanden til klyngetopologien, analyserer informasjonen som mottas, og hvis det oppstår problemer, kan den starte en automatisk gjenopprettingsprosedyre. Utvikleren er ansvarlig for selve prosedyren, siden den kan implementeres på forskjellige måter: basert på VIP, DNS, ved hjelp av tjenesteoppdagingstjenester eller selvskrevne mekanismer.

En enkel måte å gjenopprette en master hvis den mislykkes, er å bruke flytende VIP-adresser.

Hva du trenger å vite om denne løsningen før du går videre:

• En VIP er en IP-adresse som ikke er knyttet til et spesifikt fysisk nettverksgrensesnitt. Hvis en node svikter eller under planlagt vedlikehold, kan vi bytte VIP-en til en annen ressurs med minimal nedetid.
• Å frigjøre og utstede en virtuell IP-adresse er en billig og rask operasjon.
• For å jobbe med VIP trenger du tilgang til serveren via SSH, eller bruk av spesielle verktøy, for eksempel, keepalived.

La oss se på mulige problemer med veiviseren vår og forestille oss hvordan den automatiske gjenopprettingsmekanismen skal fungere.

Nettverkstilkoblingen til masteren har forsvunnet, eller det har oppstått et problem på maskinvarenivå, og serveren er utilgjengelig

1. Orkestratoren oppdaterer klyngetopologien, hver replika rapporterer at masteren er utilgjengelig. Orkestratoren starter prosessen med å velge en replika som passer for rollen som den nye mesteren og begynner utvinningen.
2. Vi prøver å fjerne VIP-en fra den gamle mesteren - uten hell.
3. Replikaen bytter til rollen som mester. Topologien bygges opp igjen.
4. Legger til et nytt nettverksgrensesnitt med VIP. Siden det ikke var mulig å fjerne VIP-en, begynner vi med jevne mellomrom å sende en forespørsel i bakgrunnen gratis ARP. Denne typen forespørsel/svar lar deg oppdatere IP- og MAC-adressekartleggingstabellen på de tilkoblede svitsjene, og dermed varsle deg om at vår VIP har flyttet. Dette minimerer sannsynligheten split brain ved retur av den gamle mesteren.
5. Alle nye tilkoblinger blir umiddelbart omdirigert til den nye masteren. Gamle tilkoblinger mislykkes og gjentatte anrop til databasen gjøres på applikasjonsnivå.

Serveren fungerer i normal modus, en feil oppstod på DBMS-nivå

Algoritmen ligner på det forrige tilfellet: oppdatering av topologien og start av gjenopprettingsprosessen. Siden serveren er tilgjengelig, slipper vi VIP-en på den gamle masteren, overfører den til den nye og sender flere ARP-forespørsler. Den mulige returen av den gamle masteren bør ikke påvirke den gjenoppbygde klyngen og driften av applikasjonen.

Andre problemer

Feil på replikaer eller mellomliggende mastere fører ikke til automatiske handlinger og krever manuell inngripen.

Et virtuelt nettverksgrensesnitt legges alltid til midlertidig, det vil si at etter omstart av serveren tildeles ikke VIP automatisk. Hver databaseforekomst starter i skrivebeskyttet modus som standard, orkestratoren bytter automatisk den nye masteren til å skrive og prøver å installere read only på den gamle mesteren. Disse handlingene er rettet mot å redusere sannsynligheten split brain.

Det kan oppstå problemer under gjenopprettingsprosessen, som også bør varsles gjennom orkestratorens brukergrensesnitt i tillegg til standard overvåkingsverktøy. Vi har utvidet REST API ved å legge til denne funksjonen (PR under vurdering).

Det generelle diagrammet for HA-løsningen er presentert nedenfor.

Velge en ny mester

Orkestratoren er smart nok og prøver å velge den mest passende kopien som ny mester i henhold til følgende kriterier:

• kopien henger etter mesteren;
• MySQL-versjon av master og replika;
• replikasjonstype (RBR, SBR eller blandet);
• plassering i samme eller forskjellige datasentre;
• tilgjengelighet errant GTID — transaksjoner som ble utført på kopien og ikke er på masteren;
• tilpassede utvalgsregler tas også i betraktning.

Ikke alle signaler er en ideell kandidat for en master. For eksempel kan en replika brukes til å sikkerhetskopiere data, eller serveren har en svakere maskinvarekonfigurasjon. Orkester støtter manuelle regler som du kan tilpasse valg av kandidater fra mest foretrukket til ignorert.

Respons og restitusjonstid

I tilfelle en hendelse er det viktig å minimere systemets nedetid, så la oss vurdere MySQL-parametrene som påvirker opprettelsen og oppdateringen av klyngetopologien av orkestratoren:

• slave_net_timeout — antall sekunder replikaen venter på at nye data eller et hjerteslagsignal kommer fra masteren før tilkoblingen blir gjenkjent som tapt og koblet til igjen. Jo lavere verdi, jo raskere kan replikaen fastslå at kommunikasjonen med masteren er brutt. Vi setter denne verdien til 5 sekunder.
• MASTER_CONNECT_RETRY — antall sekunder mellom gjentilkoblingsforsøk. I tilfelle nettverksproblemer vil en lav verdi for denne parameteren tillate rask gjenoppretting og forhindre at klyngegjenopprettingsprosessen starter. Anbefalt verdi er 1 sekund.
• MASTER_RETRY_COUNT — maksimalt antall gjentilkoblingsforsøk.
• MASTER_HEARTBEAT_PERIOD — intervall i sekunder hvoretter masteren sender et hjerteslagsignal. Standard er halve verdien slave_net_timeout.

Orkesteralternativer:

• DelayMasterPromotionIfSQLThreadNotUpToDate - hvis lik true, så vil ikke masterrollen bli brukt på kandidatreplikaen før replikaens SQL-tråd har fullført alle ubrukte transaksjoner fra reléloggen. Vi bruker dette alternativet for å unngå å miste transaksjoner når alle kandidatreplikaer faller bak.
• InstancePollSeconds — hyppighet av bygging og oppdatering av topologien.
• RecoveryPollSeconds — hyppighet av topologianalyse. Hvis et problem oppdages, startes topologigjenoppretting. Dette konstant, lik 1 sekund.

Hver klyngennode blir spurt av orkestratoren en gang hver InstancePollSeconds sekunder Når et problem oppdages, tvinges klyngetilstanden oppdatert, og deretter tas den endelige avgjørelsen om å utføre gjenoppretting. Ved å eksperimentere med forskjellige database- og orkestratorparametere klarte vi å redusere respons- og gjenopprettingstiden til 30 sekunder.

Prøvestativ

Vi begynte å teste ut HA-ordningen med utvikling av en lokal test benk og videre implementering i test- og produksjonsmiljøer. Den lokale standen er helautomatisert basert på Docker og lar deg eksperimentere med konfigurasjonen av orkestratoren og nettverket, skalere klyngen fra 2-3 servere til flere dusin, og gjennomføre øvelser i et trygt miljø.

Under øvelsene velger vi en av problememuleringsmetodene: skyt øyeblikkelig mesteren ved hjelp av kill -9, avslutt sakte prosessen og stopp serveren (docker-compose stop), simuler nettverksproblemer ved å bruke iptables -j REJECT eller iptables -j DROP. Vi forventer følgende resultater:

• orkestratoren vil oppdage problemer med masteren og oppdatere topologien på ikke mer enn 10 sekunder;
• gjenopprettingsprosedyren starter automatisk: nettverkskonfigurasjonen vil endres, rollen til masteren vil overføres til replikaen, topologien vil bli gjenoppbygd;
• den nye masteren vil bli skrivbar, levende replikaer vil ikke gå tapt under gjenoppbyggingsprosessen;
• data vil begynne å bli skrevet til den nye masteren og replikert;
• Den totale gjenopprettingstiden vil ikke være mer enn 30 sekunder.

Som du vet, kan systemet oppføre seg annerledes i test- og produksjonsmiljøer på grunn av ulik maskinvare og nettverkskonfigurasjoner, forskjeller i syntetisk og reell belastning, etc. Derfor gjennomfører vi med jevne mellomrom øvelser under reelle forhold, og sjekker hvordan systemet oppfører seg når nettverkstilkoblingen går tapt eller dets individuelle deler blir forringet. I fremtiden ønsker vi å bygge en helt identisk infrastruktur for begge miljøene og automatisere testingen.

Funn

Helsen til hovedlagersystemnoden er en av hovedoppgavene til SRE og driftsteamet. Implementeringen av orkestratoren og HA-løsningen basert på VIP tillot oss å oppnå følgende resultater:

• pålitelig gjenkjenning av problemer med topologien til databaseklyngen;
• automatisk og rask respons på masterrelaterte hendelser, noe som reduserer nedetiden for systemet.

Løsningen har imidlertid sine begrensninger og ulemper:

• skalering av HA-ordningen til flere datasentre vil kreve et enkelt L2-nettverk mellom dem;
• Før vi tildeler VIP på den nye masteren, må vi frigi den på den gamle. Prosessen er sekvensiell, noe som øker gjenopprettingstiden;
• frigjøring av VIP krever SSH-tilgang til serveren, eller en hvilken som helst annen metode for å kalle eksterne prosedyrer. Siden serveren eller databasen har problemer som forårsaket gjenopprettingsprosessen, kan vi ikke være sikre på at VIP-fjerningen vil fullføres. Og dette kan føre til at det vises to servere med samme virtuelle IP-adresse og et problem split brain.

Å unngå split brain, kan du bruke metoden STONITH ("Skyt den andre noden i hodet"), som fullstendig isolerer eller deaktiverer problemnoden. Det er andre måter å implementere klyngehøy tilgjengelighet på: en kombinasjon av VIP og DNS, tjenesteoppdagelse og proxy-tjenester, synkron replikering og andre metoder som har sine egne ulemper og fordeler.

Jeg snakket om vår tilnærming til å lage en MySQL failover-klynge. Det er enkelt å implementere og gir et akseptabelt nivå av pålitelighet under gjeldende forhold. Etter hvert som hele systemet generelt og infrastruktur spesielt utvikler seg, vil denne tilnærmingen utvilsomt utvikle seg.

Kilde: www.habr.com