Sa Citymobil gumagamit kami ng MySQL database bilang aming pangunahing patuloy na pag-iimbak ng data. Mayroon kaming ilang database cluster para sa iba't ibang serbisyo at layunin.

Ang patuloy na pagkakaroon ng master ay isang kritikal na tagapagpahiwatig ng pagganap ng buong sistema at ang mga indibidwal na bahagi nito. Ang awtomatikong pagbawi ng cluster kung sakaling magkaroon ng master failure ay lubos na nakakabawas sa oras ng pagtugon sa insidente at downtime ng system. Sa artikulong ito, titingnan ko ang isang mataas na kakayahang magamit (HA) na disenyo para sa isang MySQL cluster batay sa MySQL Orchestrator at mga virtual na IP address (VIP).

HA solusyon batay sa VIP

Una, maikling sasabihin ko sa iyo kung ano ang aming data storage system.

Gumagamit kami ng classic na replication scheme na may isang write-accessible master at maramihang read-only na replika. Ang cluster ay maaaring maglaman ng intermediate master - isang node na parehong replica at master para sa iba. Ina-access ng mga kliyente ang mga replika sa pamamagitan ng HAProxy, na nagbibigay-daan para sa pantay na pamamahagi ng pag-load at madaling pag-scale. Ang paggamit ng HAProxy ay dahil sa mga makasaysayang dahilan, at kami ay kasalukuyang nasa proseso ng paglipat sa ProxySQL.

Isinasagawa ang pagtitiklop sa semi-synchronous na mode batay sa GTID. Nangangahulugan ito na hindi bababa sa isang replika ang dapat mag-log ng isang transaksyon bago ito ituring na matagumpay. Nagbibigay ang replication mode na ito ng pinakamainam na balanse sa pagitan ng performance at kaligtasan ng data kung sakaling magkaroon ng master node failure. Karaniwan ang lahat ng mga pagbabago ay inililipat mula sa master patungo sa mga replika na ginagamit Row Based Replication (RBR), ngunit maaaring mayroon ang ilang mga node mixed binlog format.

Pana-panahong ina-update ng orkestra ang estado ng topology ng cluster, sinusuri ang impormasyong natanggap, at kung may mga problema, maaari itong maglunsad ng isang awtomatikong pamamaraan sa pagbawi. Ang nag-develop ay may pananagutan para sa mismong pamamaraan, dahil maaari itong ipatupad sa iba't ibang paraan: batay sa VIP, DNS, gamit ang mga serbisyo sa pagtuklas ng serbisyo o mga self-written na mekanismo.

Isang simpleng paraan upang maibalik ang isang master kung nabigo ito ay ang paggamit ng mga lumulutang na VIP address.

Ano ang kailangan mong malaman tungkol sa solusyon na ito bago sumulong:

Ang VIP ay isang IP address na hindi nauugnay sa isang partikular na pisikal na interface ng network. Kung nabigo ang isang node o sa panahon ng naka-iskedyul na pagpapanatili, maaari naming ilipat ang VIP sa isa pang mapagkukunan na may kaunting downtime.
Ang pagpapalaya at pag-isyu ng isang virtual na IP address ay isang mura at mabilis na operasyon.
Upang gumana sa VIP, kailangan mo ng access sa server sa pamamagitan ng SSH, o ang paggamit ng mga espesyal na kagamitan, halimbawa, keepalived.

Tingnan natin ang mga posibleng problema sa aming wizard at isipin kung paano dapat gumana ang mekanismo ng awtomatikong pagbawi.

Nawala ang pagkakakonekta ng network sa master, o nagkaroon ng problema sa antas ng hardware, at hindi available ang server

Ina-update ng orkestra ang cluster topology, ang bawat replica ay nag-uulat na ang master ay hindi magagamit. Sinisimulan ng orkestra ang proseso ng pagpili ng replika na angkop para sa papel ng bagong master at magsisimula ng pagbawi.
Sinusubukan naming alisin ang VIP mula sa matandang master - nang walang tagumpay.
Ang replica ay lumipat sa papel ng master. Ang topology ay itinayong muli.
Pagdaragdag ng bagong network interface na may VIP. Dahil hindi posible na alisin ang VIP, sinimulan naming pana-panahong magpadala ng kahilingan sa background walang bayad na ARP. Ang ganitong uri ng kahilingan/tugon ay nagbibigay-daan sa iyo na i-update ang talahanayan ng pagmamapa ng IP at MAC address sa mga konektadong switch, at sa gayon ay aabisuhan ka na ang aming VIP ay lumipat na. Pinaliit nito ang posibilidad split brain pagbabalik ng matandang amo.
Ang lahat ng mga bagong koneksyon ay agad na na-redirect sa bagong master. Nabigo ang mga lumang koneksyon at ang mga paulit-ulit na tawag sa database ay ginawa sa antas ng aplikasyon.

Ang server ay tumatakbo sa normal na mode, isang pagkabigo ang naganap sa antas ng DBMS

Ang algorithm ay katulad ng nakaraang kaso: pag-update ng topology at pagsisimula ng proseso ng pagbawi. Dahil available ang server, matagumpay naming nai-release ang VIP sa lumang master, inilipat ito sa bago, at nagpadala ng ilang kahilingan sa ARP. Ang posibleng pagbabalik ng lumang master ay hindi dapat makaapekto sa itinayong muli na kumpol at ang pagpapatakbo ng aplikasyon.

Iba pang mga problema

Pagkabigo ng mga replika o intermediate masters hindi nangunguna sa mga awtomatikong pagkilos at nangangailangan ng manu-manong interbensyon.

Ang isang virtual na interface ng network ay palaging idinagdag pansamantala, iyon ay, pagkatapos ng pag-reboot ng server, ang VIP ay hindi awtomatikong itinalaga. Ang bawat database instance ay nagsisimula sa read-only na mode bilang default, awtomatikong inililipat ng orkestra ang bagong master para magsulat at sinusubukang i-install read only sa matandang master. Ang mga pagkilos na ito ay naglalayong bawasan ang posibilidad split brain.

Maaaring magkaroon ng mga problema sa panahon ng proseso ng pagbawi, na dapat ding ipaalam sa pamamagitan ng UI ng orkestra bilang karagdagan sa mga karaniwang tool sa pagsubaybay. Pinalawak namin ang REST API sa pamamagitan ng pagdaragdag ng feature na ito (PR kasalukuyang sinusuri).

Ang pangkalahatang diagram ng solusyon sa HA ay ipinakita sa ibaba.

Pagpili ng bagong master

Ang orkestra ay sapat na matalino at sinusubukang pumili ang pinaka-angkop na replika bilang isang bagong master ayon sa sumusunod na pamantayan:

ang replica ay nahuhuli sa likod ng master;
MySQL bersyon ng master at replika;
uri ng pagtitiklop (RBR, SBR o halo-halong);
lokasyon sa pareho o magkaibang mga data center;
availability errant GTID — mga transaksyon na isinagawa sa replica at wala sa master;
Isinasaalang-alang din ang mga custom na panuntunan sa pagpili.

Hindi lahat ng cue ay isang perpektong kandidato para sa isang master. Halimbawa, maaaring gamitin ang isang replika sa pag-backup ng data, o ang server ay may mas mahinang configuration ng hardware. Orkestra sumusuporta manu-manong panuntunan kung saan maaari mong i-customize ang iyong mga kagustuhan sa pagpili ng kandidato mula sa pinakagusto hanggang sa hindi pinansin.

Oras ng pagtugon at pagbawi

Sa kaganapan ng isang insidente, mahalagang bawasan ang downtime ng system, kaya isaalang-alang natin ang mga parameter ng MySQL na nakakaapekto sa paglikha at pag-update ng cluster topology ng orkestra:

slave_net_timeout — ang bilang ng mga segundo kung kailan naghihintay ang replica para sa bagong data o signal ng tibok ng puso na dumating mula sa master bago matukoy ang koneksyon bilang nawala at muling nakakonekta. Kung mas mababa ang halaga, mas mabilis na matutukoy ng replika na nasira ang komunikasyon sa master. Itinakda namin ang halagang ito sa 5 segundo.
MASTER_CONNECT_RETRY — bilang ng mga segundo sa pagitan ng mga pagtatangka sa muling pagkonekta. Kung sakaling magkaroon ng mga problema sa network, ang mababang halaga para sa parameter na ito ay magbibigay-daan sa mabilis na muling pagkonekta at maiwasan ang pagsisimula ng proseso ng pagbawi ng cluster. Ang inirerekomendang halaga ay 1 segundo.
MASTER_RETRY_COUNT — maximum na bilang ng mga pagtatangka sa muling pagkonekta.
MASTER_HEARTBEAT_PERIOD — agwat sa mga segundo pagkatapos kung saan ang master ay nagpapadala ng signal ng tibok ng puso. Default sa kalahati ng halaga slave_net_timeout.

Mga parameter ng orkestra:

DelayMasterPromotionIfSQLThreadNotUpToDate - kung pantay true, pagkatapos ay hindi ilalapat ang master role sa replika ng kandidato hanggang sa makumpleto ng SQL thread ng replica ang lahat ng hindi nailapat na transaksyon mula sa Relay Log. Ginagamit namin ang opsyong ito upang maiwasan ang pagkawala ng mga transaksyon kapag nahuli ang lahat ng replika ng kandidato.
InstancePollSeconds — dalas ng pagbuo at pag-update ng topology.
RecoveryPollSeconds — dalas ng pagsusuri sa topolohiya. Kung may nakitang problema, sisimulan ang pagbawi ng topology. Ito palagiang, katumbas ng 1 segundo.

Ang bawat cluster node ay sinusuri ng orkestra isang beses bawat isa InstancePollSeconds segundo Kapag may nakitang problema, mapipilitan ang cluster state na-update, at pagkatapos ay ginawa ang pangwakas na desisyon upang maisagawa ang pagbawi. Sa pamamagitan ng pag-eksperimento sa iba't ibang mga parameter ng database at orchestrator, nagawa naming bawasan ang tugon at oras ng pagbawi sa 30 segundo.

Test stand

Sinimulan naming subukan ang HA scheme sa pagbuo ng isang lokal test bench at karagdagang pagpapatupad sa pagsubok at produksyon na kapaligiran. Ang lokal na stand ay ganap na awtomatiko batay sa Docker at nagbibigay-daan sa iyong mag-eksperimento sa pagsasaayos ng orkestra at network, i-scale ang cluster mula 2-3 server sa ilang dosena, at magsagawa ng mga ehersisyo sa isang ligtas na kapaligiran.

Sa panahon ng mga pagsasanay, pumili kami ng isa sa mga pamamaraan ng pagtulad sa problema: agad na kunan ng larawan ang master gamit kill -9, malumanay na wakasan ang proseso at itigil ang server (docker-compose stop), gayahin ang mga problema sa network gamit ang iptables -j REJECT o iptables -j DROP. Inaasahan namin ang mga sumusunod na resulta:

matutuklasan ng orkestra ang mga problema sa master at i-update ang topology nang hindi hihigit sa 10 segundo;
ang pamamaraan ng pagbawi ay awtomatikong magsisimula: ang pagsasaayos ng network ay magbabago, ang papel ng master ay ipapasa sa replika, ang topology ay itatayong muli;
ang bagong master ay magiging masusulat, ang mga live na replika ay hindi mawawala sa panahon ng proseso ng muling pagtatayo;
ang data ay magsisimulang isulat sa bagong master at kopyahin;
Ang kabuuang oras ng pagbawi ay hindi hihigit sa 30 segundo.

Tulad ng alam mo, maaaring magkaiba ang pagkilos ng system sa mga kapaligiran ng pagsubok at produksyon dahil sa iba't ibang configuration ng hardware at network, mga pagkakaiba sa synthetic at real load, atbp. Samakatuwid, pana-panahon kaming nagsasagawa ng mga pagsasanay sa totoong mga kondisyon, sinusuri kung paano kumikilos ang system kapag nawala ang koneksyon sa network o ang mga indibidwal na bahagi nito ay nasira. Sa hinaharap, gusto naming bumuo ng ganap na magkaparehong imprastraktura para sa parehong mga kapaligiran at i-automate ang pagsubok nito.

Natuklasan

Ang kalusugan ng pangunahing storage system node ay isa sa mga pangunahing gawain ng SRE at operations team. Ang pagpapatupad ng orkestra at solusyon ng HA batay sa VIP ay nagbigay-daan sa amin na makamit ang mga sumusunod na resulta:

maaasahang pagtuklas ng mga problema sa topology ng kumpol ng database;
awtomatiko at mabilis na pagtugon sa mga insidenteng nauugnay sa master, na binabawasan ang downtime ng system.

Gayunpaman, ang solusyon ay may mga limitasyon at kawalan nito:

Ang pag-scale ng HA scheme sa ilang data center ay mangangailangan ng isang L2 network sa pagitan nila;
Bago magtalaga ng VIP sa bagong master, kailangan nating ilabas ito sa luma. Ang proseso ay sunud-sunod, na nagpapataas ng oras ng pagbawi;
ang pagpapalabas ng VIP ay nangangailangan ng SSH access sa server, o anumang iba pang paraan ng pagtawag sa mga malalayong pamamaraan. Dahil ang server o database ay nakakaranas ng mga problema na naging sanhi ng proseso ng pagbawi, hindi kami makatitiyak na matagumpay na makukumpleto ang pag-alis ng VIP. At ito ay maaaring humantong sa paglitaw ng dalawang server na may parehong virtual IP address at isang problema split brain.

Para maiwasan split brain, maaari mong gamitin ang pamamaraan STONITH (“Shoot The Other Node In The Head”), na ganap na naghihiwalay o nagdi-disable sa node ng problema. Mayroong iba pang mga paraan upang ipatupad ang cluster high availability: isang kumbinasyon ng VIP at DNS, pagtuklas ng serbisyo at mga serbisyo ng proxy, sabay-sabay na pagtitiklop at iba pang mga pamamaraan na may sariling mga disadvantage at pakinabang.

Nakipag-usap ako tungkol sa aming diskarte sa paglikha ng isang MySQL failover cluster. Ito ay madaling ipatupad at nagbibigay ng isang katanggap-tanggap na antas ng pagiging maaasahan sa ilalim ng kasalukuyang mga kondisyon. Habang umuunlad ang buong sistema sa pangkalahatan at partikular na imprastraktura, ang diskarteng ito ay walang alinlangan na magbabago.

Pinagmulan: www.habr.com

Orchestrator at VIP bilang isang solusyon sa HA para sa isang MySQL cluster