Mikä tahansa suuri projekti alkoi parilla palvelimella. Aluksi oli yksi DB-palvelin, sitten siihen lisättiin orjia skaalaamaan lukemaa. Ja sitten - lopeta! On yksi isäntä, mutta on monia orjia; jos yksi orjista lähtee, kaikki on hyvin, mutta jos isäntä lähtee, se on huono: seisokit, järjestelmänvalvojat yrittävät nostaa palvelinta. Mitä tehdä? Varaa mestari. Kollegani Pavel kirjoitti jo tästä , en toista sitä. Sen sijaan kerron sinulle, miksi tarvitset ehdottomasti Orchestratorin MySQL:lle!
Aloitetaan pääkysymyksestä: "Kuinka vaihdamme koodin uuteen koneeseen, kun isäntä lähtee?"
- Pidän eniten VIP:n (Virtual IP) -järjestelmästä, puhumme siitä alla. Se on yksinkertaisin ja ilmeisin, vaikka sillä on ilmeinen rajoitus: varattavan isännän on oltava L2-segmentissä uuden koneen kanssa, eli voimme unohtaa toisen DC:n. Ja sovinnollisesti, jos noudatat sääntöä, että suuri L2 on paha, koska L2 on vain telinettä kohti ja L3 on telineiden välissä, ja sellaisessa järjestelmässä on vielä enemmän rajoituksia.
- Voit kirjoittaa DNS-nimen koodiin ja ratkaista sen /etc/hosts kautta. Itse asiassa ratkaisua ei tule. Kaavan etu: ensimmäiselle menetelmälle ei ole ominaista rajoitusta, eli on mahdollista järjestää ristikkäinen DC. Mutta sitten herää ilmeinen kysymys: kuinka nopeasti voimme toimittaa muutoksen tiedostoon /etc/hosts Puppet-Ansiblen kautta?
- Voit muuttaa toista menetelmää hieman: asenna välimuisti DNS kaikille verkkopalvelimille, jonka kautta koodi menee päätietokantaan. Voit asettaa tälle DNS-merkinnälle TTL 60:n. Vaikuttaa siltä, että jos se toteutetaan oikein, menetelmä on hyvä.
- Järjestelmä, jossa on palveluhaku, joka tarkoittaa Consulin ja etcd:n käyttöä.
- Mielenkiintoinen vaihtoehto . Sinun on reitittävä kaikki liikenne MySQL:ään ProxySQL:n kautta; ProxySQL itse voi määrittää, kuka on isäntä. Muuten, voit lukea yhdestä tämän tuotteen käyttövaihtoehdosta minun .
Orchestratorin kirjoittaja, joka työskentelee Githubissa, toteutti ensin ensimmäisen järjestelmän VIP:n kanssa ja muunsi sen sitten konsulin kanssa suunnitelmaksi.
Tyypillinen infrastruktuurin asettelu:
Kuvaan heti ilmeiset tilanteet, jotka on otettava huomioon:
- VIP-osoitetta ei tule rekisteröidä minkään palvelimen asetuksiin. Kuvitellaanpa tilanne: isäntä käynnistyi uudelleen, ja sen latautuessa Orchestrator meni vikasietotilaan ja teki yhdestä orjista isännän; sitten vanha mestari nousi, ja nyt VIP on kahdessa autossa. Tämä on huono.
- Orkesteria varten sinun on kirjoitettava käsikirjoitus vanhan mestarin ja uuden mestarin kutsumiseksi. Vanhalla masterilla täytyy ajaa ifdown ja uudella masterilla ifup vip. Olisi mukavaa sisällyttää tähän skriptiin myös se, että vikasietotilanteessa vanhan pääkytkimen portti yksinkertaisesti sammutetaan aivojen jakautumisen välttämiseksi.
- Kun Orchestrator on kutsunut komentosarjaasi poistaakseen ensin VIP:n ja/tai sammuttaakseen kytkimen portin ja sitten kutsunut VIP-korotusskriptin uudessa masterissa, älä unohda käyttää arping-komentoa kertoaksesi kaikille, että uusi VIP on nyt tässä.
- Kaikilla orjilla pitäisi olla read_only=1, ja heti kun siirrät orjan isännäksi, sen pitäisi olla read_only=0.
- Älä unohda, että jokaisesta orjasta, jonka olemme valinneet tähän, voi tulla isäntä (Orchestratorilla on koko valintamekanismi sille, mitä orjaa pitää ensinnäkin ehdokkaana uudeksi isäntäksi, mitä toiseksi ja minkä orjan pitäisi ei missään tapauksessa valita mestari). Jos orjasta tulee isäntä, niin orjan kuorma jää siihen ja isäntäkuorma lisätään, tämä on otettava huomioon.
Miksi tarvitset Orchestratoria, jos sinulla ei ole sitä?
- Orchestratorissa on erittäin käyttäjäystävällinen graafinen käyttöliittymä, joka näyttää koko topologian (katso kuvakaappaus alla).
- Orchestrator voi seurata, mitkä orjat ovat jäljessä ja missä replikointi on yleensä katkennut (Orchestratoriin on liitetty komentosarjat tekstiviestien lähettämistä varten).
- Orchestrator kertoo, millä orjilla on GTID-virhe.
Orkesterin käyttöliittymä:
Mikä on GTID virheellinen?
Orchestratorin toiminnalle on kaksi päävaatimusta:
- On välttämätöntä, että pseudoGTID on käytössä kaikissa MySQL-klusterin koneissa; meillä on käytössä GTID.
- On välttämätöntä, että kaikkialla on yhden tyyppisiä binlogeja, voit käyttää lauseketta. Meillä oli kokoonpano, jossa isännällä ja useimmilla orjilla oli Row, ja kaksi jäi historiallisesti Mixed-tilaan. Tämän seurauksena Orchestrator ei yksinkertaisesti halunnut yhdistää näitä orjia uuteen isäntään.
Muista, että tärkein asia tuotantoorjassa on sen johdonmukaisuus isäntälle! Jos Global Transaction ID (GTID) on käytössä sekä isäntä- että orjalaitteessa, voit käyttää gtid_subset-funktiota selvittääksesi, onko näissä koneissa todella suoritettu samoja tietojen muutospyyntöjä. Voit lukea tästä lisää .
Siten Orchestrator näyttää sinulle GTID-virheen kautta, että orjassa on tapahtumia, jotka eivät ole isännässä. Miksi tämä tapahtuu?
- Read_only=1 ei ole käytössä orjassa, joku on muodostanut yhteyden ja suorittanut tietojen muutospyynnön.
- Super_read_only=1 ei ole käytössä orjassa, niin admin hämmentyi palvelimen, meni sisään ja suoritti pyynnön siellä.
- Jos otit huomioon molemmat edelliset kohdat, on vielä yksi temppu: MySQL:ssä binlogien tyhjennyspyyntö menee myös binlogiin, joten ensimmäisellä huuhtelukerralla GTID-virhe ilmestyy isännälle ja kaikille orjille. Kuinka välttää tämä? Perona-5.7.25-28 esitteli binlog_skip_flush_commands=1-asetuksen, joka estää tyhjennyskirjoituksen binlogeihin. Mysql.com-sivustolla on perustettu .
Sallikaa minun tehdä yhteenveto kaikesta yllä olevasta. Jos et vielä halua käyttää Orchestratoria vikasietotilassa, aseta se tarkkailutilaan. Silloin sinulla on aina silmiesi edessä kartta MySQL-koneiden vuorovaikutuksesta ja visuaalista tietoa siitä, minkä tyyppistä replikointia kussakin koneessa on, ovatko orjat jäljessä ja mikä tärkeintä, kuinka johdonmukaisia ne ovat isäntäkoneen kanssa!
Ilmeinen kysymys kuuluu: "Kuinka Orchestratorin pitäisi toimia?" Hänen on valittava uusi isäntä nykyisten orjien joukosta ja kytkettävä sitten kaikki orjat siihen uudelleen (tähän varten GTID tarvitaan; jos käytät vanhaa mekanismia binlog_name ja binlog_pos kanssa, niin orja vaihdetaan nykyisestä isännästä uuteen on yksinkertaisesti mahdotonta!). Ennen kuin meillä oli Orchestrator, minun piti kerran tehdä tämä kaikki manuaalisesti. Vanha isäntä roikkui bugisen Adaptec-ohjaimen takia; siinä oli noin 10 orjaa. Minun piti siirtää VIP isännältä yhdelle orjalaitteista ja yhdistää kaikki muut orjat siihen. Kuinka monta konsolia minun piti avata, kuinka monta komentoa samanaikaisesti annoin... Minun piti odottaa kolmeen aamulla, poistaa kuorma kaikista orjista paitsi kahdesta, tehdä ensimmäinen kone kahdesta isännästä, kiinnittää heti toinen kone siihen, joten kiinnitä kaikki muut orjat uuteen isäntään ja palauta kuorma. Kaiken kaikkiaan kauheaa...
Miten Orchestrator toimii, kun se menee vikasietotilaan? Tätä havainnollistaa helpoimmin esimerkki tilanteesta, jossa haluamme tehdä mestarista tehokkaamman, nykyaikaisemman koneen.
Kuvassa näkyy prosessin puoliväli. Mitä on jo tehty tähän mennessä? Sanoimme, että halusimme tehdä jostakin orjasta uudeksi isännäksi, Orchestrator alkoi yksinkertaisesti yhdistää kaikki muut orjat siihen, ja uusi isäntä toimi siirtokoneena. Tällä mallilla ei tapahdu virheitä, kaikki orjat toimivat, Orchestrator poistaa VIP:n vanhasta isännästä, siirtää sen uuteen, tekee read_only=0:n ja unohtaa vanhan isäntälaitteen. Kaikki! Palvelumme seisokkiaika on VIP-siirtoaika, joka on 2-3 sekuntia.
Siinä kaikki tälle päivälle, kiitos kaikille. Orchestratorista tulee pian toinen artikkeli. Kuuluisassa Neuvostoliiton elokuvassa "Garage" yksi hahmo sanoi: "En lähtisi tiedustelulle hänen kanssaan!" Joten, orkesteri, menisin kanssasi tiedustelulle!
Lähde: will.com