Orchestrator za MySQL: zakaj brez njega ne morete zgraditi projekta, odpornega na napake

Vsak velik projekt se je začel z nekaj strežniki. Sprva je bil en strežnik DB, nato pa so mu dodali podrejene, da so merili branje. In potem - nehaj! En gospodar je, a mnogo je sužnjev; če eden od sužnjev odide, potem bo vse v redu, če pa master odide, bo slabo: izpadi, admini poskušajo dvigniti strežnik. Kaj storiti? Rezervirajte mojstra. O tem je pisal že kolega Pavel статью, ne bom ponavljal. Namesto tega vam bom povedal, zakaj zagotovo potrebujete Orchestrator za MySQL!

Začnimo z glavnim vprašanjem: "Kako bomo kodo preklopili na nov stroj, ko master odide?"

• Najbolj mi je všeč shema z VIP (Virtual IP), o kateri bomo govorili spodaj. Je najenostavnejši in najbolj očiten, čeprav ima očitno omejitev: master, ki ga bomo rezervirali, mora biti pri novem stroju v segmentu L2, se pravi, da lahko pozabimo na drugi DC. In po prijateljski poti, če se držiš pravila, da je velik L2 zlo, ker je L2 samo na rack, L3 pa med regali, in ima taka shema še več omejitev.
• V kodo lahko zapišete ime DNS in ga razrešite prek /etc/hosts. Resolucije pravzaprav ne bo. Prednost sheme: ni nobenih omejitev, značilnih za prvo metodo, to je, da je mogoče organizirati navzkrižni DC. Toda potem se pojavi očitno vprašanje: kako hitro lahko dostavimo spremembo v /etc/hosts prek Puppet-Ansible?
• Drugo metodo lahko nekoliko spremenite: na vse spletne strežnike namestite predpomnilnik DNS, prek katerega bo koda šla v glavno bazo podatkov. Za ta vnos v DNS lahko nastavite TTL 60. Zdi se, da je metoda dobra, če jo izvajamo pravilno.
• Shema z odkrivanjem storitev, kar pomeni uporabo Consul in itd.
• Zanimiva možnost z ProxySQL. Ves promet morate usmeriti v MySQL prek ProxySQL; ProxySQL sam lahko določi, kdo je glavni. Mimogrede, o eni od možnosti uporabe tega izdelka lahko preberete v mojem članek.

Avtor Orchestratorja, ki dela v Githubu, je najprej implementiral prvo shemo z VIP, nato pa jo pretvoril v shemo s konzulom.

Tipična postavitev infrastrukture:

Takoj bom opisal očitne situacije, ki jih je treba upoštevati:

• VIP naslov ne sme biti registriran v konfiguraciji na nobenem strežniku. Predstavljajmo si situacijo: nadrejena enota se je znova zagnala in med nalaganjem je Orchestrator preklopil v način preklopa in enega od podrejenih enot postavil za nadrejenega; potem se je dvignil stari mojster, zdaj pa je VIP na dveh avtomobilih. To je slabo.
• Za orkestratorja boste morali napisati scenarij za klic starega in novega mojstra. Na starem masterju morate zagnati ifdown, na novem masterju pa ifup vip. Lepo bi bilo v ta skript vključiti tudi, da se v primeru preklopa vrata na starem glavnem stikalu preprosto izklopijo, da bi se izognili razcepu možganov.
• Potem ko je Orchestrator poklical vaš skript, da najprej odstrani VIP in/ali ugasne vrata na stikalu, nato pa je poklical skript za dvig VIP na novem masterju, ne pozabite uporabiti ukaza arping, da vsem poveste, da je novi VIP zdaj tukaj
• Vsi podrejeni bi morali imeti read_only=1 in takoj, ko povišate podrejenega v glavnega, bi moral imeti read_only=0.
• Ne pozabite, da lahko kateri koli suženj, ki smo ga za to izbrali, postane mojster (Orchestrator ima cel mehanizem preferenc za to, katerega sužnja naj obravnava kot kandidata za novega gospodarja na prvem mestu, katerega na drugem mestu in katerega sužnja naj v nobenem primeru ne sme biti izbran za mojstra). Če podrejeni postane glavni, bo obremenitev podrejenega ostala na njem in dodana bo obremenitev glavnega, to je treba upoštevati.

Zakaj potrebujete Orchestrator, če ga nimate?

• Orchestrator ima zelo uporabniku prijazen grafični vmesnik, ki prikazuje celotno topologijo (glejte spodnji posnetek zaslona).
• Orchestrator lahko sledi, kateri podrejeni zaostajajo in kje se je replikacija na splošno pokvarila (orchestratorju imamo priložene skripte za pošiljanje SMS-ov).
• Orchestrator vam pove, kateri sužnji imajo napačni GTID.

Vmesnik Orchestrator:

Kaj je napačni GTID?

Obstajata dve glavni zahtevi za Orchestrator delo:

• Potrebno je, da je psevdo GTID omogočen na vseh strojih v gruči MySQL; GTID imamo omogočen.
• Potrebno je, da je povsod ena vrsta binlogov, lahko uporabite statement. Imeli smo konfiguracijo, v kateri so glavni in večina podrejenih imeli vrstico, dva pa sta zgodovinsko ostala v mešanem načinu. Kot rezultat, Orchestrator preprosto ni želel povezati teh sužnjev z novim gospodarjem.

Ne pozabite, da je najpomembnejša stvar pri proizvodnem sužnju njegova skladnost z gospodarjem! Če imate globalni ID transakcije (GTID) omogočen na glavnem in podrejenem računalniku, lahko s funkcijo gtid_subset ugotovite, ali so bile iste zahteve za spremembe podatkov dejansko izvedene na teh računalnikih. Več o tem si lahko preberete tukaj.

Tako vam Orchestrator prek napake GTID pokaže, da obstajajo transakcije na podrejeni napravi, ki jih ni na glavni. Zakaj se to dogaja?

• Read_only=1 ni omogočen na podrejeni napravi, nekdo se je povezal in dokončal zahtevo za spremembo podatkov.
• Super_read_only=1 ni omogočen na podrejeni strani, potem je skrbnik, ki je zmedel strežnik, vstopil in tam izvedel zahtevo.
• Če ste upoštevali obe prejšnji točki, potem obstaja še en trik: v MySQL gre tudi zahteva za izpiranje binlogov v binlog, tako da se bo ob prvem splakovanju na masterju in vseh podrejenih pojavil napaka GTID. Kako se temu izogniti? Perona-5.7.25-28 je uvedla nastavitev binlog_skip_flush_commands=1, ki prepoveduje pisanje flush v binlogs. Na spletnem mestu mysql.com je uveljavljeno hrošček.

Naj povzamem vse zgoraj našteto. Če Orchestratorja še ne želite uporabljati v samodejnem načinu, ga prestavite v način opazovanja. Potem boste vedno imeli pred očmi zemljevid interakcije strojev MySQL in vizualne informacije o tem, kakšna vrsta replikacije je na posameznem stroju, ali podrejeni zaostajajo, in kar je najpomembnejše, kako skladni so z glavnim!

Očitno vprašanje je: "Kako naj Orchestrator deluje?" Izbrati mora novega glavnega izmed trenutnih podrejenih in nato znova povezati vse podrejene nanj (temu je namenjen GTID; če uporabljate stari mehanizem z binlog_name in binlog_pos, potem preklop podrejenega s trenutnega glavnega na novega ena je preprosto nemogoča!). Preden smo imeli Orchestrator, sem moral nekoč vse to narediti ročno. Stari mojster je visel zaradi hroščastega Adaptec krmilnika, imel je cca 10 sužnjev. Moral sem prenesti VIP z glavnega na enega od podrejenih in nanj znova povezati vse druge podrejene. Koliko konzol sem moral odpreti, koliko sočasnih ukazov sem vnesel ... Moral sem počakati do 3 ure zjutraj, odstraniti obremenitev z vseh podrejenih razen dveh, prvi stroj od dveh narediti za glavnega, takoj priključiti drugi stroj nanj, zato priključite vse druge podrejene na novega gospodarja in vrnite breme. Na splošno, grozno ...

Kako Orchestrator deluje, ko preklopi v samodejni način? To najlažje ponazorimo s primerom situacije, ko želimo iz mastera narediti močnejši, modernejši stroj, kot ga imamo sedaj.

Slika prikazuje sredino procesa. Kaj je bilo do sedaj že narejenega? Rekli smo, da želimo nekega sužnja narediti za novega gospodarja, Orchestrator je začel preprosto znova povezovati vse druge sužnje, pri čemer je novi master deloval kot tranzitni stroj. Pri tej shemi ne pride do napak, vsi podrejeni delujejo, Orchestrator odstrani VIP iz starega masterja, ga prenese na novega, naredi read_only=0 in pozabi na starega masterja. Vse! Čas izpada naše storitve je čas VIP prenosa, ki znaša 2-3 sekunde.

To je vse za danes, hvala vsem. Kmalu bo drugi članek o Orchestratorju. V znamenitem sovjetskem filmu "Garaža" je en lik rekel: "Ne bi šel z njim v izvidnico!" Torej, orkestrator, jaz bi šel s teboj v izvidnico!

Vir: www.habr.com