Ĉiu granda projekto komenciĝis per kelkaj serviloj. Komence ekzistis unu DB-servilo, tiam sklavoj estis aldonitaj al ĝi por skali la legadon. Kaj tiam — haltu! Estas unu mastro, sed estas multaj sklavoj; se unu el la sklavoj foriras, tiam ĉio estos en ordo, sed se la mastro foriros, estos malbona: malfunkcio, administrantoj provas altigi la servilon. Kion fari? Rezervu majstron. Mia kolego Pavel jam skribis pri tio , mi ne ripetos ĝin. Anstataŭe, mi diros al vi kial vi certe bezonas Orchestrator por MySQL!
Ni komencu per la ĉefa demando: "Kiel ni ŝanĝos la kodon al nova maŝino kiam la majstro foriros?"
- Mi plej ŝatas la skemon kun VIP (Virtuala IP), ni parolos pri ĝi sube. Ĝi estas la plej simpla kaj evidenta, kvankam ĝi havas evidentan limigon: la majstro, kiun ni rezervos, devas esti en la L2-segmento kun la nova maŝino, tio estas, ni povas forgesi pri la dua DC. Kaj, amikeme, se vi sekvas la regulon, ke granda L2 estas malbona, ĉar L2 estas nur po rako, kaj L3 estas inter la rako, kaj tia skemo havas eĉ pli da limigoj.
- Vi povas skribi DNS-nomon en la kodo kaj solvi ĝin per /etc/hosts. Fakte, ne estos rezolucio. La avantaĝo de la skemo: ne ekzistas limigo karakterizaĵo de la unua metodo, tio estas, eblas organizi kruc-DC. Sed tiam aperas la evidenta demando: kiom rapide ni povas liveri la ŝanĝon al /etc/hosts per Puppet-Ansible?
- Vi povas iomete ŝanĝi la duan metodon: instali kaŝmemoron DNS sur ĉiuj retserviloj, per kiuj la kodo iros al la majstra datumbazo. Vi povas agordi TTL 60 por ĉi tiu eniro en DNS. Ŝajnas ke se efektivigita ĝuste, la metodo estas bona.
- Skemo kun serva malkovro, implicante la uzon de Konsulo kaj ktp.
- Interesa opcio kun . Vi devas direkti la tutan trafikon al MySQL per ProxySQL; ProxySQL mem povas determini kiu estas la mastro. Cetere, vi povas legi pri unu el la ebloj por uzi ĉi tiun produkton en mia .
La verkinto de Orchestrator, laboranta en Github, unue efektivigis la unuan skemon kun VIP, kaj tiam konvertis ĝin al skemo kun konsulo.
Tipa infrastruktura aranĝo:
Mi tuj priskribos la evidentajn situaciojn, kiujn oni devas konsideri:
- La VIP-adreso ne estu registrita en la agordo de iu ajn el la serviloj. Ni imagu situacion: la majstro rekomencis, kaj dum ĝi ŝargis, Orchestrator iris en malsukcesan reĝimon kaj faris unu el la sklavoj majstro; tiam leviĝis la maljuna mastro, kaj nun la VIP estas sur du aŭtoj. Ĉi tio estas malbona.
- Por la orkestro, vi devos skribi skripton por voki la malnovan majstron kaj la novan majstron. Sur la malnova majstro vi devas ruli ifdown, kaj sur la nova majstro - ifup vip. Estus bone ankaŭ inkluzivi en ĉi tiu skripto, ke en kazo de malsukceso, la haveno sur la ŝaltilo de la malnova majstro estas simple malŝaltita por eviti ajnan splitcerbon.
- Post kiam Orchestrator vokis vian skripton por unue forigi la VIP kaj/aŭ estingi la havenon sur la ŝaltilo, kaj poste vokis la VIP-levigan skripton sur la nova majstro, ne forgesu uzi la arpingan komandon por diri al ĉiuj, ke la nova VIP nun estas. ĉi tie.
- Ĉiuj sklavoj devus havi read_only=1, kaj tuj kiam vi promocias la sklavon al la mastro, ĝi devus havi read_only=0.
- Ne forgesu, ke iu ajn sklavo, kiun ni elektis por ĉi tio, povas fariĝi majstro (Orkestranto havas tutan prefermekanismon por kiun sklavon konsideri kiel kandidaton por nova majstro en la unua loko, kiu en la dua loko, kaj kiu sklavo devus konsideri. tute ne estu elektita majstro). Se la sklavo fariĝas mastro, tiam la ŝarĝo de la sklavo restos sur ĝi kaj la ŝarĝo de la mastro estos aldonita, tion oni devas konsideri.
Kial vi bezonas Orchestrator se vi ne havas tian?
- Orchestrator havas tre afablan grafikan interfacon, kiu montras la tutan topologion (vidu ekrankopion sube).
- Orchestrator povas spuri kiuj sklavoj postrestis, kaj kie reproduktado ĝenerale rompiĝis (ni havas skriptojn alkroĉitajn al Orchestrator por sendi SMS).
- Orchestrator diras al vi, kiuj sklavoj havas GTID-eraranton.
Interfaco de orkestro:
Kio estas GTID erara?
Estas du ĉefaj postuloj por ke Orchestrator funkciu:
- Necesas, ke pseŭdo GTID estas ebligita sur ĉiuj maŝinoj en la MySQL-grupo; ni havas GTID ebligita.
- Necesas, ke ĉie estu unu speco de binlogs, vi povas uzi deklaron. Ni havis agordon en kiu la mastro kaj plej multaj sklavoj havis Row, kaj du historie restis en la Miksita reĝimo. Kiel rezulto, Orchestrator simple ne volis ligi ĉi tiujn sklavojn al la nova majstro.
Memoru, ke la plej grava afero en produktadsklavo estas ĝia konsistenco kun la mastro! Se vi havas Tutmondan Transakcian ID (GTID) ebligita sur kaj via majstro kaj sklavo, tiam vi povas uzi la funkcion gtid_subset por ekscii ĉu la samaj petoj pri datumŝanĝoj efektive estis efektivigitaj sur ĉi tiuj maŝinoj. Vi povas legi pli pri ĉi tio .
Tiel, Orchestrator montras al vi tra la GTID-eraro, ke ekzistas transakcioj sur la sklavo, kiuj ne estas sur la majstro. Kial ĉi tio okazas?
- Read_only=1 ne estas ebligita ĉe la sklavo, iu konektis kaj kompletigis peton por ŝanĝi datumojn.
- Super_read_only=1 ne estas ebligita ĉe la sklavo, tiam la administranto, konfuzinte la servilon, eniris kaj efektivigis la peton tie.
- Se vi enkalkulis ambaŭ antaŭajn punktojn, tiam ekzistas unu plia lertaĵo: en MySQL, peto por forfluigi binlogs ankaŭ iras al la binlog, do ĉe la unua fluado, GTID-eraro aperos sur la majstro kaj ĉiuj sklavoj. Kiel eviti ĉi tion? Perona-5.7.25-28 enkondukis la agordon binlog_skip_flush_commands=1, kiu malpermesas skribi flush al binlogs. Estas establita en la retejo mysql.com .
Lasu min resumi ĉion supre. Se vi ankoraŭ ne volas uzi Orchestrator en malsukcesa reĝimo, tiam metu ĝin en observan reĝimon. Tiam vi ĉiam havos antaŭ viaj okuloj mapon de la interago de MySQL-maŝinoj kaj vidajn informojn pri kia reproduktado estas sur ĉiu maŝino, ĉu la sklavoj postrestas, kaj plej grave, kiom konsekvencaj ili estas kun la mastro!
La evidenta demando estas: "Kiel devus funkcii Orchestrator?" Li devas elekti novan majstron el la nunaj sklavoj, kaj poste rekonekti ĉiujn sklavojn al ĝi (por tio necesas GTID; se vi uzas la malnovan mekanismon kun binlog_name kaj binlog_pos, tiam ŝanĝante sklavon de la nuna majstro al nova. estas simple neebla!). Antaŭ ol ni havis Orchestrator, mi iam devis fari ĉion ĉi permane. La maljuna majstro pendis pro kaleŝa Adaptec-regilo; ĝi havis proksimume 10 sklavojn. Mi bezonis translokigi VIP de la mastro al unu el la sklavoj kaj religi ĉiujn aliajn sklavojn al ĝi. Kiom da konzoloj mi devis malfermi, kiom da samtempaj komandoj mi enmetis... Mi devis atendi ĝis la 3-a matene, forigi la ŝarĝon de ĉiuj sklavoj krom du, fari la unuan maŝinon el du majstroj, tuj kunligi la duan maŝinon. al ĝi, do aligu ĉiujn aliajn sklavojn al la nova mastro kaj redonu la ŝarĝon. Ĝenerale, terura...
Kiel funkcias Orchestrator kiam ĝi iras en malsukcesan reĝimon? Tio estas plej facile ilustrita per ekzemplo de situacio kie ni volas igi majstron pli potenca, pli moderna maŝino ol ni havas nun.
La figuro montras la mezon de la procezo. Kio jam estis farita ĝis ĉi tiu punkto? Ni diris, ke ni volas fari iun sklavon la nova majstro, Orchestrator komencis simple rekonekti ĉiujn aliajn sklavojn al ĝi, kun la nova majstro agante kiel transitmaŝino. Kun ĉi tiu skemo, neniuj eraroj okazas, ĉiuj sklavoj funkcias, Orchestrator forigas la VIP de la malnova majstro, transdonas ĝin al la nova, faras read_only=0 kaj forgesas pri la malnova majstro. Ĉiuj! La malfunkcio de nia servo estas la VIP-transiga tempo, kiu estas 2-3 sekundoj.
Jen ĉio por hodiaŭ, dankon al ĉiuj. Baldaŭ aperos dua artikolo pri Orchestrator. En la fama sovetia filmo "Garage", unu rolulo diris: "Mi ne farus sciigon kun li!" Do, orkestro, mi akompanus vin pri rekono!
fonto: www.habr.com