På Citymobil använder vi en MySQL-databas som vår huvudsakliga beständiga datalagring. Vi har flera databaskluster för olika tjänster och ändamål.

Den konstanta tillgängligheten av mastern är en kritisk indikator på prestandan för hela systemet och dess individuella delar. Automatisk klusteråterställning i händelse av ett huvudfel minskar avsevärt incidentens svarstid och systemets stilleståndstid. I den här artikeln kommer jag att titta på en design med hög tillgänglighet (HA) för ett MySQL-kluster baserat på MySQL Orchestrator och virtuella IP-adresser (VIP).

HA-lösning baserad på VIP

Först ska jag kort berätta vad vårt datalagringssystem är.

Vi använder ett klassiskt replikeringsschema med en skrivtillgänglig master och flera skrivskyddade repliker. Ett kluster kan innehålla en mellanliggande master - en nod som är både en replik och en master för andra. Klienter får åtkomst till repliker genom HAProxy, vilket möjliggör jämn lastfördelning och enkel skalning. Användningen av HAProxy beror på historiska skäl, och vi håller för närvarande på att migrera till ProxySQL.

Replikering utförs i semi-synkront läge baserat på GTID. Det betyder att minst en replik måste logga en transaktion innan den anses vara framgångsrik. Detta replikeringsläge ger en optimal balans mellan prestanda och datasäkerhet i händelse av ett masternodfel. I princip alla ändringar överförs från mastern till replikerna med hjälp av Row Based Replication (RBR), men vissa noder kan ha mixed binlog format.

Orkestratorn uppdaterar med jämna mellanrum klustertopologins tillstånd, analyserar den mottagna informationen och om problem uppstår kan den starta en automatisk återställningsprocedur. Utvecklaren är ansvarig för själva proceduren, eftersom den kan implementeras på olika sätt: baserat på VIP, DNS, med hjälp av tjänsteupptäcktstjänster eller självskrivna mekanismer.

Ett enkelt sätt att återställa en master om den misslyckas är att använda flytande VIP-adresser.

Vad du behöver veta om den här lösningen innan du går vidare:

• En VIP är en IP-adress som inte är associerad med ett specifikt fysiskt nätverksgränssnitt. Om en nod misslyckas eller under schemalagt underhåll kan vi byta VIP till en annan resurs med minimal driftstopp.
• Att frigöra och utfärda en virtuell IP-adress är en billig och snabb operation.
• För att arbeta med VIP behöver du tillgång till servern via SSH, eller användning av speciella verktyg, till exempel, keepalived.

Låt oss titta på möjliga problem med vår guide och föreställa oss hur den automatiska återställningsmekanismen ska fungera.

Nätverksanslutningen till mastern har försvunnit eller ett problem har uppstått på hårdvarunivån och servern är inte tillgänglig

1. Orkestratorn uppdaterar klustertopologin, varje replik rapporterar att mastern inte är tillgänglig. Orkestratören startar processen med att välja en replik som lämpar sig för rollen som den nya mästaren och börjar återhämta sig.
2. Vi försöker ta bort VIP:n från den gamla mästaren - utan framgång.
3. Repliken byter till rollen som mästare. Topologin byggs om.
4. Lägger till ett nytt nätverksgränssnitt med VIP. Eftersom det inte gick att ta bort VIP:n börjar vi med jämna mellanrum skicka en förfrågan i bakgrunden gratis ARP. Denna typ av förfrågan/svar låter dig uppdatera IP- och MAC-adressmappningstabellen på de anslutna switcharna och därigenom meddela dig att vår VIP har flyttat. Detta minimerar sannolikheten split brain när den gamla mästaren återlämnas.
5. Alla nya anslutningar omdirigeras omedelbart till den nya mastern. Gamla anslutningar misslyckas och upprepade anrop till databasen görs på applikationsnivå.

Servern fungerar i normalt läge, ett fel inträffade på DBMS-nivå

Algoritmen liknar det tidigare fallet: uppdatering av topologin och start av återställningsprocessen. Eftersom servern är tillgänglig släpper vi framgångsrikt VIP på den gamla mastern, överför den till den nya och skickar flera ARP-förfrågningar. Den eventuella återlämnandet av den gamla mastern bör inte påverka det ombyggda klustret och applikationens funktion.

Andra problem

Misslyckande av repliker eller mellanliggande masters leder inte till automatiska åtgärder och kräver manuellt ingripande.

Ett virtuellt nätverksgränssnitt läggs alltid till tillfälligt, det vill säga efter en omstart av servern tilldelas inte VIP automatiskt. Varje databasinstans startar i skrivskyddat läge som standard, orkestratorn byter automatiskt den nya mastern för att skriva och försöker installera read only på den gamle mästaren. Dessa åtgärder syftar till att minska sannolikheten split brain.

Problem kan uppstå under återställningsprocessen, vilket också bör meddelas via orkestratorns användargränssnitt utöver standardövervakningsverktyg. Vi har utökat REST API genom att lägga till den här funktionen (PR för närvarande granskas).

Det allmänna diagrammet för HA-lösningen presenteras nedan.

Att välja en ny mästare

Orkestratören är smart nog och försöker välja den mest lämpliga kopian som ny befälhavare enligt följande kriterier:

• repliken släpar efter mästaren;
• MySQL-version av master och replika;
• replikationstyp (RBR, SBR eller blandad);
• plats i samma eller olika datacenter;
• tillgänglighet errant GTID — Transaktioner som utfördes på repliken och som inte finns på mastern.
• anpassade urvalsregler beaktas också.

Inte varje cue är en idealisk kandidat för en mästare. Till exempel kan en replik användas för att säkerhetskopiera data, eller så har servern en svagare hårdvarukonfiguration. Orkesterare stöder manuella regler med vilka du kan anpassa dina val av kandidater från mest föredragna till ignorerade.

Respons och återhämtningstid

I händelse av en incident är det viktigt att minimera systemets driftstopp, så låt oss överväga MySQL-parametrarna som påverkar skapandet och uppdateringen av klustertopologin av orkestratorn:

• slave_net_timeout — Antalet sekunder under vilka repliken väntar på att nya data eller en hjärtslagssignal ska komma från mastern innan anslutningen identifieras som förlorad och återansluten. Ju lägre värde, desto snabbare kan repliken avgöra att kommunikationen med mastern är bruten. Vi ställer in detta värde till 5 sekunder.
• MASTER_CONNECT_RETRY — Antal sekunder mellan återanslutningsförsök. I händelse av nätverksproblem kommer ett lågt värde för denna parameter att möjliggöra snabb återanslutning och förhindra att klusteråterställningsprocessen startar. Det rekommenderade värdet är 1 sekund.
• MASTER_RETRY_COUNT — Maximalt antal återanslutningsförsök.
• MASTER_HEARTBEAT_PERIOD — intervall i sekunder efter vilket mastern sänder en hjärtslagssignal. Förinställer halva värdet slave_net_timeout.

Orchestrator alternativ:

• DelayMasterPromotionIfSQLThreadNotUpToDate - om lika true, då kommer masterrollen inte att tillämpas på kandidatrepliken förrän replikens SQL-tråd har slutfört alla ej tillämpade transaktioner från reläloggen. Vi använder det här alternativet för att undvika att förlora transaktioner när alla kandidatkopior hamnar på efterkälken.
• InstancePollSeconds — Frekvens för att bygga och uppdatera topologin.
• RecoveryPollSeconds — Frekvens för topologianalys. Om ett problem upptäcks initieras topologiåterställning. Detta konstant, lika med 1 sekund.

Varje klusternod avfrågas av orkestratorn en gång varje InstancePollSeconds sekunder När ett problem upptäcks tvingas klustertillståndet uppdaterad, och sedan fattas det slutliga beslutet att utföra återställning. Genom att experimentera med olika databas- och orkestratorparametrar kunde vi minska responsen och återhämtningstiden till 30 sekunder.

Testbänk

Vi började testa HA-schemat med utvecklingen av en lokal Testbänk och vidare implementering i test- och produktionsmiljöer. Den lokala montern är helautomatiserad baserat på Docker och låter dig experimentera med konfigurationen av orkestratorn och nätverket, skala klustret från 2-3 servrar till flera dussin och genomföra övningar i en säker miljö.

Under övningarna väljer vi en av problememuleringsmetoderna: skjut direkt befälhavaren med hjälp av kill -9, avsluta mjukt processen och stoppa servern (docker-compose stop), simulera nätverksproblem med hjälp av iptables -j REJECT eller iptables -j DROP. Vi förväntar oss följande resultat:

• orkestratorn kommer att upptäcka problem med mastern och uppdatera topologin på inte mer än 10 sekunder;
• återställningsproceduren startar automatiskt: nätverkskonfigurationen kommer att ändras, masterns roll kommer att övergå till repliken, topologin kommer att byggas om;
• den nya mastern kommer att bli skrivbar, levande repliker kommer inte att gå förlorade under återuppbyggnadsprocessen;
• data kommer att börja skrivas till den nya mastern och replikeras;
• Den totala återhämtningstiden kommer inte att vara mer än 30 sekunder.

Som ni vet kan systemet bete sig annorlunda i test- och produktionsmiljöer på grund av olika hårdvaru- och nätverkskonfigurationer, skillnader i syntetisk och verklig belastning, etc. Därför genomför vi regelbundet övningar under verkliga förhållanden, och kontrollerar hur systemet beter sig när nätverksanslutningen försvinner eller dess enskilda delar försämras. I framtiden vill vi bygga en helt identisk infrastruktur för båda miljöerna och automatisera dess testning.

Resultat

Tillståndet för huvudlagringssystemets nod är en av huvuduppgifterna för SRE och operationsteamet. Implementeringen av orkestratorn och HA-lösningen baserad på VIP gjorde det möjligt för oss att uppnå följande resultat:

• tillförlitlig upptäckt av problem med topologin för databasklustret;
• automatiskt och snabbt svar på master-relaterade incidenter, vilket minskar systemets stilleståndstid.

Lösningen har dock sina begränsningar och nackdelar:

• skalning av HA-schemat till flera datacenter kommer att kräva ett enda L2-nätverk mellan dem;
• Innan vi tilldelar VIP på den nya mastern måste vi släppa den på den gamla. Processen är sekventiell, vilket ökar återhämtningstiden;
• att släppa VIP kräver SSH-åtkomst till servern, eller någon annan metod för att anropa fjärrprocedurer. Eftersom servern eller databasen har problem som orsakade återställningsprocessen kan vi inte vara säkra på att VIP-borttagningen kommer att slutföras framgångsrikt. Och detta kan leda till uppkomsten av två servrar med samma virtuella IP-adress och ett problem split brain.

Att undvika split brain, kan du använda metoden STONITH ("Skjut den andra noden i huvudet"), vilket helt isolerar eller inaktiverar problemnoden. Det finns andra sätt att implementera klusterhög tillgänglighet: en kombination av VIP och DNS, tjänsteupptäckt och proxytjänster, synkron replikering och andra metoder som har sina egna nackdelar och fördelar.

Jag pratade om vårt tillvägagångssätt för att skapa ett MySQL failover-kluster. Det är lätt att implementera och ger en acceptabel nivå av tillförlitlighet under rådande förhållanden. Allt eftersom hela systemet i allmänhet och infrastrukturen i synnerhet utvecklas, kommer detta synsätt utan tvekan att utvecklas.

Källa: will.com