Ogni grande prughjettu hà cuminciatu cù un paru di servitori. À u primu ci era un servitore DB, dopu i schiavi sò stati aghjuntu à ellu per scala a lettura. E poi - ferma ! Ci hè un maestru, ma ci sò assai schiavi; se unu di i schiavi parte, allora tuttu sarà bè, ma se u maestru parte, serà male: downtime, l'amministratori cercanu di elevà u servitore. Chì fà ? Riserva un maestru. U mo cullegu Pavel hà digià scrittu annantu à questu , ùn ripeteraghju micca. Invece, vi dicu perchè avete bisognu di Orchestrator per MySQL!
Cuminciamu cù a quistione principale: "Cumu cambiemu u codice à una nova macchina quandu u maestru parte?"
- Mi piace u schema cù VIP (Virtual IP) u più, parlemu quì sottu. Hè u più simplice è più ovvi, ancu s'ellu hà una limitazione evidenti: u maestru chì riservàmu deve esse in u segmentu L2 cù a nova macchina, vale à dì, pudemu scurdà di a seconda DC. È, in una manera amichevule, se seguite a regula chì un grande L2 hè male, perchè L2 hè solu per rack, è L3 hè trà i racks, è un tali schema hà ancu più restrizioni.
- Pudete scrive un nome DNS in u codice è risolve per via /etc/hosts. In fatti, ùn ci sarà una risoluzione. U vantaghju di u schema: ùn ci hè micca una caratteristica di limitazione di u primu metudu, vale à dì, hè pussibule urganizà un cross-DC. Ma tandu sorge a quistione ovvia: quantu rapidamente pudemu furnisce u cambiamentu à /etc/hosts via Puppet-Ansible?
- Pudete cambià u sicondu mètudu un pocu: installate caching DNS in tutti i servitori web, attraversu quale u codice anderà à a basa di dati maestru. Pudete stabilisce TTL 60 per questa entrata in DNS. Sembra chì se implementatu currettamente, u metudu hè bonu.
- Un schema cù scuperta di serviziu, chì implica l'usu di Consul è etcd.
- Una opzione interessante cun . Avete bisognu di indirizzà tuttu u trafficu à MySQL attraversu ProxySQL; ProxySQL stessu pò determinà quale hè u maestru. In modu, pudete leghje circa una di l'opzioni per aduprà stu pruduttu in u mo .
L'autore di Orchestrator, chì travaglia in Github, hà implementatu prima u primu schema cù VIP, è poi l'hà cunvertitu in un schema cun consul.
Disposizione tipica di l'infrastruttura:
Descriveraghju immediatamente e situazioni evidenti chì deve esse cunsideratu:
- L'indirizzu VIP ùn deve esse registratu in a cunfigurazione in alcunu di i servitori. Imaginemu una situazione: u maestru rebooted, è mentre era carica, Orchestrator andò in modu di failover è hà fattu unu di i schiavi un maestru; allora u vechju maestru s'arrizzò, è avà u VIP hè nantu à dui vitture. Questu hè male.
- Per l'orchestratore, avete bisognu di scrive un script per chjamà u vechju maestru è u novu maestru. Nant'à u vechju maestru avete bisognu di eseguisce ifdown, è nantu à u novu maestru - ifup vip. Saria piacevule ancu include in questu script chì in casu di fallimentu, u portu nantu à l'interruttore di u vechju maestru hè simplicemente disattivatu per evità ogni splitbrain.
- Dopu chì Orchestrator hà chjamatu u vostru script per prima caccià u VIP è / o estingue u portu nantu à u switch, è dopu chjamatu u script di risuscitazione VIP nantu à u novu maestru, ùn vi scurdate di utilizà l'arping command per dì à tutti chì u novu VIP hè avà. quì.
- Tutti i schiavi duveranu avè read_only=1, è appena prumove l'esclave à u maestru, deve avè read_only=0.
- Ùn vi scurdate micca chì ogni schiavu chì avemu sceltu per questu pò diventà un maestru (Orchestrator hà un mecanismu di preferenza tutale per quale schiavu per cunsiderà cum'è candidatu per un novu maestru in u primu locu, chì in u sicondu locu, è quale schiavu duveria). ùn esse micca sceltu in ogni casu maestru). Se u slave diventa un maestru, allora a carica di u slave ferma nantu à questu è a carica di u maestru serà aghjuntu, questu deve esse cunsideratu.
Perchè avete bisognu di Orchestrator se ùn avete micca unu?
- Orchestrator hà una interfaccia grafica assai amichevule chì mostra tutta a topologia (vede a screenshot sottu).
- L'Orchestrator pò seguità quale schiavi sò in ritardo, è induve a replicazione hè generalmente rotta (avemu scripts attaccati à Orchestrator per mandà SMS).
- Orchestrator vi dice chì i schiavi anu un errant GTID.
Interfaccia Orchestrator:
Cosa hè GTID errant?
Ci hè dui requisiti principali per u travagliu di Orchestrator:
- Hè necessariu chì u pseudo GTID hè attivatu in tutte e macchine in u cluster MySQL; avemu GTID attivatu.
- Hè necessariu chì ci sia un tipu di binlogs in ogni locu, pudete aduprà dichjarazione. Avemu avutu una cunfigurazione in quale u maestru è a maiò parte di i schiavi avianu Row, è dui storicu restanu in u modu Mixed. In u risultatu, Orchestrator simpricimenti ùn vulia micca cunnette sti schiavi à u novu maestru.
Ricurdativi chì u più impurtante in un schiavu di produzzione hè a so cunsistenza cù u maestru! Se avete l'ID di Transazzione Globale (GTID) attivatu sia in u vostru maestru sia in u vostru schiavu, pudete aduprà a funzione gtid_subset per sapè se e stesse richieste di cambiamenti di dati sò state eseguite in queste macchine. Pudete leghje più nantu à questu .
Cusì, Orchestrator vi mostra à traversu u GTID errant chì ci sò transazzione nantu à u slave chì ùn sò micca nantu à u maestru. Perchè questu succede?
- Read_only=1 ùn hè micca attivatu nantu à u slave, qualcunu cunnessu è cumpletu una dumanda di cambià dati.
- Super_read_only=1 ùn hè micca attivatu nantu à u slave, allora l'amministratore, dopu avè cunfunditu u servitore, intrì è eseguitu a dumanda quì.
- Se tenete in contu i dui punti precedenti, allora ci hè un altru truccu: in MySQL, una dumanda di sguassate binlogs va ancu à u binlog, cusì à u primu flussu, un errant GTID appariscerà nantu à u maestru è tutti i schiavi. Cumu evità questu? Perona-5.7.25-28 hà introduttu u binlog_skip_flush_commands = 1 paràmetru, chì pruibisce di scrive flush à binlogs. Ci hè un stabilitu in u situ web mysql.com .
Lasciami riassume tuttu ciò chì sopra. Se ùn vulete micca aduprà Orchestrator in modu di failover, allora mette in modu di osservazione. Allora sempre averete davanti à i vostri ochji una mappa di l'interazzione di e macchine MySQL è l'infurmazione visuale nantu à quale tipu di replicazione hè nantu à ogni macchina, se i schiavi sò in ritardu, è più importantemente, quantu sò cunsistenti cù u maestru!
A quistione ovvia hè: "Cumu deve travaglià Orchestrator?" Ellu deve selezziunà un novu maestru da i schiavi attuali, è poi riconnettà tutti i schiavi à questu (questu hè ciò chì GTID hè necessariu; se aduprate u vechju mecanismu cù binlog_name è binlog_pos, allora cambiendu un slave da u maestru attuale à un novu. hè simplicemente impussibile!). Prima chì avemu avutu l'Orchestrator, una volta avia da fà tuttu questu manualmente. U vechju maestru era impiccatu per via di un controller Adaptec buggy; avia circa 10 schiavi. Aviu bisognu di trasfiriri VIP da u maestru à unu di i schiavi è ricunnisce tutti l'altri schiavi. Quante cunsola aghju avutu à apre, quante cumandamenti simultanee aghju intrutu ... Aviu avutu aspittà finu à 3 am, sguassate a carica da tutti i schiavi eccettu dui, fate a prima macchina da dui maestri, aghjunghje immediatamente a seconda macchina. à questu, cusì aghjunghje tutti l'altri schiavi à u novu maestru è rinvià a carica. In generale, terribili ...
Cumu funziona Orchestrator quandu entra in u modu di failover? Questu hè più facilmente illustratu da un esempiu di una situazione induve vulemu fà un maestru una macchina più putente è più moderna di ciò chì avemu avà.
A figura mostra a mità di u prucessu. Chì hè digià fattu finu à questu puntu? Avemu dettu chì vulemu fà un schiavu u novu maestru, Orchestrator hà cuminciatu à ricunnisce micca tutti l'altri schiavi, cù u novu maestru chì agisce cum'è una macchina di transitu. Cù stu schema, ùn accade micca errori, tutti i schiavi travaglianu, l'Orchestrator sguassate u VIP da u vechju maestru, u trasferisce à u novu, rende read_only = 0 è si scurda di u vechju maestru. Tuttu ! U downtime di u nostru serviziu hè u tempu di trasferimentu VIP, chì hè 2-3 seconde.
Hè tuttu per oghje, grazie à tutti. Ci sarà prestu un secondu articulu nantu à Orchestrator. In u famosu film sovièticu "Garage", un caratteru hà dettu: "Ùn avissi micca andà in ricunniscenza cun ellu!" Allora, orchestratore, andaraghju cun voi in ricunniscenza !
Source: www.habr.com