Käytämme Citymobilissa MySQL-tietokantaa pääasiallisena pysyvänä tallennusvälineenä. Meillä on useita tietokantaklustereita erilaisiin palveluihin ja tarkoituksiin.

Masterin jatkuva saatavuus on kriittinen indikaattori koko järjestelmän ja sen yksittäisten osien suorituskyvystä. Automaattinen klusterin palautus isäntävian sattuessa lyhentää huomattavasti tapauksen vasteaikaa ja järjestelmän seisokkeja. Tässä artikkelissa tarkastelen korkean käytettävyyden (HA) suunnittelua MySQL-klusterille, joka perustuu MySQL Orchestrator ja virtuaaliset IP-osoitteet (VIP).

VIP-pohjainen HA-ratkaisu

Ensin kerron lyhyesti, mikä on tietojen tallennusjärjestelmämme.

Käytämme klassista replikointimallia, jossa on yksi kirjoituskelpoinen isäntä ja useita vain luku -kopioita. Klusteri voi sisältää välipään - solmun, joka on sekä replika että isäntä muille. Asiakkaat voivat käyttää replikoita HAProxyn kautta, mikä mahdollistaa tasaisen kuorman jakautumisen ja helpon skaalauksen. HAProxyn käyttö johtuu historiallisista syistä, ja olemme parhaillaan siirtymässä ProxySQL:ään.

Replikointi suoritetaan puolisynkronisessa tilassa, joka perustuu GTID. Tämä tarkoittaa, että vähintään yhden replikan on kirjattava tapahtuma ennen kuin se katsotaan onnistuneeksi. Tämä replikointitila tarjoaa optimaalisen tasapainon suorituskyvyn ja tietoturvan välillä pääsolmun vian sattuessa. Periaatteessa kaikki muutokset siirretään isäntäkoneesta replikoihin käyttämällä Row Based Replication (RBR), mutta joissakin solmuissa voi olla mixed binlog format.

Orkesteri päivittää ajoittain klusterin topologian tilan, analysoi vastaanotetut tiedot ja voi käynnistää automaattisen palautusprosessin, jos ilmenee ongelmia. Kehittäjä on vastuussa itse prosessista, koska se voidaan toteuttaa eri tavoin: VIP-, DNS-pohjaisesti, käyttämällä palveluiden etsintäpalveluita tai itse kirjoitettuja mekanismeja.

Yksi yksinkertainen tapa palauttaa isäntä, jos se epäonnistuu, on käyttää kelluvia VIP-osoitteita.

Mitä sinun on tiedettävä tästä ratkaisusta ennen kuin jatkat:

• VIP on IP-osoite, jota ei ole liitetty tiettyyn fyysiseen verkkoliitäntään. Jos solmu epäonnistuu tai ajoitetun huollon aikana, voimme vaihtaa VIP:n toiseen resurssiin minimaalisella seisokkiajalla.
• Virtuaalisen IP-osoitteen vapauttaminen ja myöntäminen on halpa ja nopea toimenpide.
• Jotta voit työskennellä VIP:n kanssa, tarvitset pääsyn palvelimeen SSH:n kautta tai erikoisapuohjelmien käyttöä, esim. keepalived.

Tarkastellaan mahdollisia ongelmia ohjatun toiminnon kanssa ja kuvitellaan, kuinka automaattisen palautusmekanismin pitäisi toimia.

Verkkoyhteys isäntäkoneeseen on kadonnut tai laitteistotasolla on ilmennyt ongelma ja palvelin ei ole käytettävissä

1. Orkesteri päivittää klusterin topologian, ja jokainen replika ilmoittaa, että isäntä ei ole käytettävissä. Orkesteri aloittaa uuden päällikön rooliin sopivan replikan valintaprosessin ja aloittaa palautumisen.
2. Yritämme poistaa VIP:n vanhasta mestarista - tuloksetta.
3. Replika siirtyy päällikön rooliin. Topologiaa rakennetaan uudelleen.
4. Uuden verkkoliittymän lisääminen VIP:n kanssa. Koska VIP:n poistaminen ei ollut mahdollista, alamme ajoittain lähettää pyyntöä taustalla maksuton ARP. Tämän tyyppisen pyynnön/vastauksen avulla voit päivittää IP- ja MAC-osoitteiden kartoitustaulukon liitettyihin kytkimiin ja ilmoittaa näin VIP-sivustomme muuttamisesta. Tämä minimoi todennäköisyyden split brain kun palaat vanhan mestarin.
5. Kaikki uudet yhteydet ohjataan välittömästi uudelle isännälle. Vanhat yhteydet epäonnistuvat ja toistuvia kutsuja tietokantaan tehdään sovellustasolla.

Palvelin toimii normaalitilassa, DBMS-tasolla tapahtui virhe

Algoritmi on samanlainen kuin edellisessä tapauksessa: päivitetään topologia ja aloitetaan palautusprosessi. Koska palvelin on saatavilla, vapautamme onnistuneesti VIP:n vanhalla isännällä, siirrämme sen uuteen ja lähetämme useita ARP-pyyntöjä. Vanhan masterin mahdollisen palautuksen ei pitäisi vaikuttaa uudelleen rakennettuun klusteriin ja sovelluksen toimintaan.

Muita ongelmia

Jäljennösten tai keskitason masterien epäonnistuminen ei johda automaattisiin toimiin ja vaatii manuaalista puuttumista.

Virtuaalinen verkkoliitäntä lisätään aina tilapäisesti, eli palvelimen uudelleenkäynnistyksen jälkeen VIP-osoitetta ei määritetä automaattisesti. Jokainen tietokanta-ilmentymä käynnistyy oletusarvoisesti vain luku -tilassa, järjestäjä vaihtaa automaattisesti uuden isäntäkoneen kirjoittamaan ja yrittää asentaa read only vanhan mestarin päälle. Näillä toimilla pyritään vähentämään todennäköisyyttä split brain.

Palautusprosessin aikana saattaa ilmetä ongelmia, joista tulee ilmoittaa myös orkesterin käyttöliittymän kautta standardien valvontatyökalujen lisäksi. Olemme laajentaneet REST-sovellusliittymää lisäämällä tämän ominaisuuden (PR parhaillaan tarkistettavana).

HA-ratkaisun yleinen kaavio on esitetty alla.

Uuden mestarin valinta

Orkesteri on tarpeeksi älykäs ja yrittää valita sopivin kopio uutena mestarina seuraavien kriteerien mukaan:

• jäljennös on jäljessä isännästä;
• Master- ja replikan MySQL-versio;
• replikointityyppi (RBR, SBR tai sekoitettu);
• sijainti samassa tai eri tietokeskuksissa;
• saatavuus errant GTID — tapahtumat, jotka suoritettiin replikalla ja jotka eivät ole isäntäkoneessa;
• mukautetut valintasäännöt otetaan myös huomioon.

Jokainen vihje ei ole ihanteellinen ehdokas mestariksi. Esimerkiksi kopiota voidaan käyttää tietojen varmuuskopiointiin tai palvelimella on heikompi laitteistokokoonpano. Orkesteri tukee manuaaliset säännöt, joiden avulla voit mukauttaa ehdokkaiden valintaasetuksiasi suosituimmasta huomioimatta.

Vastaus- ja palautumisaika

Tapahtumatapauksessa on tärkeää minimoida järjestelmän seisokkiaika, joten tarkastellaan MySQL-parametreja, jotka vaikuttavat järjestäjän suorittamaan klusterin topologian luomiseen ja päivittämiseen:

• slave_net_timeout — kuinka monta sekuntia replika odottaa uutta dataa tai sykesignaalia isäntälaitteelta, ennen kuin yhteys tunnistetaan kadonneeksi ja se yhdistetään uudelleen. Mitä pienempi arvo, sitä nopeammin replika voi määrittää, että yhteys isäntäkoneen kanssa on katkennut. Asetamme tämän arvon 5 sekuntiin.
• MASTER_CONNECT_RETRY — uudelleenkytkentäyritysten välinen sekuntimäärä. Verkko-ongelmissa tämän parametrin pieni arvo mahdollistaa nopean yhteyden muodostamisen ja estää klusterin palautusprosessin alkamisen. Suositeltu arvo on 1 sekunti.
• MASTER_RETRY_COUNT — uudelleenkytkentäyritysten enimmäismäärä.
• MASTER_HEARTBEAT_PERIOD — intervalli sekunneissa, jonka jälkeen isäntä lähettää sykesignaalin. Oletusarvo on puolet arvosta slave_net_timeout.

Orkesterin parametrit:

• DelayMasterPromotionIfSQLThreadNotUpToDate - jos yhtä suuri true, silloin pääroolia ei käytetä ehdokasreplikassa ennen kuin replikan SQL-säie on suorittanut kaikki käyttämättömät tapahtumat välityslokista. Käytämme tätä vaihtoehtoa välttääksemme tapahtumien menettämisen, kun kaikki ehdokaskopiot jäävät jälkeen.
• InstancePollSeconds — topologian rakentamisen ja päivittämisen tiheys.
• RecoveryPollSeconds — topologia-analyysin tiheys. Jos ongelma havaitaan, topologian palautus käynnistetään. Tämä vakio, yhtä sekuntia.

Orkestori pollaa jokaisen klusterin solmun kerran joka kerta InstancePollSeconds sekuntia Kun ongelma havaitaan, klusterin tila pakotetaan päivitetty, ja sitten tehdään lopullinen päätös palautuksen suorittamisesta. Kokeilemalla erilaisia ​​tietokanta- ja orkestrointiparametreja pystyimme lyhentämään vaste- ja palautumisaikaa 30 sekuntiin.

Testiteline

Aloitimme HA-järjestelmän testaamisen paikallisen kehittämisellä testipenkki ja jatkokäyttöönotto testi- ja tuotantoympäristöissä. Paikallinen osasto on täysin automatisoitu Dockeriin perustuen, ja sen avulla voit kokeilla orkestraattorin ja verkon konfiguraatiota, skaalata klusterin 2-3 palvelimesta useisiin kymmeniin ja suorittaa harjoituksia turvallisessa ympäristössä.

Harjoitusten aikana valitsemme yhden ongelman emulointimenetelmistä: ammutaan mestari heti käyttämällä kill -9, lopeta prosessi pehmeästi ja pysäytä palvelin (docker-compose stop), simuloi verkko-ongelmia käyttämällä iptables -j REJECT tai iptables -j DROP. Odotamme seuraavia tuloksia:

• orkesteri havaitsee ongelmat masterissa ja päivittää topologian enintään 10 sekunnissa;
• palautusmenettely käynnistyy automaattisesti: verkon kokoonpano muuttuu, isäntälaitteen rooli siirtyy replikalle, topologia rakennetaan uudelleen;
• uusi master tulee kirjoitettavaksi, elävät jäljennökset eivät katoa uudelleenrakennusprosessin aikana;
• tietoja aletaan kirjoittaa uuteen isäntälaitteeseen ja replikoida;
• Kokonaispalautusaika on enintään 30 sekuntia.

Kuten tiedät, järjestelmä voi käyttäytyä eri tavalla testi- ja tuotantoympäristöissä erilaisista laitteisto- ja verkkokokoonpanoista, synteettisen ja todellisen kuormituksen eroista jne. Siksi suoritamme ajoittain harjoituksia todellisissa olosuhteissa ja tarkistamme, kuinka järjestelmä käyttäytyy, kun verkkoyhteys katkeaa tai sen yksittäiset osat ovat huonontuneet. Jatkossa haluamme rakentaa molempiin ympäristöihin täysin identtisen infrastruktuurin ja automatisoida sen testauksen.

Tulokset

Päätallennusjärjestelmän solmun kunto on yksi SRE:n ja operaatiotiimin päätavoitteista. VIP-pohjaisen orchestrator- ja HA-ratkaisun käyttöönotto mahdollisti seuraavat tulokset:

• tietokantaklusterin topologian ongelmien luotettava havaitseminen;
• automaattinen ja nopea reagointi isäntään liittyviin tapahtumiin, mikä vähentää järjestelmän seisokkeja.

Ratkaisulla on kuitenkin rajoituksensa ja haittansa:

• HA-mallin skaalaaminen useisiin tietokeskuksiin vaatii yhden L2-verkon niiden välillä;
• Ennen kuin määrität VIP:n uudelle isännälle, meidän on vapautettava se vanhassa. Prosessi on peräkkäinen, mikä lisää palautumisaikaa;
• VIP:n vapauttaminen vaatii SSH-pääsyn palvelimeen tai minkä tahansa muun etäproseduurien kutsumistavan. Koska palvelimessa tai tietokannassa on ongelmia, jotka aiheuttivat palautusprosessin, emme voi olla varmoja VIP-poiston onnistumisesta. Ja tämä voi johtaa kahden palvelimen ilmestymiseen samalla virtuaalisella IP-osoitteella ja ongelmaan split brain.

Välttää split brain, voit käyttää menetelmää STONITH ("Shoot The Other Node In The Head"), joka eristää ongelmasolmun kokonaan tai poistaa sen käytöstä. On muitakin tapoja toteuttaa klusterin korkea käytettävyys: VIP- ja DNS-yhdistelmä, palvelun etsintä- ja välityspalvelinpalvelut, synkroninen replikointi ja muut menetelmät, joilla on omat haittansa ja etunsa.

Puhuin lähestymistavastamme MySQL-virheklusterin luomiseen. Se on helppo toteuttaa ja tarjoaa hyväksyttävän luotettavuustason nykyisissä olosuhteissa. Kun koko järjestelmä yleensä ja infrastruktuuri erityisesti kehittyvät, tämä lähestymistapa epäilemättä kehittyy.

Lähde: will.com