Ethvert stort projekt startede med et par servere. Først var der én DB-server, derefter blev der tilføjet slaver til den for at skalere aflæsningen. Og så - stop! Der er én herre, men der er mange slaver; hvis en af slaverne forlader, så vil alt være fint, men hvis masteren forlader, vil det være dårligt: nedetid, administratorer forsøger at hæve serveren. Hvad skal man gøre? Reserver en mester. Min kollega Pavel har allerede skrevet om dette , jeg vil ikke gentage det. I stedet vil jeg fortælle dig, hvorfor du helt sikkert har brug for Orchestrator til MySQL!
Lad os starte med hovedspørgsmålet: "Hvordan skifter vi koden til en ny maskine, når mesteren forlader?"
- Jeg kan bedst lide ordningen med VIP (Virtual IP), vi vil tale om det nedenfor. Det er den enkleste og mest indlysende, selvom den har en åbenlys begrænsning: masteren, som vi vil reservere, skal være i L2-segmentet med den nye maskine, det vil sige, vi kan glemme den anden DC. Og på en mindelig måde, hvis du følger reglen om, at en stor L2 er ond, fordi L2 kun er pr. stativ, og L3 er mellem stativerne, og sådan en ordning har endnu flere begrænsninger.
- Du kan skrive et DNS-navn i koden og løse det gennem /etc/hosts. Faktisk vil der ikke være nogen løsning. Fordelen ved ordningen: der er ingen begrænsning karakteristisk for den første metode, det vil sige, at det er muligt at organisere en cross-DC. Men så opstår det åbenlyse spørgsmål: hvor hurtigt kan vi levere ændringen til /etc/hosts via Puppet-Ansible?
- Du kan ændre den anden metode lidt: installer caching DNS på alle webservere, hvorigennem koden vil gå til masterdatabasen. Du kan indstille TTL 60 for denne post i DNS. Det ser ud til, at hvis den implementeres korrekt, er metoden god.
- En ordning med serviceopdagelse, der indebærer brug af Consul og etcd.
- En interessant mulighed med . Du skal dirigere al trafik til MySQL gennem ProxySQL; ProxySQL kan selv bestemme, hvem der er master. Du kan i øvrigt læse om en af mulighederne for at bruge dette produkt i min .
Forfatteren af Orchestrator, der arbejder i Github, implementerede først den første ordning med VIP og konverterede den derefter til en ordning med konsul.
Typisk infrastruktur layout:
Jeg vil straks beskrive de åbenlyse situationer, der skal tages i betragtning:
- VIP-adressen bør ikke registreres i konfigurationen på nogen af serverne. Lad os forestille os en situation: masteren genstartede, og mens den blev indlæst, gik Orchestrator i failover-tilstand og gjorde en af slaverne til master; så rejste den gamle mester sig, og nu er VIP'en på to biler. Det her er slemt.
- Til orkestratoren skal du skrive et manuskript til at kalde den gamle mester og den nye mester. På den gamle master skal du køre ifdown, og på den nye master – ifup vip. Det ville være rart også at inkludere i dette script, at i tilfælde af en failover, bliver porten på den gamle masters switch simpelthen slået fra for at undgå enhver splitbrain.
- Efter Orchestrator har kaldt dit script for først at fjerne VIP'en og/eller slukke porten på switchen og derefter kaldet VIP-raising-scriptet på den nye master, så glem ikke at bruge arping-kommandoen til at fortælle alle, at den nye VIP er nu her.
- Alle slaver burde have read_only=1, og så snart du forfremmer slaven til masteren, skulle den have read_only=0.
- Glem ikke, at enhver slave, som vi har valgt til dette, kan blive en mester (Orchestrator har en hel præferencemekanisme for, hvilken slave man skal overveje som en kandidat til en ny mester i første omgang, hvilken i anden omgang, og hvilken slave skal slet ikke vælges under nogen omstændigheder master). Hvis slaven bliver en master, så vil slavens belastning forblive på den og masterens belastning vil blive tilføjet, dette skal tages i betragtning.
Hvorfor har du brug for Orchestrator, hvis du ikke har en?
- Orchestrator har en meget brugervenlig grafisk grænseflade, der viser hele topologien (se skærmbillede nedenfor).
- Orchestrator kan spore, hvilke slaver der halter bagefter, og hvor replikering generelt er brudt sammen (vi har scripts knyttet til Orchestrator til afsendelse af SMS).
- Orchestrator fortæller dig, hvilke slaver der har en GTID-fejl.
Orchestrator-grænseflade:
Hvad er GTID fejlagtigt?
Der er to hovedkrav for at Orchestrator skal fungere:
- Det er nødvendigt, at pseudo GTID er aktiveret på alle maskiner i MySQL-klyngen; vi har GTID aktiveret.
- Det er nødvendigt, at der er én type binlogs overalt, du kan bruge statement. Vi havde en konfiguration, hvor mesteren og de fleste slaver havde Row, og to forblev historisk i den blandede tilstand. Som et resultat ønskede Orchestrator simpelthen ikke at forbinde disse slaver med den nye mester.
Husk, at det vigtigste i en produktionsslave er dens sammenhæng med mesteren! Hvis du har Global Transaction ID (GTID) aktiveret på både din master og slave, så kan du bruge gtid_subset-funktionen til at finde ud af, om de samme anmodninger om dataændringer rent faktisk er blevet udført på disse maskiner. Du kan læse mere om dette .
Således viser Orchestrator dig gennem GTID-fejlen, at der er transaktioner på slaven, som ikke er på masteren. Hvorfor sker dette?
- Read_only=1 er ikke aktiveret på slaven, nogen tilsluttede sig og gennemførte en anmodning om at ændre data.
- Super_read_only=1 er ikke aktiveret på slaven, så gik administratoren, efter at have forvirret serveren, ind og udførte anmodningen der.
- Hvis du tog hensyn til begge tidligere punkter, så er der endnu et trick: i MySQL går en anmodning om at tømme binlogs også til binlogen, så ved første flush vil der dukke en GTID fejl på masteren og alle slaver. Hvordan undgår man dette? Perona-5.7.25-28 introducerede binlog_skip_flush_commands=1 indstillingen, som forbyder at skrive flush til binlogs. Der er en etableret en på mysql.com-webstedet .
Lad mig opsummere alt ovenstående. Hvis du ikke vil bruge Orchestrator i failover-tilstand endnu, så sæt den i observationstilstand. Så vil du altid have for dine øjne et kort over samspillet mellem MySQL-maskiner og visuel information om, hvilken type replikering der er på hver maskine, om slaverne halter bagud, og vigtigst af alt, hvor konsistente de er med masteren!
Det åbenlyse spørgsmål er: "Hvordan skal Orchestrator arbejde?" Han skal vælge en ny master fra de nuværende slaver og derefter tilslutte alle slaver til den igen (det er hvad GTID er nødvendigt for; hvis du bruger den gamle mekanisme med binlog_name og binlog_pos, så skifter en slave fra den nuværende master til en ny. er simpelthen umuligt!). Før vi fik Orchestrator, skulle jeg engang gøre alt dette manuelt. Den gamle master hang på grund af en buggy Adaptec controller; den havde omkring 10 slaver. Jeg havde brug for at overføre VIP fra masteren til en af slaverne og forbinde alle andre slaver til den igen. Hvor mange konsoller skulle jeg åbne, hvor mange samtidige kommandoer indtastede jeg... Jeg var nødt til at vente til kl. 3, fjern belastningen fra alle slaver undtagen to, lav den første maskine af de to til master, tilslut straks den anden maskine til den, så fastgør alle de andre slaver til den nye master og returner lasten. Samlet set forfærdeligt...
Hvordan fungerer Orchestrator, når den går i failover-tilstand? Dette illustreres nemmest ved et eksempel på en situation, hvor vi ønsker at gøre en mester til en mere kraftfuld, mere moderne maskine, end vi har nu.
Figuren viser midten af processen. Hvad er der allerede blevet gjort indtil dette punkt? Vi sagde, at vi ville gøre en eller anden slave til den nye mester, Orchestrator begyndte simpelthen at forbinde alle andre slaver til den igen, hvor den nye mester fungerede som en transitmaskine. Med dette skema opstår der ingen fejl, alle slaver fungerer, Orchestrator fjerner VIP'en fra den gamle master, overfører den til den nye, laver read_only=0 og glemmer den gamle master. Alle! Nedetiden for vores tjeneste er VIP-overførselstiden, som er 2-3 sekunder.
Det var alt for i dag, tak til jer alle. Der kommer snart en anden artikel om Orchestrator. I den berømte sovjetiske film "Garage" sagde en karakter: "Jeg ville ikke tage på rekognoscering med ham!" Så, Orchestrator, jeg ville tage med dig på rekognoscering!
Kilde: www.habr.com