By Citymobil gebruik ons ​​'n MySQL-databasis as ons vernaamste volgehoue ​​databerging. Ons het verskeie databasisklusters vir verskeie dienste en doeleindes.

Die konstante beskikbaarheid van die meester is 'n kritieke aanduiding van die prestasie van die hele stelsel en sy individuele dele. Outomatiese groepherstel in die geval van 'n meestermislukking verminder die reaksietyd van die voorval en stelselstilstand aansienlik. In hierdie artikel sal ek kyk na 'n hoë beskikbaarheid (HA) ontwerp vir 'n MySQL-kluster gebaseer op MySQL-orkeseerder en virtuele IP-adresse (VIP).

HA-oplossing gebaseer op VIP

Eerstens sal ek jou kortliks vertel wat ons databergingstelsel is.

Ons gebruik 'n klassieke replikasieskema met een skryftoeganklike meester en veelvuldige leesalleen-replikas. 'n Tros kan 'n intermediêre meester bevat - 'n nodus wat beide 'n replika en 'n meester vir ander is. Kliënte kry toegang tot replikas deur HAProxy, wat eweredige vragverspreiding en maklike skaal moontlik maak. Die gebruik van HAProxy is as gevolg van historiese redes, en ons is tans besig om na ProxySQL te migreer.

Replikasie word uitgevoer in semi-sinchroniese modus gebaseer op GTID. Dit beteken dat ten minste een replika 'n transaksie moet aanteken voordat dit as suksesvol beskou word. Hierdie replikasiemodus bied 'n optimale balans tussen werkverrigting en dataveiligheid in die geval van 'n meesterknooppuntfout. Basies word alle veranderinge oorgedra van die meester na die replikas wat gebruik word Row Based Replication (RBR), maar sommige nodusse kan hê mixed binlog format.

Die orkestreerder dateer periodiek die toestand van die klustertopologie op, ontleed die inligting wat ontvang is, en as probleme opduik, kan dit 'n outomatiese herstelprosedure begin. Die ontwikkelaar is verantwoordelik vir die prosedure self, aangesien dit op verskillende maniere geïmplementeer kan word: gebaseer op VIP, DNS, met behulp van diensontdekkingsdienste of selfgeskrewe meganismes.

Een eenvoudige manier om 'n meester te herstel as dit misluk, is om drywende BBP-adresse te gebruik.

Wat jy oor hierdie oplossing moet weet voordat jy vorentoe beweeg:

• 'n VIP is 'n IP-adres wat nie met 'n spesifieke fisiese netwerkkoppelvlak geassosieer word nie. As 'n nodus misluk of tydens geskeduleerde instandhouding, kan ons die VIP na 'n ander hulpbron oorskakel met minimale stilstand.
• Die vrystelling en uitreik van 'n virtuele IP-adres is 'n goedkoop en vinnige operasie.
• Om met VIP te werk, benodig jy toegang tot die bediener via SSH, of die gebruik van spesiale nutsprogramme, byvoorbeeld, keepalived.

Kom ons kyk na moontlike probleme met ons towenaar en stel ons voor hoe die outomatiese herstelmeganisme moet werk.

Netwerkverbinding met die meester het verdwyn, of 'n probleem het op hardewarevlak ontstaan, en die bediener is nie beskikbaar nie

1. Die orkestreerder werk die groeptopologie op, elke replika rapporteer dat die meester nie beskikbaar is nie. Die orkeseerder begin die proses om 'n replika te kies wat geskik is vir die rol van die nuwe meester en begin met herstel.
2. Ons probeer om die VIP van die ou meester te verwyder - sonder sukses.
3. Die replika skakel oor na die rol van meester. Die topologie word herbou.
4. Voeg 'n nuwe netwerkkoppelvlak by met VIP. Aangesien dit nie moontlik was om die VIP te verwyder nie, begin ons gereeld 'n versoek in die agtergrond stuur gratis ARP. Hierdie tipe versoek/antwoord laat jou toe om die IP- en MAC-adres-karteringstabel op die gekoppelde skakelaars op te dateer, en sodoende jou in kennis stel dat ons VIP verskuif het. Dit verminder die waarskynlikheid split brain by die terugkeer van die ou meester.
5. Alle nuwe verbindings word onmiddellik na die nuwe meester herlei. Ou verbindings misluk en herhaalde oproepe na die databasis word op toepassingsvlak gemaak.

Die bediener werk in normale modus, 'n fout het op die DBMS-vlak voorgekom

Die algoritme is soortgelyk aan die vorige geval: die opdatering van die topologie en die begin van die herstelproses. Aangesien die bediener beskikbaar is, stel ons die VIP suksesvol op die ou meester vry, dra dit oor na die nuwe een en stuur verskeie ARP-versoeke. Die moontlike terugkeer van die ou meester behoort nie die herboude kluster en die werking van die toepassing te beïnvloed nie.

Ander probleme

Mislukking van replikas of intermediêre meesters lei nie tot outomatiese aksies en vereis handmatige ingryping.

'n Virtuele netwerkkoppelvlak word altyd tydelik bygevoeg, dit wil sê, na 'n bediener herlaai word die VIP nie outomaties toegewys nie. Elke databasis-instansie begin by verstek in leesalleen-modus, die orkeseerder skakel outomaties die nuwe meester oor om te skryf en probeer installeer read only op die ou meester. Hierdie aksies is daarop gemik om die waarskynlikheid te verminder split brain.

Probleme kan tydens die herstelproses ontstaan, wat benewens standaard moniteringsnutsmiddels ook deur die orkestreerder-UI in kennis gestel moet word. Ons het die REST API uitgebrei deur hierdie kenmerk by te voeg (PR tans hersien word).

Die algemene diagram van die HA-oplossing word hieronder aangebied.

Die keuse van 'n nuwe meester

Die orkeseerder is slim genoeg en probeer kies die mees geskikte replika as 'n nuwe meester volgens die volgende kriteria:

• die replika bly agter die meester;
• MySQL weergawe van meester en replika;
• replikasie tipe (RBR, SBR of gemeng);
• ligging in dieselfde of verskillende datasentrums;
• beskikbaarheid errant GTID — transaksies wat op die replika uitgevoer is en nie op die meester is nie;
• persoonlike keuringsreëls word ook in ag geneem.

Nie elke leidraad is 'n ideale kandidaat vir 'n meester nie. Byvoorbeeld, 'n replika kan gebruik word om data te rugsteun, of die bediener het 'n swakker hardeware-konfigurasie. Orkesleier ondersteun handleiding reëls waarmee jy jou kandidaat seleksie voorkeure kan aanpas van mees verkies tot geïgnoreer.

Reaksie en hersteltyd

In die geval van 'n voorval, is dit belangrik om die stilstand van die stelsel tot die minimum te beperk, dus kom ons kyk na die MySQL-parameters wat die skepping en opdatering van die groeptopologie deur die orkestreerder beïnvloed:

• slave_net_timeout — die aantal sekondes waartydens die replika wag vir nuwe data of 'n hartklopsein om van die meester af te kom voordat die verbinding erken word as verlore en weer verbind. Hoe laer die waarde, hoe vinniger kan die replika bepaal dat kommunikasie met die meester verbreek is. Ons stel hierdie waarde op 5 sekondes.
• MASTER_CONNECT_RETRY — aantal sekondes tussen heraansluitingspogings. In die geval van netwerkprobleme, sal 'n lae waarde vir hierdie parameter vinnige herverbinding moontlik maak en verhoed dat die groepherstelproses begin. Die aanbevole waarde is 1 sekonde.
• MASTER_RETRY_COUNT — maksimum aantal heraansluitingspogings.
• MASTER_HEARTBEAT_PERIOD — interval in sekondes waarna die meester 'n hartklopsein stuur. Verstek tot die helfte van die waarde slave_net_timeout.

Orchestrator parameters:

• DelayMasterPromotionIfSQLThreadNotUpToDate - indien gelyk true, dan sal die meesterrol nie op die kandidaat-replika toegepas word totdat die replika se SQL-draad alle ontoegepaste transaksies vanaf die Relay Log voltooi het nie. Ons gebruik hierdie opsie om te verhoed dat transaksies verloor word wanneer alle kandidaat-replikas agter raak.
• InstancePollSeconds — frekwensie van bou en opdatering van die topologie.
• RecoveryPollSeconds — frekwensie van topologie-analise. As 'n probleem opgespoor word, word topologie-herwinning begin. Hierdie konstante, gelyk aan 1 sekonde.

Elke trosknoop word elke keer deur die orkeseerder gepeil InstancePollSeconds sekondes Wanneer 'n probleem opgespoor word, word die trostoestand gedwing opgedateer, en dan word die finale besluit geneem om herstel uit te voer. Deur met verskillende databasis- en orkestreerderparameters te eksperimenteer, kon ons die reaksie- en hersteltyd tot 30 sekondes verminder.

toetsbank

Ons het die HA-skema begin toets met die ontwikkeling van 'n plaaslike toetsbank en verdere implementering in toets- en produksieomgewings. Die plaaslike stand is ten volle geoutomatiseer gebaseer op Docker en stel jou in staat om te eksperimenteer met die konfigurasie van die orkestreerder en netwerk, die groepering van 2-3 bedieners tot 'n paar dosyn te skaal en oefeninge in 'n veilige omgewing uit te voer.

Tydens die oefeninge kies ons een van die probleem-emulasiemetodes: skiet die meester onmiddellik deur kill -9, beëindig die proses saggies en stop die bediener (docker-compose stop), simuleer netwerkprobleme met behulp van iptables -j REJECT of iptables -j DROP. Ons verwag die volgende resultate:

• die orkestreerder sal probleme met die meester opspoor en die topologie binne nie meer as 10 sekondes opdateer nie;
• die herstelprosedure sal outomaties begin: die netwerkkonfigurasie sal verander, die rol van die meester sal na die replika oorgedra word, die topologie sal herbou word;
• die nuwe meester sal skryfbaar word, lewendige replikas sal nie tydens die herbouproses verlore gaan nie;
• data sal begin om na die nuwe meester geskryf en gerepliseer te word;
• Die totale hersteltyd sal nie meer as 30 sekondes wees nie.

Soos u weet, kan die stelsel anders optree in toets- en produksieomgewings as gevolg van verskillende hardeware en netwerkkonfigurasies, verskille in sintetiese en werklike las, ens. Daarom doen ons van tyd tot tyd oefeninge in werklike toestande, en kyk hoe die stelsel optree wanneer netwerkkonneksie verloor word of die individuele dele daarvan verswak. In die toekoms wil ons 'n heeltemal identiese infrastruktuur vir beide omgewings bou en die toetsing daarvan outomatiseer.

Bevindinge

Die gesondheid van die hoofbergingstelselnodus is een van die hooftake van die SRE en bedryfspan. Die implementering van die orkestreerder en HA-oplossing gebaseer op VIP het ons toegelaat om die volgende resultate te behaal:

• betroubare opsporing van probleme met die topologie van die databasiskluster;
• outomatiese en vinnige reaksie op meesterverwante voorvalle, wat stelselstilstand verminder.

Die oplossing het egter sy beperkings en nadele:

• die skaal van die HA-skema na verskeie datasentrums sal 'n enkele L2-netwerk tussen hulle vereis;
• Voordat ons VIP op die nuwe meester toeken, moet ons dit op die ou een vrystel. Die proses is opeenvolgend, wat hersteltyd verhoog;
• die vrystelling van die VIP vereis SSH-toegang tot die bediener, of enige ander metode om afgeleë prosedures te bel. Aangesien die bediener of databasis probleme ondervind wat die herstelproses veroorsaak het, kan ons nie seker wees dat die VIP-verwydering suksesvol sal voltooi nie. En dit kan lei tot die verskyning van twee bedieners met dieselfde virtuele IP-adres en 'n probleem split brain.

Om te vermy split brain, kan jy die metode gebruik STONITH ("Skiet die ander node in die kop"), wat die probleemknoop heeltemal isoleer of deaktiveer. Daar is ander maniere om 'n groep hoë beskikbaarheid te implementeer: 'n kombinasie van VIP en DNS, diensontdekking en instaanbedienerdienste, sinchroniese replikasie en ander metodes wat hul eie nadele en voordele het.

Ek het gepraat oor ons benadering tot die skep van 'n MySQL failover-kluster. Dit is maklik om te implementeer en bied 'n aanvaarbare vlak van betroubaarheid onder huidige toestande. Soos die hele stelsel in die algemeen en infrastruktuur in die besonder ontwikkel, sal hierdie benadering ongetwyfeld ontwikkel.

Bron: will.com