Orchestrator för MySQL: varför du inte kan bygga ett feltolerant projekt utan det

Alla stora projekt började med ett par servrar. Först fanns det en DB-server, sedan lades slavar till den för att skala avläsningen. Och sedan - sluta! Det finns en herre, men det finns många slavar; om en av slavarna lämnar kommer allt att bli bra, men om mastern lämnar blir det dåligt: ​​driftstopp, administratörer försöker höja servern. Vad ska man göra? Reservera en mästare. Min kollega Pavel har redan skrivit om detta Artikel, jag kommer inte att upprepa det. Istället ska jag berätta varför du definitivt behöver Orchestrator för MySQL!

Låt oss börja med huvudfrågan: "Hur ska vi byta koden till en ny maskin när befälhavaren lämnar?"

• Jag gillar systemet med VIP (Virtual IP) mest, vi kommer att prata om det nedan. Det är det enklaste och mest uppenbara, även om det har en uppenbar begränsning: mastern som vi kommer att reservera måste vara i L2-segmentet med den nya maskinen, det vill säga vi kan glömma den andra DC. Och, på ett vänskapligt sätt, om du följer regeln att en stor L2 är ond, eftersom L2 bara är per rack, och L3 är mellan racken, och ett sådant system har ännu fler begränsningar.
• Du kan skriva ett DNS-namn i koden och lösa det genom /etc/hosts. Faktum är att det inte blir någon lösning. Fördelen med schemat: det finns ingen begränsning som är karakteristisk för den första metoden, det vill säga det är möjligt att organisera en cross-DC. Men då uppstår den uppenbara frågan: hur snabbt kan vi leverera ändringen till /etc/hosts via Puppet-Ansible?
• Du kan ändra den andra metoden lite: installera cachning DNS på alla webbservrar, genom vilken koden kommer att gå till huvuddatabasen. Du kan ställa in TTL 60 för denna post i DNS. Det verkar som om metoden är bra om den implementeras på rätt sätt.
• Ett schema med tjänsteupptäckt, vilket innebär användning av Consul och etcd.
• Ett intressant alternativ med ProxySQL. Du måste dirigera all trafik till MySQL genom ProxySQL; ProxySQL kan själv avgöra vem som är mästaren. Du kan förresten läsa om ett av alternativen för att använda denna produkt i min artikeln.

Författaren till Orchestrator, som arbetar i Github, implementerade först det första schemat med VIP och konverterade det sedan till ett schema med konsul.

Typisk infrastrukturlayout:

Jag kommer omedelbart att beskriva de uppenbara situationer som måste beaktas:

• VIP-adressen ska inte registreras i konfigurationen på någon av servrarna. Låt oss föreställa oss en situation: mastern startade om, och medan den laddades gick Orchestrator in i failover-läge och gjorde en av slavarna till master; sedan reste den gamle mästaren sig, och nu är VIP på två bilar. Det här är dåligt.
• För orkestratorn måste du skriva ett manus för att ringa den gamla mästaren och den nya mästaren. På den gamla mastern måste du köra ifdown, och på den nya mastern – ifup vip. Det skulle vara trevligt att även inkludera i det här skriptet att i händelse av en failover, så stängs porten på den gamla masterns switch helt enkelt av för att undvika splitbrain.
• Efter att Orchestrator har anropat ditt skript för att först ta bort VIP:n och/eller släcka porten på switchen och sedan anropa VIP-höjningsskriptet på den nya mastern, glöm inte att använda kommandot arping för att berätta för alla att den nya VIP:n är nu här.
• Alla slavar borde ha read_only=1, och så fort du befordrar slaven till mastern ska den ha read_only=0.
• Glöm inte att vilken slav som helst som vi har valt för detta kan bli en mästare (Orchestrator har en hel preferensmekanism för vilken slav som ska övervägas som kandidat för en ny mästare i första hand, vilken i andra hand, och vilken slav som ska inte väljas alls under några omständigheter master). Om slaven blir en master, kommer slavens last att förbli på den och masterns last kommer att läggas till, detta måste beaktas.

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

• Orchestrator har ett mycket användarvänligt grafiskt gränssnitt som visar hela topologin (se skärmdump nedan).
• Orchestrator kan spåra vilka slavar som släpar efter och var replikeringen i allmänhet har gått sönder (vi har skript kopplade till Orchestrator för att skicka SMS).
• Orchestrator berättar vilka slavar som har ett GTID-fel.

Orchestrator Interface:

Vad är GTID fel?

Det finns två huvudkrav för att Orchestrator ska fungera:

• Det är nödvändigt att pseudo GTID är aktiverat på alla maskiner i MySQL-klustret, vi har GTID aktiverat.
• Det är nödvändigt att det finns en typ av binlogs överallt, du kan använda statement. Vi hade en konfiguration där befälhavaren och de flesta slavar hade rad, och två historiskt sett förblev i blandat läge. Som ett resultat ville Orchestrator helt enkelt inte koppla dessa slavar till den nya mastern.

Kom ihåg att det viktigaste i en produktionsslav är dess överensstämmelse med befälhavaren! Om du har Global Transaction ID (GTID) aktiverat på både din master och slav, kan du använda funktionen gtid_subset för att ta reda på om samma förfrågningar om dataändringar faktiskt har utförts på dessa maskiner. Du kan läsa mer om detta här.

Således visar Orchestrator dig genom GTID-felet att det finns transaktioner på slaven som inte finns på mastern. Varför händer det här?

• Read_only=1 är inte aktiverat på slaven, någon ansluten och slutförde en begäran om att ändra data.
• Super_read_only=1 är inte aktiverat på slaven, då administratören, efter att ha förvirrat servern, gick in och körde begäran där.
• Om du tog hänsyn till båda föregående punkterna, så finns det ytterligare ett knep: i MySQL går en begäran om att spola binlogs också till binloggen, så vid den första flushen kommer en GTID-felande att dyka upp på mastern och alla slavar. Hur undviker man detta? Perona-5.7.25-28 introducerade inställningen binlog_skip_flush_commands=1, som förbjuder att skriva flush till binlogs. Det finns en etablerad sådan på mysql.com-webbplatsen insekt.

Låt mig sammanfatta allt ovan. Om du inte vill använda Orchestrator i failover-läge ännu, sätt den i observationsläge. Då har du alltid framför dina ögon en karta över interaktionen mellan MySQL-maskiner och visuell information om vilken typ av replikering som finns på varje maskin, om slavarna släpar efter, och viktigast av allt, hur konsekventa de är med mastern!

Den uppenbara frågan är: "Hur ska Orchestrator fungera?" Han måste välja en ny master från de nuvarande slavarna och sedan återansluta alla slavar till den (detta är vad GTID behövs för; om du använder den gamla mekanismen med binlog_name och binlog_pos, byta sedan en slav från den nuvarande mastern till en ny. är helt enkelt omöjligt!). Innan vi fick Orchestrator var jag en gång tvungen att göra allt detta manuellt. Den gamla mastern hängde på grund av en buggy Adaptec-kontroller, den hade cirka 10 slavar. Jag behövde överföra VIP från mastern till en av slavarna och återansluta alla andra slavar till den. Hur många konsoler behövde jag öppna, hur många samtidiga kommandon skrev jag in... Jag var tvungen att vänta till 3:XNUMX, ta bort belastningen från alla slavar utom två, gör den första maskinen av två master, anslut omedelbart den andra maskinen till den, så anslut alla andra slavar till den nya mastern och lämna tillbaka lasten. Sammantaget, hemskt...

Hur fungerar Orchestrator när den går in i failover-läge? Detta illustreras lättast av ett exempel på en situation där vi vill göra en mästare till en kraftfullare, modernare maskin än vi har nu.

Bilden visar mitten av processen. Vad har redan gjorts fram till denna punkt? Vi sa att vi ville göra någon slav till den nya mästaren, Orchestrator började helt enkelt återansluta alla andra slavar till den, med den nya mästaren som en transitmaskin. Med detta schema uppstår inga fel, alla slavar fungerar, Orchestrator tar bort VIP från den gamla mastern, överför den till den nya, gör read_only=0 och glömmer bort den gamla mastern. Allt! Nedetiden för vår tjänst är VIP-överföringstiden, som är 2-3 sekunder.

Det var allt för idag, tack alla. Det kommer snart en andra artikel om Orchestrator. I den berömda sovjetiska filmen "Garage" sa en karaktär: "Jag skulle inte åka på spaning med honom!" Så, Orchestrator, jag skulle följa med dig på spaning!

Källa: will.com