Orchestrator ya MySQL: kwa nini huwezi kujenga mradi unaostahimili makosa bila hiyo

Mradi wowote mkubwa ulianza na seva kadhaa. Mwanzoni kulikuwa na seva moja ya DB, kisha watumwa waliongezwa kwake ili kuongeza usomaji. Na kisha - kuacha! Bwana ni mmoja, lakini watumwa ni wengi; ikiwa mmoja wa watumwa ataondoka, basi kila kitu kitakuwa sawa, lakini ikiwa bwana ataondoka, itakuwa mbaya: wakati wa chini, wasimamizi wanajaribu kuinua seva. Nini cha kufanya? Hifadhi bwana. Mwenzangu Pavel tayari aliandika juu ya hili nakala, sitarudia. Badala yake, nitakuambia kwa nini unahitaji Orchestrator kwa MySQL!

Wacha tuanze na swali kuu: "Tutabadilishaje nambari hiyo kwa mashine mpya wakati bwana anaondoka?"

• Ninapenda mpango na VIP (Virtual IP) zaidi, tutazungumza juu yake hapa chini. Ni rahisi na dhahiri zaidi, ingawa ina kizuizi dhahiri: bwana ambaye tutahifadhi lazima awe katika sehemu ya L2 na mashine mpya, ambayo ni, tunaweza kusahau kuhusu DC ya pili. Na, kwa njia ya kirafiki, ikiwa unafuata sheria kwamba L2 kubwa ni mbaya, kwa sababu L2 ni kwa rack tu, na L3 ni kati ya racks, na mpango huo una vikwazo zaidi.
• Unaweza kuandika jina la DNS kwenye msimbo na kuitatua kupitia /etc/hosts. Kwa kweli, hakutakuwa na azimio. Faida ya mpango huo: hakuna sifa ya kizuizi cha njia ya kwanza, yaani, inawezekana kuandaa msalaba-DC. Lakini basi swali la wazi linatokea: je, tunawezaje kuwasilisha mabadiliko kwa /etc/hosts kupitia Puppet-Ansible?
• Unaweza kubadilisha njia ya pili kidogo: kusanikisha caching DNS kwenye seva zote za wavuti, kwa njia ambayo msimbo utaenda kwenye hifadhidata kuu. Unaweza kuweka TTL 60 kwa ingizo hili katika DNS. Inaonekana kwamba ikiwa inatekelezwa kwa usahihi, njia hiyo ni nzuri.
• Mpango wenye ugunduzi wa huduma, unaomaanisha matumizi ya Balozi na nk.
• Chaguo la kuvutia na ProxySQL. Unahitaji kuelekeza trafiki yote kwa MySQL kupitia ProxySQL; ProxySQL yenyewe inaweza kuamua nani ni bwana. Kwa njia, unaweza kusoma kuhusu moja ya chaguzi za kutumia bidhaa hii katika yangu Ibara ya.

Mwandishi wa Orchestrator, anayefanya kazi huko Github, alitekeleza kwanza mpango wa kwanza na VIP, na kisha akaubadilisha kuwa mpango na balozi.

Muundo wa kawaida wa miundombinu:

Nitaelezea mara moja hali dhahiri ambazo zinahitaji kuzingatiwa:

• Anwani ya VIP haipaswi kusajiliwa katika usanidi kwenye seva yoyote. Wacha tufikirie hali: bwana alianzisha tena, na wakati inapakia, Orchestrator aliingia kwenye hali ya kushindwa na kumfanya mmoja wa watumwa kuwa bwana; kisha bwana wa zamani akainuka, na sasa VIP iko kwenye magari mawili. Hii ni mbaya.
• Kwa orchestrator, utahitaji kuandika hati ya kumwita bwana wa zamani na bwana mpya. Kwenye bwana wa zamani unahitaji kukimbia ifdown, na kwa bwana mpya - ifup vip. Itakuwa nzuri pia kuingiza katika script hii kwamba katika tukio la kushindwa, bandari kwenye swichi ya bwana wa zamani imezimwa tu ili kuepuka mgawanyiko wowote.
• Baada ya Orchestrator kuita hati yako ili kwanza kuondoa VIP na/au kuzima bandari kwenye swichi, na kisha kuita hati ya kuongeza VIP kwenye bwana mpya, usisahau kutumia amri ya arping kuwaambia kila mtu kuwa VIP mpya ni sasa. hapa.
• Watumwa wote walipaswa kusoma_tu=1, na mara tu unapompandisha cheo mtumwa kwa bwana, inapaswa kuwa imesoma_pekee=0.
• Usisahau kwamba mtumwa yeyote ambaye tumemchagua kwa hii anaweza kuwa bwana (Orchestrator ina utaratibu mzima wa upendeleo ambao mtumwa anapaswa kuzingatia kama mgombea wa bwana mpya katika nafasi ya kwanza, ambayo katika nafasi ya pili, na ni mtumwa gani anapaswa kuzingatia. kutochaguliwa hata kidogo kwa hali yoyote bwana). Ikiwa mtumwa anakuwa bwana, basi mzigo wa mtumwa utabaki juu yake na mzigo wa bwana utaongezwa, hii lazima izingatiwe.

Kwa nini unahitaji Orchestrator ikiwa huna moja?

• Orchestrator ina kiolesura cha kielelezo kinachofaa sana mtumiaji ambacho kinaonyesha topolojia nzima (ona picha ya skrini hapa chini).
• Orchestrator inaweza kufuatilia ni watumwa gani wamesalia nyuma, na ambapo urudufishaji umeharibika kwa ujumla (tuna hati zilizoambatishwa kwa Orchestrator za kutuma SMS).
• Orchestrator anakuambia ni watumwa gani wana makosa ya GTID.

Kiolesura cha orchestrator:

Makosa ya GTID ni nini?

Kuna mahitaji mawili kuu kwa Orchestrator kufanya kazi:

• Ni muhimu kwamba GTID bandia iwashwe kwenye mashine zote kwenye nguzo ya MySQL; tumewasha GTID.
• Inahitajika kuwa kuna aina moja ya logi kila mahali, unaweza kutumia taarifa. Tulikuwa na usanidi ambao bwana na watumwa wengi walikuwa na Safu, na wawili kihistoria walibaki katika hali ya Mchanganyiko. Kama matokeo, Orchestrator hakutaka tu kuwaunganisha watumwa hawa na bwana mpya.

Kumbuka kwamba jambo muhimu zaidi katika mtumwa wa uzalishaji ni msimamo wake na bwana! Ikiwa umewasha Kitambulisho cha Muamala wa Kimataifa (GTID) kwenye bwana na mtumwa wako, basi unaweza kutumia gtid_subset chaguo za kukokotoa ili kujua kama maombi sawa ya mabadiliko ya data yametekelezwa kwenye mashine hizi. Unaweza kusoma zaidi kuhusu hili hapa.

Kwa hivyo, Orchestrator inakuonyesha kupitia makosa ya GTID kwamba kuna miamala kwa mtumwa ambayo haiko kwa bwana. Kwa nini hii inatokea?

• Read_only=1 haijawashwa kwenye mtumwa, mtu aliunganisha na kukamilisha ombi la kubadilisha data.
• Super_read_only=1 haijawashwa kwa mtumwa, basi msimamizi, akiwa amechanganya seva, akaingia na kutekeleza ombi hapo.
• Ikiwa umezingatia pointi zote mbili za awali, basi kuna hila moja zaidi: katika MySQL, ombi la kufuta binlogs pia huenda kwa binlog, kwa hiyo kwa mara ya kwanza, kosa la GTID litatokea kwa bwana na watumwa wote. Jinsi ya kuepuka hili? Perona-5.7.25-28 ilianzisha mpangilio wa binlog_skip_flush_commands=1, ambao unakataza kuandika flush kwa logi. Kuna iliyoanzishwa kwenye wavuti ya mysql.com mdudu.

Acha nifanye muhtasari wa yote hapo juu. Ikiwa hutaki kutumia Orchestrator katika hali ya kushindwa bado, basi iweke katika hali ya uchunguzi. Kisha utakuwa na daima mbele ya macho yako ramani ya mwingiliano wa mashine za MySQL na taarifa ya kuona kuhusu aina gani ya replication iko kwenye kila mashine, ikiwa watumwa wanabaki nyuma, na muhimu zaidi, jinsi wanavyofanana na bwana!

Swali la wazi ni: "Okestra inapaswa kufanya kazi vipi?" Lazima achague bwana mpya kutoka kwa watumwa wa sasa, na kisha aunganishe watumwa wote kwake (hii ndio GTID inahitajika; ikiwa unatumia utaratibu wa zamani na binlog_name na binlog_pos, kisha kubadilisha mtumwa kutoka kwa bwana wa sasa hadi mpya. haiwezekani tu!). Kabla ya kuwa na Orchestrator, nililazimika kufanya haya yote kwa mikono. Bwana huyo mzee alikuwa akining'inia kwa sababu ya kidhibiti cha buggy cha Adaptec; kilikuwa na watumwa 10 hivi. Nilihitaji kuhamisha VIP kutoka kwa bwana hadi kwa mmoja wa watumwa na kuunganisha watumwa wengine wote kwake. Nilipaswa kufungua consoles ngapi, ni amri ngapi za wakati huo huo nilizoingia ... Ilinibidi kusubiri hadi saa 3 asubuhi, niondoe mzigo kutoka kwa watumwa wote isipokuwa mbili, tengeneza mashine ya kwanza kutoka kwa bwana wawili, mara moja ambatisha mashine ya pili. Kwa hiyo, waambatanishe watumwa wengine wote kwa bwana mpya na urudishe mzigo huo. Kwa ujumla, kutisha ...

Orchestrator inafanyaje kazi inapoingia katika hali ya kushindwa? Hii inaonyeshwa kwa urahisi zaidi na mfano wa hali ambapo tunataka kufanya bwana mashine yenye nguvu zaidi, ya kisasa zaidi kuliko sisi sasa.

Takwimu inaonyesha katikati ya mchakato. Je, ni nini tayari kimefanywa hadi kufikia hatua hii? Tulisema kwamba tulitaka kumfanya mtumwa fulani kuwa bwana mpya, Orchestrator alianza kuwaunganisha tena watumwa wengine wote kwake, huku bwana huyo mpya akiigiza kama mashine ya kupita. Kwa mpango huu, hakuna makosa yanayotokea, watumwa wote hufanya kazi, Orchestrator huondoa VIP kutoka kwa bwana wa zamani, kuihamisha kwa mpya, hufanya kusoma_tu = 0 na kusahau kuhusu bwana wa zamani. Wote! Muda wa chini wa huduma yetu ni wakati wa uhamisho wa VIP, ambao ni sekunde 2-3.

Ni hayo tu kwa leo, asanteni wote. Kutakuwa na makala ya pili kuhusu Orchestrator hivi karibuni. Katika filamu maarufu ya Soviet "Garage," mhusika mmoja alisema, "singeendelea na uchunguzi naye!" Kwa hivyo, Orchestrator, ningeenda nawe kwenye uchunguzi!

Chanzo: mapenzi.com