Orchestrator for MySQL: hvorfor du ikke kan bygge et feiltolerant prosjekt uten det

Ethvert stort prosjekt startet med et par servere. Først var det én DB-server, så ble det lagt til slaver for å skalere lesingen. Og så - stopp! Det er én herre, men det er mange slaver; hvis en av slavene forlater, vil alt være bra, men hvis masteren forlater, vil det være dårlig: nedetid, administratorer prøver å heve serveren. Hva å gjøre? Reserver en mester. Min kollega Pavel har allerede skrevet om dette artikkel, jeg vil ikke gjenta det. I stedet skal jeg fortelle deg hvorfor du definitivt trenger Orchestrator for MySQL!

La oss starte med hovedspørsmålet: "Hvordan bytter vi koden til en ny maskin når masteren går?"

• Jeg liker best opplegget med VIP (Virtuell IP), vi vil snakke om det nedenfor. Det er den enkleste og mest åpenbare, selv om den har en åpenbar begrensning: masteren som vi vil reservere må være i L2-segmentet med den nye maskinen, det vil si at vi kan glemme den andre DC. Og på en vennskapelig måte, hvis du følger regelen om at en stor L2 er ond, fordi L2 bare er per stativ, og L3 er mellom stativene, og en slik ordning har enda flere begrensninger.
• Du kan skrive et DNS-navn i koden og løse det gjennom /etc/hosts. Faktisk blir det ingen løsning. Fordelen med ordningen: det er ingen begrensning som er karakteristisk for den første metoden, det vil si at det er mulig å organisere en kryss-DC. Men så oppstår det åpenbare spørsmålet: hvor raskt kan vi levere endringen til /etc/hosts via Puppet-Ansible?
• Du kan endre den andre metoden litt: installer caching DNS på alle webservere, der koden går til hoveddatabasen. Du kan angi TTL 60 for denne oppføringen i DNS. Det ser ut til at hvis den implementeres riktig, er metoden god.
• En ordning med tjenesteoppdagelse, som innebærer bruk av Consul og etcd.
• Et interessant alternativ med ProxySQL. Du må rute all trafikk til MySQL gjennom ProxySQL; ProxySQL kan selv bestemme hvem som er masteren. Du kan forresten lese om et av alternativene for å bruke dette produktet i min artikkel.

Forfatteren av Orchestrator, som jobber i Github, implementerte først den første ordningen med VIP, og konverterte den deretter til en ordning med konsul.

Typisk infrastrukturoppsett:

Jeg vil umiddelbart beskrive de åpenbare situasjonene som må tas i betraktning:

• VIP-adressen skal ikke registreres i konfigurasjonen på noen av serverne. La oss forestille oss en situasjon: masteren startet på nytt, og mens den lastet, gikk Orchestrator i failover-modus og gjorde en av slavene til master; så reiste den gamle mesteren seg, og nå er VIP-en på to biler. Dette er dårlig.
• For orkestratoren må du skrive et manus for å kalle den gamle mesteren og den nye mesteren. På den gamle masteren må du kjøre ifdown, og på den nye masteren – ifup vip. Det ville være fint å også inkludere i dette skriptet at i tilfelle en failover, blir porten på den gamle hovedbryteren ganske enkelt slått av for å unngå splitbrain.
• Etter at Orchestrator har kalt skriptet ditt for først å fjerne VIP-en og/eller slukke porten på bryteren, og deretter kalt VIP-hevingsskriptet på den nye masteren, ikke glem å bruke arping-kommandoen for å fortelle alle at den nye VIP-en er nå her.
• Alle slaver skal ha read_only=1, og så snart du promoterer slaven til masteren, skal den ha read_only=0.
• Ikke glem at enhver slave som vi har valgt for dette kan bli en mester (Orchestrator har en hel preferansemekanisme for hvilken slave som skal vurderes som en kandidat for en ny mester i første omgang, hvilken i andre omgang, og hvilken slave skal ikke velges i det hele tatt under noen omstendigheter master). Hvis slaven blir en master, vil belastningen til slaven forbli på den og belastningen til masteren vil bli lagt til, dette må tas i betraktning.

Hvorfor trenger du Orchestrator hvis du ikke har en?

• Orchestrator har et svært brukervennlig grafisk grensesnitt som viser hele topologien (se skjermbilde nedenfor).
• Orchestrator kan spore hvilke slaver som henger etter, og hvor replikering generelt har brutt sammen (vi har skript knyttet til Orchestrator for å sende SMS).
• Orchestrator forteller deg hvilke slaver som har en GTID feil.

Orchestrator Interface:

Hva er GTID feil?

Det er to hovedkrav for at Orchestrator skal fungere:

• Det er nødvendig at pseudo GTID er aktivert på alle maskiner i MySQL-klyngen; vi har GTID aktivert.
• Det er nødvendig at det er én type binlogs overalt, du kan bruke statement. Vi hadde en konfigurasjon der mesteren og de fleste slavene hadde rad, og to forble historisk i blandet modus. Som et resultat ønsket Orchestrator rett og slett ikke å koble disse slavene til den nye mesteren.

Husk at det viktigste i en produksjonsslave er dens konsistens med mesteren! Hvis du har Global Transaction ID (GTID) aktivert på både master og slave, kan du bruke gtid_subset-funksjonen for å finne ut om de samme forespørslene om dataendringer faktisk har blitt utført på disse maskinene. Du kan lese mer om dette her.

Dermed viser Orchestrator deg gjennom GTID-feilen at det er transaksjoner på slaven som ikke er på masteren. Hvorfor skjer dette?

• Read_only=1 er ikke aktivert på slaven, noen koblet til og fullførte en forespørsel om å endre data.
• Super_read_only=1 er ikke aktivert på slaven, så administratoren, etter å ha forvirret serveren, gikk inn og utførte forespørselen der.
• Hvis du tok hensyn til begge de foregående punktene, så er det ett triks til: i MySQL går en forespørsel om å tømme binlogs også til binloggen, så ved første flush vil en GTID-feil vises på masteren og alle slaver. Hvordan unngå dette? Perona-5.7.25-28 introduserte binlog_skip_flush_commands=1-innstillingen, som forbyr skriving av flush til binlogs. Det er en etablert en på mysql.com-nettstedet feil.

La meg oppsummere alt det ovennevnte. Hvis du ikke vil bruke Orchestrator i failover-modus ennå, sett den i observasjonsmodus. Da vil du alltid ha for øynene et kart over samspillet til MySQL-maskiner og visuell informasjon om hvilken type replikering som er på hver maskin, om slavene henger etter, og viktigst av alt, hvor konsistente de er med masteren!

Det åpenbare spørsmålet er: "Hvordan bør Orchestrator fungere?" Han må velge en ny master fra gjeldende slaver, og deretter koble alle slaver til den igjen (det er dette GTID er nødvendig for; hvis du bruker den gamle mekanismen med binlog_name og binlog_pos, så bytte en slave fra den nåværende masteren til en ny. er rett og slett umulig!). Før vi fikk Orchestrator, måtte jeg en gang gjøre alt dette manuelt. Den gamle masteren ble hengende på grunn av en buggy Adaptec-kontroller; den hadde omtrent 10 slaver. Jeg trengte å overføre VIP fra masteren til en av slavene og koble alle andre slaver til den igjen. Hvor mange konsoller måtte jeg åpne, hvor mange samtidige kommandoer skrev jeg inn... Jeg måtte vente til klokken 3, fjerne lasten fra alle slaver unntatt to, lage den første maskinen av to master, koble til den andre maskinen umiddelbart til den, så fest alle de andre slavene til den nye masteren og returner lasten. Alt i alt, forferdelig...

Hvordan fungerer Orchestrator når den går i failover-modus? Dette illustreres enklest ved et eksempel på en situasjon der vi ønsker å gjøre en mester til en kraftigere, mer moderne maskin enn vi har nå.

Figuren viser midten av prosessen. Hva har allerede blitt gjort frem til nå? Vi sa at vi ønsket å gjøre en eller annen slave til den nye mesteren, Orchestrator begynte ganske enkelt å koble alle andre slaver til den igjen, med den nye masteren som en transittmaskin. Med dette opplegget oppstår ingen feil, alle slaver fungerer, Orchestrator fjerner VIP-en fra den gamle masteren, overfører den til den nye, lager read_only=0 og glemmer den gamle masteren. Alle! Nedetiden for tjenesten vår er VIP-overføringstiden, som er 2-3 sekunder.

Det var alt for i dag, takk alle sammen. Det kommer en annen artikkel om Orchestrator snart. I den berømte sovjetiske filmen "Garage" sa en karakter: "Jeg ville ikke gå på rekognosering med ham!" Så, orkesterleder, jeg ville bli med deg på rekognosering!

Kilde: www.habr.com