Ĉe Citymobil ni uzas MySQL-datumbazon kiel nia ĉefa konstanta datumstokado. Ni havas plurajn datumbazajn aretojn por diversaj servoj kaj celoj.

La konstanta havebleco de la majstro estas kritika indikilo de la agado de la tuta sistemo kaj ĝiaj individuaj partoj. Aŭtomata reakiro de areto en la okazaĵo de majstra fiasko multe reduktas okazaĵan respondtempon kaj sisteman malfunkcion. En ĉi tiu artikolo, mi rigardos dezajnon de alta havebleco (HA) por MySQL-grupo bazita sur MySQL-Orkestro kaj virtualaj IP-adresoj (VIP).

HA-solvo bazita sur VIP

Unue, mi mallonge diros al vi, kio estas nia datuma konserva sistemo.

Ni uzas klasikan reproduktan skemon kun unu skrib-alirebla majstro kaj multoblaj nurlegeblaj kopioj. Areto povas enhavi mezan majstron - nodo kiu estas kaj kopio kaj majstro por aliaj. Klientoj aliras kopiojn per HAProxy, kiu ebligas eĉ ŝarĝan distribuon kaj facilan skalon. La uzo de HAProxy estas pro historiaj kialoj, kaj ni nuntempe estas en procezo de migrado al ProxySQL.

Reproduktado estas farita en duonsinkrona reĝimo bazita sur GTID. Ĉi tio signifas, ke almenaŭ unu kopio devas registri transakcion antaŭ ol ĝi estas konsiderata sukcesa. Ĉi tiu reprodukta reĝimo disponigas optimuman ekvilibron inter efikeco kaj datumsekureco en la okazaĵo de majstra nodo-fiasko. Esence ĉiuj ŝanĝoj estas translokigitaj de la majstro al la kopioj uzante Row Based Replication (RBR), sed iuj nodoj povas havi mixed binlog format.

La orkestranto periode ĝisdatigas la staton de la grapoltopologio, analizas la ricevitajn informojn, kaj se aperas problemoj, ĝi povas lanĉi aŭtomatan reakiran proceduron. La programisto respondecas pri la proceduro mem, ĉar ĝi povas esti efektivigita laŭ malsamaj manieroj: surbaze de VIP, DNS, uzante servo-malkovrajn servojn aŭ memskribitajn mekanismojn.

Unu simpla maniero restarigi majstron se ĝi malsukcesas estas uzi flosajn VIP-adresojn.

Kion vi bezonas scii pri ĉi tiu solvo antaŭ ol antaŭeniri:

• VIP estas IP-adreso, kiu ne rilatas al specifa fizika reto-interfaco. Se nodo malsukcesas aŭ dum planita prizorgado, ni povas ŝanĝi la VIP al alia rimedo kun minimuma malfunkcio.
• Liberigi kaj elsendi virtualan IP-adreson estas malmultekosta kaj rapida operacio.
• Por labori kun VIP, vi bezonas aliron al la servilo per SSH, aŭ la uzon de specialaj utilecoj, ekzemple, keepalived.

Ni rigardu eblajn problemojn kun nia sorĉisto kaj imagu kiel devus funkcii la aŭtomata reakiro.

Reta konektebleco al la majstro malaperis, aŭ problemo aperis sur la aparataro, kaj la servilo estas neatingebla

1. La orkestranto ĝisdatigas la arettopologion, ĉiu kopio raportas ke la majstro estas neatingebla. La orkestranto komencas la procezon elekti kopion taŭgan por la rolo de la nova majstro kaj komencas reakiron.
2. Ni provas forigi la VIP de la malnova majstro - sen sukceso.
3. La kopio ŝanĝas al la rolo de majstro. La topologio estas rekonstruata.
4. Aldonante novan retan interfacon kun VIP. Ĉar ne eblis forigi la VIP, ni periode komencas sendi peton en la fono senpaga ARP. Ĉi tiu speco de peto/respondo ebligas al vi ĝisdatigi la IP- kaj MAC-adresmapan tabelon sur la konektitaj ŝaltiloj, tiel sciigante al vi, ke nia VIP translokiĝis. Ĉi tio minimumigas la verŝajnecon split brain reveninte la maljunan majstron.
5. Ĉiuj novaj konektoj tuj estas redirektitaj al la nova majstro. Malnovaj konektoj malsukcesas kaj ripetaj vokoj al la datumbazo estas faritaj ĉe la aplika nivelo.

La servilo funkcias en normala reĝimo, malsukceso okazis ĉe la DBMS-nivelo

La algoritmo estas simila al la antaŭa kazo: ĝisdatigi la topologion kaj komenci la reakiron. Ĉar la servilo disponeblas, ni sukcese liberigas la VIP sur la malnova majstro, transdonas ĝin al la nova kaj sendas plurajn ARP-petojn. La ebla reveno de la malnova majstro ne devus influi la rekonstruitan areton kaj la funkciadon de la aplikaĵo.

Aliaj problemoj

Fiasko de kopioj aŭ mezaj majstroj ne gvidas al aŭtomataj agoj kaj postulas manan intervenon.

Virtuala reto-interfaco ĉiam estas aldonita provizore, tio estas, post rekomenco de servilo, la VIP ne estas aŭtomate asignita. Ĉiu datumbaza okazo komenciĝas en nurlegebla reĝimo defaŭlte, la orkestro aŭtomate ŝanĝas la novan majstron por skribi kaj provas instali read only sur la maljuna majstro. Ĉi tiuj agoj celas redukti la verŝajnecon split brain.

Problemoj povas aperi dum la reakiro, kiu ankaŭ devus esti sciigita per la orkestra UI krom normaj monitoraj iloj. Ni vastigis la REST API aldonante ĉi tiun funkcion (PR nuntempe sub revizio).

La ĝenerala diagramo de la HA-solvo estas prezentita malsupre.

Elektante novan majstron

La orkestro estas sufiĉe saĝa kaj provas elekti la plej taŭga kopio kiel nova majstro laŭ la jenaj kriterioj:

• la kopio postrestas malantaŭ la majstro;
• MySQL-versio de majstro kaj kopio;
• reproduktadspeco (RBR, SBR aŭ miksita);
• loko en la sama aŭ malsamaj datumcentroj;
• disponibilidad errant GTID - transakcioj kiuj estis efektivigitaj sur la kopio kaj ne estas sur la majstro;
• kutimaj elektaj reguloj ankaŭ estas konsiderataj.

Ne ĉiu signalo estas ideala kandidato por majstro. Ekzemple, kopio povas esti uzata por sekurkopii datumojn, aŭ la servilo havas pli malfortan hardvarkonfiguracion. Orkestro subtenoj manaj reguloj per kiuj vi povas agordi viajn kandidatojn elektpreferojn de plej preferataj ĝis ignoritaj.

Tempo de respondo kaj reakiro

Okaze de okazaĵo, gravas minimumigi la malfunkcion de la sistemo, do ni konsideru la MySQL-parametrojn, kiuj influas la kreadon kaj ĝisdatigon de la cluster-topologio de la orkestro:

• slave_net_timeout — la nombro da sekundoj dum kiuj la kopio atendas ke novaj datumoj aŭ korbatsignalo alvenos de la majstro antaŭ ol la konekto estas rekonita kiel perdita kaj rekonektita. Ju pli malalta la valoro, des pli rapide la kopio povas determini, ke komunikado kun la majstro estas rompita. Ni fiksas ĉi tiun valoron al 5 sekundoj.
• MASTER_CONNECT_RETRY — nombro da sekundoj inter rekonektoprovoj. Okaze de retaj problemoj, malalta valoro por ĉi tiu parametro permesos rapidan rekonekton kaj malhelpos komenci la reakiran procezon de la grapolo. La rekomendita valoro estas 1 sekundo.
• MASTER_RETRY_COUNT — maksimuma nombro da rekonektoprovoj.
• MASTER_HEARTBEAT_PERIOD — intervalo en sekundoj post kiu la majstro sendas korbatsignalon. Defaŭlte al duono de la valoro slave_net_timeout.

Parametroj de orkestranto:

• DelayMasterPromotionIfSQLThreadNotUpToDate - se egale true, tiam la majstra rolo ne estos aplikita sur la kandidat-repliko ĝis la SQL-fadeno de la kopio kompletigis ĉiujn neaplikatajn transakciojn de la Relajsa Protokolo. Ni uzas ĉi tiun opcion por eviti perdi transakciojn kiam ĉiuj kandidatoj kopias malantaŭen.
• InstancePollSeconds — ofteco de konstruado kaj ĝisdatigo de la topologio.
• RecoveryPollSeconds — ofteco de topologia analizo. Se problemo estas detektita, topologia reakiro estas komencita. Ĉi tio konstanta, egala al 1 sekundo.

Ĉiu aretnodo estas balotita de la orkestranto unufoje ĉiu InstancePollSeconds sekundoj Kiam problemo estas detektita, la amasŝtato estas devigita ĝisdatigita, kaj tiam la fina decido estas farita por elfari reakiron. Spertante kun malsamaj datumbazoj kaj orkestroparametroj, ni povis redukti la respondan kaj reakivan tempon al 30 sekundoj.

Testbenko

Ni komencis testi la HA-skemon kun la disvolviĝo de loka testbenko kaj plia efektivigo en testaj kaj produktadmedioj. La loka stando estas plene aŭtomatigita surbaze de Docker kaj permesas vin eksperimenti kun la agordo de la orkestro kaj reto, grimpi la areton de 2-3 serviloj al pluraj dekduoj, kaj fari ekzercojn en sekura medio.

Dum la ekzercoj, ni elektas unu el la problemaj emulaj metodoj: tuj pafu la majstron uzante kill -9, mallaŭte ĉesigu la procezon kaj haltigu la servilon (docker-compose stop), simulu retajn problemojn uzante iptables -j REJECT aŭ iptables -j DROP. Ni atendas la sekvajn rezultojn:

• la orkestro detektos problemojn kun la majstro kaj ĝisdatigos la topologion en ne pli ol 10 sekundoj;
• la reakira proceduro aŭtomate komenciĝos: la reto-agordo ŝanĝiĝos, la rolo de la majstro transiros al la kopio, la topologio estos rekonstruita;
• la nova majstro fariĝos skribebla, vivaj kopioj ne perdiĝos dum la rekonstrua procezo;
• datumoj komencos esti skribitaj al la nova majstro kaj reproduktitaj;
• La tuta reakiro ne estos pli ol 30 sekundoj.

Kiel vi scias, la sistemo povas konduti malsame en testaj kaj produktadmedioj pro malsamaj aparataro kaj retaj agordoj, diferencoj en sinteza kaj reala ŝarĝo, ktp. Tial ni periode faras ekzercojn en realaj kondiĉoj, kontrolante kiel la sistemo kondutas kiam reto-konektebleco estas perdita aŭ ĝiaj individuaj partoj estas degraditaj. En la estonteco, ni volas konstrui tute identan infrastrukturon por ambaŭ medioj kaj aŭtomatigi ĝian testadon.

trovoj

La sano de la ĉefa stoksistemo-nodo estas unu el la ĉefaj taskoj de la SRE kaj operacia teamo. La efektivigo de la orkestranto kaj HA-solvo bazita sur VIP permesis al ni atingi la sekvajn rezultojn:

• fidinda detekto de problemoj kun la topologio de la datumbaza areto;
• aŭtomata kaj rapida respondo al mastro-rilataj okazaĵoj, reduktante sisteman malfunkcion.

Tamen, la solvo havas siajn limojn kaj malavantaĝojn:

• grimpi la HA-skemon al pluraj datumcentroj postulos ununuran L2-reton inter ili;
• Antaŭ ol atribui VIP al la nova majstro, ni devas liberigi ĝin sur la malnova. La procezo estas sinsekva, kio pliigas reakivan tempon;
• liberigi la VIP postulas SSH-aliron al la servilo, aŭ ajnan alian metodon por voki forajn procedurojn. Ĉar la servilo aŭ datumbazo spertas problemojn, kiuj kaŭzis la reakiran procezon, ni ne povas esti certaj, ke la VIP-forigo sukcese finiĝos. Kaj ĉi tio povas konduki al apero de du serviloj kun la sama virtuala IP-adreso kaj problemo split brain.

Eviti split brain, vi povas uzi la metodon ŜTONO ("Pafu La Alian Nodon En La Kapon"), kiu tute izolas aŭ malŝaltas la problemnodon. Estas aliaj manieroj efektivigi cluster alta havebleco: kombinaĵo de VIP kaj DNS, servo malkovro kaj prokura servoj, sinkrona reproduktado kaj aliaj metodoj kiuj havas siajn proprajn malavantaĝojn kaj avantaĝojn.

Mi parolis pri nia aliro al kreado de MySQL-malsukcesa grapolo. Ĝi estas facile efektivigi kaj disponigas akcepteblan nivelon de fidindeco sub nunaj kondiĉoj. Ĉar la tuta sistemo ĝenerale kaj infrastrukturo precipe evoluas, ĉi tiu aliro sendube evoluos.

fonto: www.habr.com