Orchestrator para sa MySQL: bakit hindi ka makakagawa ng fault-tolerant na proyekto kung wala ito

Ang anumang malaking proyekto ay nagsimula sa isang pares ng mga server. Sa una ay mayroong isang DB server, pagkatapos ay idinagdag dito ang mga alipin upang masukat ang pagbabasa. At pagkatapos - tumigil! May isang panginoon, ngunit maraming alipin; kung umalis ang isa sa mga alipin, magiging maayos ang lahat, ngunit kung umalis ang master, ito ay masama: downtime, sinusubukan ng mga admin na itaas ang server. Anong gagawin? Magpareserba ng master. Ang aking kasamahan na si Pavel ay nagsulat na tungkol dito isang artikulo, hindi ko na uulitin. Sa halip, sasabihin ko sa iyo kung bakit talagang kailangan mo ang Orchestrator para sa MySQL!

Magsimula tayo sa pangunahing tanong: "Paano natin ililipat ang code sa isang bagong makina kapag umalis ang master?"

• Pinaka gusto ko ang scheme na may VIP (Virtual IP), pag-uusapan natin ito sa ibaba. Ito ay ang pinakasimpleng at pinaka-halata, kahit na ito ay may isang malinaw na limitasyon: ang master na irereserba namin ay dapat na nasa L2 segment na may bagong makina, iyon ay, maaari naming kalimutan ang tungkol sa pangalawang DC. At, sa isang mapayapang paraan, kung susundin mo ang panuntunan na ang isang malaking L2 ay masama, dahil ang L2 ay bawat rack lamang, at ang L3 ay nasa pagitan ng mga rack, at ang gayong pamamaraan ay may higit pang mga paghihigpit.
• Maaari kang magsulat ng pangalan ng DNS sa code at lutasin ito sa pamamagitan ng /etc/hosts. Sa katunayan, walang magiging resolusyon. Ang bentahe ng scheme: walang limitasyon na katangian ng unang paraan, iyon ay, posible na ayusin ang isang cross-DC. Ngunit pagkatapos ay lumitaw ang malinaw na tanong: gaano kabilis namin maihahatid ang pagbabago sa /etc/hosts sa pamamagitan ng Puppet-Ansible?
• Maaari mong baguhin nang kaunti ang pangalawang paraan: i-install ang caching DNS sa lahat ng mga web server, kung saan mapupunta ang code sa master database. Maaari mong itakda ang TTL 60 para sa entry na ito sa DNS. Tila kung ipinatupad nang tama, ang pamamaraan ay mabuti.
• Isang pamamaraan na may pagtuklas ng serbisyo, na nagpapahiwatig ng paggamit ng Consul at etcd.
• Isang kawili-wiling opsyon na may ProxySQL. Kailangan mong iruta ang lahat ng trapiko sa MySQL sa pamamagitan ng ProxySQL; Ang ProxySQL mismo ay maaaring matukoy kung sino ang master. Sa pamamagitan ng paraan, maaari mong basahin ang tungkol sa isa sa mga pagpipilian para sa paggamit ng produktong ito sa aking Artikulo.

Ang may-akda ng Orchestrator, na nagtatrabaho sa Github, ay unang nagpatupad ng unang scheme sa VIP, at pagkatapos ay na-convert ito sa isang scheme na may konsul.

Karaniwang layout ng imprastraktura:

Ilalarawan ko kaagad ang mga malinaw na sitwasyon na kailangang isaalang-alang:

• Ang VIP address ay hindi dapat nakarehistro sa config sa alinman sa mga server. Isipin natin ang isang sitwasyon: nag-reboot ang master, at habang naglo-load ito, napunta sa failover mode ang Orchestrator at ginawang master ang isa sa mga alipin; pagkatapos ay bumangon ang matandang master, at ngayon ang VIP ay nasa dalawang kotse. Masama ito.
• Para sa orkestra, kakailanganin mong magsulat ng isang script para sa pagtawag sa lumang master at sa bagong master. Sa lumang master kailangan mong tumakbo ifdown, at sa bagong master - ifup vip. Mainam na isama rin sa script na ito na kung sakaling magkaroon ng failover, ang port sa switch ng lumang master ay naka-off lang upang maiwasan ang anumang splitbrain.
• Pagkatapos tawagan ng Orchestrator ang iyong script para alisin muna ang VIP at/o patayin ang port sa switch, at pagkatapos ay tawagan ang VIP raising script sa bagong master, huwag kalimutang gamitin ang arping command para sabihin sa lahat na ang bagong VIP ay ngayon. dito.
• Ang lahat ng mga alipin ay dapat na may read_only=1, at sa sandaling i-promote mo ang alipin sa master, ito ay dapat na read_only=0.
• Huwag kalimutan na ang sinumang alipin na aming pinili para dito ay maaaring maging isang master (Ang Orchestrator ay may isang buong mekanismo ng kagustuhan kung aling alipin ang dapat isaalang-alang bilang isang kandidato para sa isang bagong master sa unang lugar, na sa pangalawang lugar, at kung aling alipin ang dapat hindi mapipili sa anumang pagkakataon master). Kung ang alipin ay naging isang panginoon, kung gayon ang pagkarga ng alipin ay mananatili dito at ang pagkarga ng panginoon ay idaragdag, ito ay dapat isaalang-alang.

Bakit kailangan mo ng Orchestrator kung wala ka nito?

• Ang Orchestrator ay may napaka-user-friendly na graphical na interface na nagpapakita ng buong topology (tingnan ang screenshot sa ibaba).
• Maaaring subaybayan ng Orchestrator kung aling mga alipin ang nahuhuli, at kung saan ang replikasyon ay karaniwang nasira (mayroon kaming mga script na naka-attach sa Orchestrator para sa pagpapadala ng SMS).
• Sinasabi sa iyo ng Orchestrator kung aling mga alipin ang may mali sa GTID.

Interface ng Orkestra:

Ano ang GTID errant?

Mayroong dalawang pangunahing kinakailangan para gumana ang Orchestrator:

• Kinakailangan na pinagana ang pseudo GTID sa lahat ng machine sa MySQL cluster; pinagana namin ang GTID.
• Kinakailangan na mayroong isang uri ng mga binlog sa lahat ng dako, maaari mong gamitin ang pahayag. Nagkaroon kami ng configuration kung saan ang panginoon at karamihan sa mga alipin ay mayroong Row, at dalawang dating nanatili sa Mixed mode. Bilang resulta, ayaw lang ikonekta ng Orchestrator ang mga aliping ito sa bagong master.

Tandaan na ang pinakamahalagang bagay sa isang production slave ay ang consistency nito sa master! Kung pinagana mo ang Global Transaction ID (GTID) sa iyong master at slave, maaari mong gamitin ang function na gtid_subset upang malaman kung ang parehong mga kahilingan para sa mga pagbabago ng data ay aktwal na naisakatuparan sa mga machine na ito. Maaari mong basahin ang higit pa tungkol dito dito.

Kaya, ipinapakita sa iyo ng Orchestrator sa pamamagitan ng GTID errant na may mga transaksyon sa alipin na wala sa master. Bakit ito nangyayari?

• Read_only=1 ay hindi pinagana sa alipin, may kumonekta at nakakumpleto ng kahilingang baguhin ang data.
• Ang Super_read_only=1 ay hindi pinagana sa alipin, pagkatapos ay ang admin, na nalito sa server, ay pumasok at nagsagawa ng kahilingan doon.
• Kung isinasaalang-alang mo ang parehong nakaraang mga punto, pagkatapos ay mayroong isa pang trick: sa MySQL, ang isang kahilingan sa pag-flush ng mga binlog ay mapupunta din sa binlog, kaya sa unang pag-flush, isang GTID errant ay lilitaw sa master at lahat ng mga alipin. Paano ito maiiwasan? Ipinakilala ng Perona-5.7.25-28 ang setting na binlog_skip_flush_commands=1, na nagbabawal sa pagsulat ng flush sa mga binlog. Mayroong itinatag sa mysql.com website surot.

Hayaan akong ibuod ang lahat ng nasa itaas. Kung ayaw mo pang gamitin ang Orchestrator sa failover mode, ilagay ito sa observation mode. Pagkatapos ay palagi mong makikita sa iyong mga mata ang isang mapa ng pakikipag-ugnayan ng mga MySQL machine at visual na impormasyon tungkol sa kung anong uri ng pagtitiklop ang nasa bawat makina, kung ang mga alipin ay nahuhuli, at higit sa lahat, kung gaano sila pare-pareho sa master!

Ang malinaw na tanong ay: "Paano dapat gumana ang Orchestrator?" Dapat siyang pumili ng isang bagong master mula sa kasalukuyang mga alipin, at pagkatapos ay muling ikonekta ang lahat ng mga alipin dito (ito ang kailangan para sa GTID; kung gagamitin mo ang lumang mekanismo na may binlog_name at binlog_pos, pagkatapos ay palitan ang isang alipin mula sa kasalukuyang master sa isang bago. imposible lang!). Bago kami magkaroon ng Orchestrator, minsan ay kinailangan kong gawin ang lahat ng ito nang manu-mano. Nakabitin ang matandang amo dahil sa isang buggy na Adaptec controller; mayroon itong mga 10 alipin. Kailangan kong ilipat ang VIP mula sa master sa isa sa mga alipin at muling ikonekta ang lahat ng iba pang mga alipin dito. Ilang console ang kailangan kong buksan, ilang sabay-sabay na utos ang pinasok ko... Kailangan kong maghintay hanggang 3 am, tanggalin ang load sa lahat ng alipin maliban sa dalawa, gawin ang unang makina sa dalawang master, agad na ikabit ang pangalawang makina dito, kaya ilakip ang lahat ng iba pang mga alipin sa bagong panginoon at ibalik ang karga. Sa pangkalahatan, kakila-kilabot...

Paano gumagana ang Orchestrator kapag napunta ito sa failover mode? Ito ay pinakamadaling ilarawan ng isang halimbawa ng isang sitwasyon kung saan gusto nating gawing mas makapangyarihan, mas modernong makina ang master kaysa sa mayroon tayo ngayon.

Ipinapakita ng figure ang gitna ng proseso. Ano na ang nagawa hanggang sa puntong ito? Sinabi namin na gusto naming gawing bagong master ang ilang alipin, sinimulan lang ng Orchestrator na ikonekta muli ang lahat ng iba pang mga alipin dito, kasama ang bagong master na kumikilos bilang isang transit machine. Sa scheme na ito, walang mga error na nagaganap, gumagana ang lahat ng mga alipin, inalis ng Orchestrator ang VIP mula sa lumang master, inilipat ito sa bago, ginagawang read_only=0 at nakalimutan ang tungkol sa lumang master. Lahat! Ang downtime ng aming serbisyo ay ang VIP transfer time, na 2-3 segundo.

Iyon lang para sa araw na ito, salamat sa lahat. Malapit nang magkaroon ng pangalawang artikulo tungkol sa Orchestrator. Sa sikat na pelikulang Sobyet na "Garage," sinabi ng isang karakter, "Hindi ako magpapatuloy sa reconnaissance sa kanya!" Kaya, Orchestrator, sasamahan kita sa reconnaissance!

Pinagmulan: www.habr.com