ProHoster > Blogg > Administration > Orchestrator för MySQL: varför det inte gÄr att bygga ett hög tillgÀnglighetsprojekt utan det

Orchestrator för MySQL: varför det inte gÄr att bygga ett hög tillgÀnglighetsprojekt utan det

Varje stort projekt börjar med ett par servrar. Först fanns det en databasserver, sedan lades ytterligare slavar till för att skala lĂ€sningen. Och hĂ€r — stopp! Det finns en master och mĂ„nga slavar; om en av slavarna gĂ„r ner Ă€r det okej, men om mastern gĂ„r ner — dĂ„ blir det problem: driftstopp, administratörer stĂ„r med huvudet i hĂ€nderna för att Ă„terstĂ€lla servern. Vad ska vi göra? Reservkopiera mastern. Min kollega Pavel har redan skrivit om detta. artikeln, jag kommer inte att upprepa det. IstĂ€llet kommer jag att berĂ€tta varför du absolut behöver Orchestrator för MySQL!

LÄt oss börja med den viktigaste frÄgan: "Hur ska vi vÀxla koden till den nya maskinen nÀr mastern gÄr ner?".

  • Schemat med VIP (Virtual IP) gillar jag mest, och det Ă€r det vi kommer att diskutera nedan. Det Ă€r det enklaste och mest uppenbara, Ă€ven om det har en tydlig begrĂ€nsning: den master som vi ska reservkopiera mĂ„ste ligga inom L2-segmentet med den nya maskinen, vilket innebĂ€r att den andra datacentret kan glömmas. Dessutom, om man ska vara Ă€rlig, om man följer regeln att stora L2 Ă€r ont, eftersom L2 bara Ă€r pĂ„ stativet, och mellan stativen L3, sĂ„ har detta schema Ă€nnu fler begrĂ€nsningar.
  • Man kan ange DNS-namnet i koden och lösa det via /etc/hosts. I verkligheten kommer dock ingen lösning att ske. Fördel med schemat: det finns ingen av dessa begrĂ€nsningar som kĂ€nnetecknar den första metoden, sĂ„ man kan Ă€ven skapa en cross-Datacenter lösning. Men dĂ„ uppkommer den uppenbara frĂ„gan, hur snabbt vi genom Puppet-Ansible kan leverera förĂ€ndringen i /etc/hosts.
  • Man kan Ă€ndra den andra metoden lite: pĂ„ alla webbservrar installerar vi en cache-DNS, genom vilken koden ska gĂ„ till master-databasen. Man kan ange TTL 60 för denna post i DNS. Det verkar som en bra metod om den implementeras korrekt.
  • Schemat med service discovery som involverar anvĂ€ndningen av Consul och etcd.
  • En intressant variant med ProxySQL. All trafik till MySQL behöver gĂ„ genom ProxySQL, som sjĂ€lv kan avgöra vem som för nĂ€rvarande Ă€r master. För övrigt, om en av anvĂ€ndningarna av denna produkt kan lĂ€sas i min artikeln.

Författaren av Orchestrator, jobbade pÄ Github, implementerade först det första schemat med VIP, och sedan Àndrade han till schemat med Consul.

Typiskt schema för infrastruktur:

Orchestrator för MySQL: varför det inte gÄr att bygga ett hög tillgÀnglighetsprojekt utan det
LÄt mig omedelbart beskriva uppenbara situationer som mÄste beaktas:

  • VIP-adressen fĂ„r inte anges i konfigurationen pĂ„ nĂ„gon av servrarna. FörestĂ€ll dig situationen: mastern startades om, och medan den bootar, har Orchestrator gĂ„tt över till failover-lĂ€ge och gjort en av slavarna till master; sedan startar den gamla mastern igen, och nu har vi VIP pĂ„ tvĂ„ maskiner. Det Ă€r dĂ„ligt.
  • För orkestatorn behöver du skriva ett skript som kontaktar den gamla mastern och den nya mastern. PĂ„ den gamla mĂ„ste ifdown köras, medan ifup vip ska köras pĂ„ den nya mastern. Det vore bra att ocksĂ„ inkludera i detta skript att, vid failover, porten pĂ„ switchen till den gamla mastern stĂ€ngs för att undvika nĂ„gon splitbrain.
  • Efter att Orchestrator har kallat ditt skript för att först ta bort VIP och/eller stĂ€nga porten pĂ„ switchen, och dĂ€refter kalla skriptet för att aktivera VIP pĂ„ den nya mastern, glöm inte att anvĂ€nda kommandot arping för att informera alla om att den nya VIP nu Ă€r hĂ€r.
  • Alla slavar ska ha read_only=1, och sĂ„ snart du gör en slav till master, ska den ha read_only=0.
  • Kom ihĂ„g att vilken slav som helst som vi vĂ€ljer för detta kan bli master (Orchestrator har en mekanism för att prioritera vilken slav som ska bli ny master först, vilken andra och vilken slav som under inga omstĂ€ndigheter ska bli vald som master). Om en slav blir master, sĂ„ kommer den ha lasten av slaven och dessutom lagt till lasten av mastern, vilket mĂ„ste beaktas.

Varför behöver du Orchestrator, om du inte har en?

  • Orchestrator har ett mycket anvĂ€ndarvĂ€nligt grĂ€nssnitt som visar hela topologin (se skĂ€rmdumpen nedan).
  • Orchestrator kan övervaka vilka slavar som har fördröjning och var replikeringen har brutit samman (vi har skript anslutna till Orchestrator för att skicka SMS).
  • Orchestrator informerar dig om vilka slavar som har ett fel GTID errant.

Orchestrator-grÀnssnittet:

Orchestrator för MySQL: varför det inte gÄr att bygga ett hög tillgÀnglighetsprojekt utan det
Vad Àr GTID errant?

Det finns tvÄ grundlÀggande krav för att Orchestrator ska fungera:

  • Det mĂ„ste vara aktiverat pseudo GTID pĂ„ alla maskiner i MySQL-klustret, och vi har GTID aktiverat.
  • Det mĂ„ste finnas en typ av binlogs överallt, gĂ€rna statement. Vi hade en sĂ„dan konfiguration dĂ€r mastern och de flesta slavar hade Row, medan tvĂ„ historiskt hade Mixed-lĂ€get. Som ett resultat ville Orchestrator helt enkelt inte ansluta dessa slavar till den nya mastern.

Kom ihÄg att det viktigaste pÄ en production-slav Àr dess konsistens med mastern! Om bÄde mastern och slaven har Global Transaction ID (GTID) aktiverat, kan man med funktionen gtid_subset ta reda pÄ om samma förÀndringsförfrÄgningar faktiskt har utförts pÄ dessa maskiner. Du kan lÀsa mer om detta. ). Ett typiskt exempel pÄ anvÀndning:.

PÄ sÄ sÀtt visar Orchestrator genom GTID-felmeddelandet att det finns transaktioner pÄ slaven som inte finns pÄ mastern. Hur kan detta hÀnda?

  • PĂ„ slaven Ă€r read_only=1 inte aktiverat, nĂ„gon har anslutit och utfört en databasĂ€ndringsfrĂ„ga.
  • PĂ„ slaven Ă€r super_read_only=1 inte aktiverat, sĂ„ en administratör kan ha förvĂ€xlat servrar och utfört en frĂ„ga dĂ€r.
  • Om du har beaktat de tvĂ„ tidigare punkterna finns det en annan finess: i MySQL registreras ocksĂ„ frĂ„gan om att tömma binloggar i binloggen, sĂ„ vid första flush pĂ„ mastern och pĂ„ alla slavar kommer GTID-felmeddelandet att visas. Hur kan man undvika detta? I perona-5.7.25-28 introducerades instĂ€llningen binlog_skip_flush_commands=1, som förhindrar att flush skrivs i binloggar. PĂ„ mysql.com finns det en uppteckning. bugg.

Sammanfattningsvis allt ovanstĂ„ende. Om du Ă€nnu inte vill anvĂ€nda Orchestrator i failover-lĂ€ge, sĂ€tt det dĂ„ i bevakningslĂ€ge. DĂ„ har du alltid en karta över interaktionen mellan MySQL-maskiner framför dig och tydlig information om vilken typ av replikering som finns pĂ„ varje maskin, om slavar ligger efter och viktigast av allt — hur konsistent de Ă€r med mastern!

En uppenbar frÄga: "Hur ska Orchestrator fungera?" Den ska vÀlja en ny master bland de nuvarande slavarna och sedan Äteransluta alla slavar till den (detta Àr anledningen till att GTID behövs; om man anvÀnder den gamla mekanismen med binlog_name och binlog_pos Àr det helt omöjligt att byta slav frÄn nuvarande master till en ny!). Före Orchestrators tid var jag tvungen att göra allt detta manuellt en gÄng. Den gamla mastern hÀngde sig pÄ grund av en buggig Adaptec-kontroll, och den hade cirka 10 slavar. Jag behövde flytta VIP frÄn mastern till en av slavarna och Äteransluta alla andra slavar dit. Hur mÄnga konsoler fick jag inte öppna, hur mÄnga kommandon fick jag inte skriva in samtidigt... Jag fick vÀnta till klockan 03:00, avlasta alla slavar utom tvÄ, göra den första maskinen till master av de tvÄ, koppla den andra direkt till den, sÄ att alla andra slavar Äteransluts till den nya mastern och belastningen ÄterstÀlls. I allmÀnhet, hemskt...

Hur fungerar Orchestrator nÀr den gÄr in i failover-lÀge? Det Àr enklast att visa med ett exempel dÀr vi vill göra en kraftfullare och modernare maskin till master Àn den vi har just nu.

Orchestrator för MySQL: varför det inte gÄr att bygga ett hög tillgÀnglighetsprojekt utan det
PÄ bilden visas mitten av processen. Vad har redan gjorts fram till den hÀr punkten? Vi sa att vi ville göra en slavinspelare till den nya mÀstaren, Orchestrator började helt enkelt koppla om alla andra slavar till den, medan den nya mÀstaren fungerar som en transitmaskin. Med detta system uppstÄr inga fel, alla slavar fungerar, Orchestrator tar bort VIP frÄn den gamla mÀstaren, flyttar den till den nya, sÀtter read_only=0 och glömmer den gamla mÀstaren. Klart! Driftstoppet för vÄr tjÀnst Àr den tid det tar att flytta VIP, det Àr 2-3 sekunder.

Det var allt för idag, tack alla. Snart kommer den andra artikeln om Orchestrator. I den vÀlkÀnda sovjetiska filmen "Garaget" sa en karaktÀr: "Jag skulle inte gÄ med honom pÄ spaning!" SÄ, Orchestrator, jag skulle gÄ med dig pÄ spaning!

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster