Elk groot project begon met een paar servers. In eerste instantie was er één DB-server, daarna werden er slaven aan toegevoegd om de uitlezing te schalen. En dan - stop! Er is één meester, maar er zijn veel slaven; als een van de slaven vertrekt, komt alles goed, maar als de meester vertrekt, zal het slecht zijn: downtime, beheerders proberen de server te verhogen. Wat moeten we doen? Reserveer een meester. Mijn collega Pavel schreef hier al over , ik zal het niet herhalen. In plaats daarvan zal ik je vertellen waarom je Orchestrator voor MySQL absoluut nodig hebt!
Laten we beginnen met de hoofdvraag: "Hoe gaan we de code overzetten naar een nieuwe machine als de meester vertrekt?"
- Ik vind het schema met VIP (Virtueel IP) het leukst, we zullen er hieronder over praten. Het is de eenvoudigste en meest voor de hand liggende, hoewel het een duidelijke beperking heeft: de master die we zullen reserveren moet zich met de nieuwe machine in het L2-segment bevinden, dat wil zeggen dat we de tweede DC kunnen vergeten. En, op een minnelijke manier, als je de regel volgt dat een grote L2 slecht is, omdat L2 alleen per rack is en L3 zich tussen de racks bevindt, en een dergelijk schema nog meer beperkingen kent.
- U kunt een DNS-naam in de code schrijven en deze oplossen via /etc/hosts. Er zal feitelijk geen oplossing komen. Het voordeel van het schema: er is geen beperking die kenmerkend is voor de eerste methode, dat wil zeggen dat het mogelijk is om een cross-DC te organiseren. Maar dan rijst de voor de hand liggende vraag: hoe snel kunnen we de wijziging via Puppet-Ansible aan /etc/hosts bezorgen?
- Je kunt de tweede methode een beetje veranderen: installeer caching DNS op alle webservers, via welke de code naar de hoofddatabase gaat. U kunt voor deze invoer TTL 60 instellen in DNS. Het lijkt erop dat de methode, mits correct geïmplementeerd, goed is.
- Een schema met servicedetectie, waarbij gebruik wordt gemaakt van Consul en etcd.
- Een interessante optie met . U moet al het verkeer via ProxySQL naar MySQL leiden; ProxySQL kan zelf bepalen wie de master is. Over een van de mogelijkheden om dit product te gebruiken kun je overigens lezen in mijn .
De auteur van Orchestrator, werkzaam in Github, implementeerde eerst het eerste schema met VIP en zette het vervolgens om naar een schema met consul.
Typische infrastructuurindeling:
Ik zal onmiddellijk de voor de hand liggende situaties beschrijven waarmee rekening moet worden gehouden:
- Het VIP-adres mag op geen enkele server worden geregistreerd in de configuratie. Laten we ons een situatie voorstellen: de master startte opnieuw op en terwijl deze aan het laden was, ging Orchestrator in de failover-modus en maakte van een van de slaves een master; toen stond de oude meester op, en nu zit de VIP in twee auto's. Dit is slecht.
- Voor de orkestrator moet u een script schrijven voor het aanroepen van de oude master en de nieuwe master. Op de oude master moet je ifdown uitvoeren, en op de nieuwe master – ifup vip. Het zou leuk zijn om in dit script ook op te nemen dat in het geval van een failover de poort op de oude masterschakelaar eenvoudigweg wordt uitgeschakeld om eventuele splitbrain te voorkomen.
- Nadat Orchestrator uw script heeft aangeroepen om eerst de VIP te verwijderen en/of de poort op de switch te doven, en vervolgens het VIP-raising-script op de nieuwe master heeft aangeroepen, vergeet dan niet de opdracht arping te gebruiken om iedereen te vertellen dat de nieuwe VIP nu is hier.
- Alle slaven moeten read_only=1 hebben, en zodra u de slaaf promoveert tot master, moet deze read_only=0 hebben.
- Vergeet niet dat elke slaaf die we hiervoor hebben uitgekozen een meester kan worden (Orchestrator heeft een heel voorkeursmechanisme voor welke slaaf hij in de eerste plaats moet overwegen als kandidaat voor een nieuwe meester, welke in de tweede plaats, en welke slaaf moet onder geen enkele omstandigheid master worden geselecteerd). Als de slave master wordt dan blijft de belasting van de slave erop staan en komt de belasting van de master erbij, hier moet rekening mee gehouden worden.
Waarom heb je Orchestrator nodig als je er geen hebt?
- Orchestrator heeft een zeer gebruiksvriendelijke grafische interface die de volledige topologie weergeeft (zie onderstaande schermafbeelding).
- Orchestrator kan bijhouden welke slaves achterlopen en waar de replicatie over het algemeen is mislukt (we hebben scripts aan Orchestrator gekoppeld voor het verzenden van sms-berichten).
- Orchestrator vertelt u welke slaves een foutieve GTID hebben.
Orchestrator-interface:
Wat is GTID foutief?
Er zijn twee belangrijke vereisten voor de werking van Orchestrator:
- Het is noodzakelijk dat pseudo GTID is ingeschakeld op alle machines in het MySQL-cluster; we hebben GTID ingeschakeld.
- Het is noodzakelijk dat er overal één type binlogs is, je kunt statement gebruiken. We hadden een configuratie waarin de master en de meeste slaven Row hadden, en twee bleven historisch gezien in de Mixed-modus. Als gevolg hiervan wilde Orchestrator deze slaves simpelweg niet verbinden met de nieuwe master.
Onthoud dat het belangrijkste bij een productieslave de consistentie met de master is! Als u Global Transaction ID (GTID) hebt ingeschakeld op zowel uw master als uw slave, kunt u de functie gtid_subset gebruiken om erachter te komen of dezelfde verzoeken om gegevenswijzigingen daadwerkelijk op deze machines zijn uitgevoerd. Hier kunt u meer over lezen .
Zo laat Orchestrator u via de foutieve GTID zien dat er transacties op de slave plaatsvinden die niet op de master staan. Waarom gebeurt dit?
- Read_only=1 is niet ingeschakeld op de slave. Iemand heeft verbinding gemaakt en een verzoek om gegevens te wijzigen voltooid.
- Super_read_only=1 is niet ingeschakeld op de slaaf, waarna de beheerder, nadat hij de server in verwarring had gebracht, naar binnen ging en daar het verzoek uitvoerde.
- Als je met beide voorgaande punten rekening hebt gehouden, is er nog een truc: in MySQL gaat een verzoek om binlogs te flushen ook naar de binlog, dus bij de eerste flush verschijnt er een foutieve GTID op de master en alle slaves. Hoe kun je dit vermijden? Perona-5.7.25-28 introduceerde de instelling binlog_skip_flush_commands=1, die het schrijven van flush naar binlogs verbiedt. Er is een gevestigde versie op de website mysql.com .
Laat ik al het bovenstaande samenvatten. Als u Orchestrator nog niet in de failover-modus wilt gebruiken, zet deze dan in de observatiemodus. Dan heb je altijd een kaart voor ogen van de interactie van MySQL-machines en visuele informatie over welk type replicatie op elke machine plaatsvindt, of de slaves achterlopen en, belangrijker nog, hoe consistent ze zijn met de master!
De voor de hand liggende vraag is: “Hoe moet Orchestrator werken?” Hij moet een nieuwe master selecteren uit de huidige slaves, en vervolgens alle slaves er opnieuw mee verbinden (dit is waar GTID voor nodig is; als je het oude mechanisme met binlog_name en binlog_pos gebruikt, schakel dan een slave over van de huidige master naar een nieuwe is simpelweg onmogelijk!). Voordat we Orchestrator hadden, moest ik dit ooit allemaal handmatig doen. De oude master bleef hangen vanwege een Adaptec-controller met fouten; deze had ongeveer 10 slaves. Ik moest VIP overbrengen van de master naar een van de slaves en alle andere slaves er opnieuw op aansluiten. Hoeveel consoles moest ik openen, hoeveel gelijktijdige commando's heb ik ingevoerd... Ik moest wachten tot 3 uur 's nachts, de belasting van alle slaves verwijderen behalve twee, de eerste machine van twee master maken, onmiddellijk de tweede machine aansluiten eraan, dus koppel alle andere slaves aan de nieuwe master en breng de lading terug. Kortom, verschrikkelijk...
Hoe werkt Orchestrator wanneer deze in de failover-modus gaat? Dit wordt het gemakkelijkst geïllustreerd door een voorbeeld van een situatie waarin we van een meester een krachtigere, modernere machine willen maken dan we nu hebben.
De figuur toont het midden van het proces. Wat is er tot nu toe al gedaan? We zeiden dat we van een of andere slaaf de nieuwe master wilden maken. Orchestrator begon eenvoudigweg alle andere slaven er opnieuw mee te verbinden, waarbij de nieuwe master als doorvoermachine fungeerde. Met dit schema treden er geen fouten op, werken alle slaves, Orchestrator verwijdert de VIP van de oude master, draagt deze over naar de nieuwe, maakt read_only=0 en vergeet de oude master. Alle! De downtime van onze service is de VIP-overdrachtstijd, deze bedraagt 2-3 seconden.
Dat was alles voor vandaag, bedankt allemaal. Binnenkort verschijnt er een tweede artikel over Orchestrator. In de beroemde Sovjetfilm ‘Garage’ zei een personage: ‘Ik zou niet met hem op verkenning gaan!’ Dus, Orchestrator, ik zou met je meegaan op verkenning!
Bron: www.habr.com