ProHoster > Blog > Administration > Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det

Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det

Enhver stor projekt startede med et par servere. FĂžrst var der Ă©n DB-server, og sĂ„ blev der tilfĂžjet slaver for at skalere lĂŠsningen. Og her stopper det! Der er Ă©n master og mange slaver; hvis en af slaverne gĂ„r ned, er alt fint, men hvis masteren gĂ„r ned — sĂ„ bliver det problematisk: nedetid, administratorer, der sveder for at fĂ„ serveren op at kĂžre. Hvad skal man gĂžre? ReservĂ©r masteren. Min kollega Pavel har allerede skrevet om dette, artiklen, sĂ„ jeg vil ikke gentage det. I stedet vil jeg fortĂŠlle, hvorfor du absolut har brug for en Orchestrator til MySQL!

Lad os starte med det vigtigste spÞrgsmÄl: "Hvordan skifter vi koden til den nye maskine, hvis masteren gÄr ned?".

  • Skemaet med VIP (Virtual IP) kan jeg bedst lide, og det vil vi tale om nedenfor. Det er det enkleste og mest oplagte, selvom det har en klar begrĂŠnsning: den master, vi vil reservere, skal vĂŠre i L2-segmentet med den nye maskine, sĂ„ man kan glemme den anden datacenter. Og rent ud sagt, hvis man fĂžlger reglen om, at en stor L2 er en skidt idĂ©, fordi L2 kun er pristrygt, mens der er L3 mellem reolerne, sĂ„ har et sĂ„dant skema endnu flere begrĂŠnsninger.
  • Man kan skrive DNS-navnet ind i koden og oplĂžse det via /etc/hosts. I virkeligheden vil oplĂžsningen ikke finde sted. Fordelen ved skemaet: der er ingen af de begrĂŠnsninger, der kendetegner den fĂžrste metode, sĂ„ man kan ogsĂ„ organisere cross-datacenter. Men sĂ„ opstĂ„r det Ă„benlyse spĂžrgsmĂ„l, hvor hurtigt vi via Puppet-Ansible kan overfĂžre ĂŠndringen til /etc/hosts.
  • Den anden metode kan ĂŠndres en smule: pĂ„ alle webserverne installerer vi en caching DNS, som koden vil bruge til at kommunikerede med master-databasen. Man kan sĂŠtte TTL til 60 for denne post i DNS. Det virker som en god metode, hvis det implementeres korrekt.
  • Skemaet med service discovery, som involverer anvendelse af Consul og etcd.
  • En interessant mulighed med ProxySQL. Al trafik til MySQL skal gĂ„ gennem ProxySQL, som selv kan bestemme, hvem der er master lige nu. Forresten kan man lĂŠse om en af anvendelserne af dette produkt i min artikel.

Forfatteren af Orchestrator, der arbejdede i Github, implementerede fĂžrst det fĂžrste skema med VIP og derefter ĂŠndrede det til skemaet med Consul.

Typisk infrastruktur skema:

Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det
Lad mig straks beskrive de Ă„benlyse situationer, der skal overvejes:

  • VIP-adressen mĂ„ ikke vĂŠre opfĂžrt i konfigurationen pĂ„ nogen af serverne. Lad os forestille os en situation: masteren genstarter, og mens den boot'er op, gĂ„r Orchestrator over i failover-tilstand og gĂžr en af slaverne til master; derefter starter den gamle master op igen, og nu er VIP aktiv pĂ„ to maskiner. Det er skidt.
  • For the orchestrator, you will need to write a script that interacts with the old master and the new master. On the old one, you should execute ifdown, and on the new master — ifup vip. It would also be good to include in this script that in the case of failover, the port on the switch of the old master is simply turned off to avoid any split brain.
  • After the Orchestrator has invoked your script to first remove the VIP and/or turn off the port on the switch, and then on the new master called the script to bring up the VIP, do not forget to use the arping command to notify everyone that the new VIP is now here.
  • All slaves must have read_only=1, and as soon as you promote a slave to a master, it should switch to read_only=0.
  • Remember that any slave we choose can become a master (the Orchestrator has a whole mechanism for preference, which slave to consider a candidate for the new master first, which second, and which slave should definitely not be chosen as a master under any circumstances). If a slave becomes a master, its load will remain as a slave's load and the master's load will be added, which needs to be considered.

Why do you absolutely need an Orchestrator if you don't have one?

  • The Orchestrator has a very convenient graphical interface displaying the entire topology (see the screenshot below).
  • Orchestrator can monitor which slaves are lagging behind and where replication has actually failed (we have scripts attached to Orchestrator for sending SMS).
  • Orchestrator tells you which slaves have a GTID errant error.

Orchestrator Interface:

Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det
What is GTID errant?

There are two main requirements for the Orchestrator to work:

  • It is necessary that pseudo GTID is enabled on all MySQL cluster machines; we have GTID enabled.
  • It is required that there is a single type of binary logs everywhere, statement can be used. We had a configuration where the master and most slaves were using Row, while two historically remained in Mixed mode. As a result, these slaves were simply not accepted by the Orchestrator into the new master.

Remember that the most important aspect of a production slave is its consistency with the master! If both the master and the slave have Global Transaction ID (GTID) enabled, then through the gtid_subset function, you can find out if the same data modification queries have indeed been executed on these machines. More details can be read about this. her.

SÄledes viser Orchestrator dig gennem GTID-fejlen, at der er transaktioner pÄ slaven, som ikke findes pÄ masteren. Hvordan kan dette ske?

  • Read_only=1 er ikke aktiveret pĂ„ slaven, sĂ„ en bruger har tilsluttet sig og udfĂžrt en ĂŠndringsanmodning.
  • Super_read_only=1 er ikke aktiveret pĂ„ slaven, derfor er admin, forvekslende serverne, gĂ„et ind og udfĂžrt en anmodning der.
  • Hvis du har taget begge de foregĂ„ende punkter i betragtning, er der endnu en finurlighed: i MySQL registreres anmodningen om at flush binlogs ogsĂ„ i binloggen, sĂ„ ved den fĂžrste flush pĂ„ masteren og pĂ„ alle slaver vil der opstĂ„ en GTID-fejl. Hvordan undgĂ„r man dette? I versionen perona-5.7.25-28 er der en indstilling, binlog_skip_flush_commands=1, som forbyder at skrive flush til binloggerne. Der findes mere information pĂ„ mysql.com. fejl i projektet Chromium.

For at opsummere alt det ovenstĂ„ende. Hvis du endnu ikke Ăžnsker at bruge Orchestrator i failover-tilstand, sĂ„ sĂŠt det i overvĂ„gningsmodus. SĂ„ vil du altid have et overblik over interaktionerne mellem MySQL-maskinerne og visuel information om, hvilken type replikation der er pĂ„ hver maskine, om slaver er forsinkede, og vigtigst af alt — hvor konsistente de er med masteren!

Et Ă„benlyst spĂžrgsmĂ„l: „Hvordan skal Orchestrator fungere?“. Den skal vĂŠlge en ny master blandt de nuvĂŠrende slaver, og derefter genforbinde alle slaver til den (det er netop derfor GTID er nĂždvendigt; hvis man bruger den gamle mekanisme med binlog_name og binlog_pos, sĂ„ er det simpelthen umuligt at skifte en slave fra den nuvĂŠrende master til den nye!). FĂžr vi fik Orchestrator, mĂ„tte jeg en gang gĂžre alt dette manuelt. Den gamle master frĂžs pĂ„ grund af en defekt Adaptec-controller, og der var omkring 10 slaver. Jeg mĂ„tte flytte VIP fra masteren til en af slaverne og genforbinde alle de Ăžvrige slaver til den. Hvor mange konsoller mĂ„tte jeg Ă„bne, hvor mange samtidige kommandoer skulle jeg indtaste ... Jeg mĂ„tte vente indtil klokken 3 om natten, lette belastningen pĂ„ alle slaver, undtagen to, gĂžre den fĂžrste maskine til master, straks tilslutte den anden maskine, sĂ„ tilslutte alle andre slaver til den nye master og genoprette belastningen. Alt i alt, et mareridt ...

Hvordan fungerer Orchestrator, nÄr den skifter til failover-tilstand? Det er nemmest at vise ved at tage udgangspunkt i en situation, hvor vi Þnsker at gÞre en mere kraftfuld og moderne maskine til master i stedet for den nuvÊrende.

Orchestrator til MySQL: hvorfor det er umuligt at bygge et fejltolerant projekt uden det
Illustrationen viser midten af processen. Hvad er allerede blevet gjort pÄ dette tidspunkt? Vi sagde, at vi Þnskede at gÞre en slave til en ny master, Orchestrator begyndte bare at genkoble alle andre slaver til den, mens den nye master fungerer som en transitmaskine. I et sÄdant setup opstÄr der ikke fejl, alle slaver fungerer, Orchestrator tager VIP fra den gamle master, flytter det til den nye, sÊtter read_only=0 og glemmer den gamle master. SÄdan! Nedetiden for vores service er tiden til at flytte VIP, det tager 2-3 sekunder.

Det var alt for i dag, tak allesammen. Snart kommer den anden artikel om Orchestrator. I den velkendte sovjetiske film "Garagen" sagde en karakter: "Jeg ville ikke gÄ i rekognoscering med ham!" SÄ ja, Orchestrator, jeg ville gÄ i rekognoscering med dig!

Kilde: habr.com

KĂžb pĂ„lidelig webhosting med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KĂžb pĂ„lidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster