Edozein proiektu handi zerbitzari pare batekin hasten zen. Hasieran DB zerbitzari bat zegoen, gero esklaboak gehitu zitzaizkion irakurketa eskalatzeko. Eta gero - gelditu! Nagusi bat dago, baina esklabo asko; esklaboetako bat alde egiten badu, dena ondo egongo da, baina maisua alde egiten badu, txarra izango da: geldialdi-denbora, administratzaileak zerbitzaria igotzen saiatzen ari dira. Zer egin? Erreserbatu master bat. Nire lankideak Pavel jada idatzi zuen honi buruz , ez dut errepikatuko. Horren ordez, esango dizut zergatik behar duzun zalantzarik gabe Orchestrator MySQLrako!
Has gaitezen galdera nagusitik: "Nola aldatuko dugu kodea makina berri batera maisua uzten duenean?"
- VIP (IP birtuala) eskema gustatzen zait gehien, jarraian hitz egingo dugu horretaz. Errazena eta agerikoena da, muga nabaria duen arren: erreserbatuko dugun maisuak L2 segmentuan egon behar du makina berriarekin, hau da, bigarren DCaz ahaztu gaitezke. Eta, modu adiskidetsuan, L2 handi bat gaiztoa dela dioen araua jarraitzen baduzu, L2 bastidore bakoitzeko bakarrik delako, eta L3 bastidoreen artean dagoelako, eta eskema horrek are murrizketa gehiago ditu.
- DNS izen bat idatzi dezakezu kodean eta ebatzi /etc/hosts bidez. Izan ere, ez da ebazpenik izango. Eskemaren abantaila: ez dago lehen metodoaren muga-ezaugarririk, hau da, cross-DC bat antolatzea posible da. Baina gero galdera argia sortzen da: zenbat azkar helarazi dezakegu aldaketa /etc/hosts-era Puppet-Ansible bidez?
- Bigarren metodoa pixka bat alda dezakezu: instalatu DNS cachea web zerbitzari guztietan, eta horren bidez kodea datu-base nagusira joango da. DNSn sarrera honetarako TTL 60 ezar dezakezu. Badirudi behar bezala ezarriz gero, metodoa ona dela.
- Zerbitzuaren aurkikuntza duen eskema bat, Kontsula eta abar erabiltzea suposatzen duena.
- Aukera interesgarri bat . Trafiko guztia MySQLra bideratu behar duzu ProxySQL bidez; ProxySQL-k berak zehaztu dezake nor den maisua. Bide batez, produktu hau erabiltzeko aukeretako bati buruz irakur dezakezu my .
Github-en lan egiten duen Orchestrator-en egileak lehen eskema inplementatu zuen VIP-rekin, eta gero kontsularekin eskema bihurtu zuen.
Azpiegituren diseinu tipikoa:
Berehala deskribatuko ditut kontuan hartu beharreko egoera nabariak:
- VIP helbidea ez da zerbitzarietako edozein konfigurazioan erregistratu behar. Imajina dezagun egoera bat: maisuak berrabiarazi zuen, eta kargatzen ari zen bitartean, Orchestrator hutsegite moduan sartu zen eta esklaboetako bat maisu bihurtu zuen; gero, maisu zaharra altxatu zen, eta orain VIP-a bi autotan dago. Hau txarra da.
- Orkestratzailearentzat, maisu zaharrari eta maisu berriari deitzeko gidoia idatzi beharko duzu. Maisu zaharrean ifdown exekutatu behar duzu, eta maisu berrian - ifup vip. Polita litzateke script honetan ere sartzea hutsegite bat gertatuz gero, maisu zaharreko etengailuko ataka besterik gabe desaktibatzen dela edozein splitbrain saihesteko.
- Orchestrator-ek zure script-a deitu ondoren, lehenik VIP-a kentzeko eta/edo etengailuko ataka itzaltzeko eta, ondoren, VIP-a igotzeko gidoia deitu ondoren maisu berrian, ez ahaztu arping komandoa erabiltzea denei VIP berria orain dela esateko. hemen.
- Esklabo guztiek read_only=1 izan beharko lukete, eta esklaboa maisuarengana igo bezain laster, read_only=0 izan beharko luke.
- Ez ahaztu horretarako aukeratu dugun edozein esklabo nagusi bihur daitekeela (Orkestratzaileak lehentasun-mekanismo osoa du zein esklabutzat hartu behar duen nagusi berrirako hautagai gisa lehenik, zein bigarrenean eta zein esklabo izan behar duen. ez da inola ere hautatu master). Esklaboa maisu bihurtzen bada, orduan esklaboaren karga bere gainean geratuko da eta maisuaren karga gehituko da, hori kontuan hartu behar da.
Zergatik behar duzu Orchestrator ez baduzu?
- Orchestrator-ek oso erabilerraza den interfaze grafikoa du, topologia osoa bistaratzen duena (ikus beheko pantaila-argazkia).
- Orchestrator-ek zein esklabo atzean dauden eta, oro har, erreplikazioa non hautsi den jarraipena egin dezake (Orchestrator-i erantsitako scriptak ditugu SMSak bidaltzeko).
- Orkestratzaileak esaten dizu zein esklabo duten GTID errant bat.
Orkestratzailearen interfazea:
Zer da GTID errant?
Orchestrator lan egiteko bi baldintza nagusi daude:
- Beharrezkoa da pseudo GTID gaituta egotea MySQL klusterreko makina guztietan; GTID gaituta daukagu.
- Beharrezkoa da binlog mota bat nonahi egotea, adierazpena erabil dezakezu. Maisuak eta esklabo gehienek Row zuten konfigurazio bat genuen, eta bi historikoki Misto moduan geratu ziren. Ondorioz, Orchestrator-ek ez zituen esklabo hauek maisu berriarekin konektatu nahi.
Gogoratu ekoizpen-esklabo batean garrantzitsuena maisuarekiko koherentzia dela! Transakzioen ID globala (GTID) gaituta baduzu bai zure maisuan bai esklaboan, orduan gtid_subset funtzioa erabil dezakezu datu-aldaketak egiteko eskaera berdinak makina hauetan benetan exekutatu diren jakiteko. Honi buruz gehiago irakur dezakezu .
Horrela, Orchestrator-ek GTID errantaren bidez erakusten dizu esklaboan maisuan ez dauden transakzioak daudela. Zergatik gertatzen da hau?
- Read_only=1 ez dago gaituta esklaboan, norbait konektatuta dago eta datuak aldatzeko eskaera bat osatu du.
- Super_read_only=1 ez dago gaituta esklaboan, orduan administratzaileak, zerbitzaria nahasita, sartu eta eskaera bertan exekutatu zuen.
- Aurreko bi puntuak kontuan hartu badituzu, orduan beste trikimailu bat dago: MySQL-n, binlog-ak garbitzeko eskaera ere binlog-era doa, beraz, lehenengo hustutzean, GTID errant bat agertuko da maisuan eta esklabo guztietan. Nola saihestu hau? Perona-5.7.25-28-k binlog_skip_flush_commands=1 ezarpena sartu zuen, binlog-etan hustuketa idaztea debekatzen duena. Ezarritako bat dago mysql.com webgunean .
Aurreko guztia laburbiltzen dut. Oraindik ez baduzu Orchestrator hutsegite moduan erabili nahi, jarri behaketa moduan. Orduan beti izango duzu begien aurrean MySQL makinen elkarrekintzaren mapa eta informazio bisuala makina bakoitzean zer erreplika mota dagoen, esklaboak atzean geratzen diren ala ez eta, batez ere, maisuarekin zein koherentzia duten!
Ageriko galdera hau da: "Nola funtzionatu behar du Orkestratzaileak?" Oraingo esklaboetatik maisu berri bat hautatu behar du, eta, ondoren, esklabo guztiak berriro konektatu behar ditu (horretarako behar da GTID; mekanismo zaharra binlog_name eta binlog_pos-ekin erabiltzen baduzu, orduan esklabo bat egungo maisutik berri batera aldatuz). ezinezkoa da!). Orchestrator izan baino lehen, behin eskuz egin behar izan nuen hori guztia. Maisu zaharra zintzilik zegoen Adaptec kontrolagailu akats baten ondorioz; 10 esklabo inguru zituen. VIP maisutik esklaboetako batera transferitu behar nuen eta beste esklabo guztiak berriro konektatu behar nuen. Zenbat kontsola ireki behar izan nituen, zenbat komando aldibereko sartu... 3:XNUMXak arte itxaron behar izan nuen, esklabo guztiei karga kendu bi izan ezik, bi nagusien lehen makina egin, bigarren makina berehala lotu. hari, beraz, lotu gainerako esklabo guztiak maisu berriari eta itzuli karga. Orokorrean, izugarria...
Nola funtzionatzen du Orchestrator hutsegite moduan sartzen denean? Hau errazena da maisu bat orain baino makina indartsuagoa eta modernoagoa bihurtu nahi dugun egoera baten adibide batekin.
Irudiak prozesuaren erdialdea erakusten du. Zer egin da ordura arte? Esan genuen esklabo batzuk maisu berri bihurtu nahi genituela, Orchestrator beste esklabo guztiak harekin berriro konektatzen hasi zen, maisu berriak igarobide-makina gisa jokatzen zuela. Eskema honekin, ez da errorerik gertatzen, esklabo guztiek funtzionatzen dute, Orchestrator-ek VIP-a maisu zaharretik kentzen du, berrira transferitzen du, read_only=0 egiten du eta maisu zaharraz ahazten da. Denak! Gure zerbitzuaren geldialdia VIP transferentzia denbora da, hau da, 2-3 segundokoa.
Hori da gaurkoa dena, eskerrik asko guztioi. Orchestratorri buruzko bigarren artikulu bat izango da laster. "Garage" pelikula sobietar ospetsuan, pertsonaia batek esan zuen: "Ez nuke berarekin azterketarik egingo!" Beraz, orkestratzailea, zurekin joango nintzateke ezagutzera!
Iturria: www.habr.com