I tidigare blogginlägg har vi behandlat ämnen för att övervaka ditt Galera-kluster oavsett om det är MySQL eller MariaDB. Även om teknikversionerna inte skiljer sig så mycket har MariaDB Cluster några stora förändringar sedan version 10.4.2. I den här versionen stöder den Galera Cluster 4 och har några fantastiska nya funktioner som vi kommer att titta på i det här blogginlägget.
För nybörjare som ännu inte är bekanta med MariaDB Cluster, är ett praktiskt taget synkront multi-master-kluster för MariaDB. Den är endast tillgänglig på Linux och stöder endast XtraDB/InnoDB-lagringsmotorerna (även om det finns experimentellt stöd för MyISAM - se systemvariabeln wsrep_replicate_myisam).
Programvaran är en medföljande teknik som drivs av MariaDB Server, MySQL-wsrep patch för MySQL Server och MariaDB Server utvecklad av Codership (stöder Unix-liknande OS) och Galera wsrep provider-biblioteket.
Du kan jämföra den här produkten med MySQL Group Replication eller med MySQL InnoDB Cluster, som syftar till att ge hög tillgänglighet. (Även om de skiljer sig åt olika i principer och tillvägagångssätt för att tillhandahålla HA.)
Nu när vi har täckt grunderna kommer vi i den här bloggen att ge tips som vi tycker är användbara när vi övervakar ditt MariaDB-kluster.
The Essentials of MariaDB Cluster
När du börjar använda MariaDB Cluster måste du identifiera exakt vad som är ditt syfte och varför du har valt MariaDB Cluster från början. Först måste du smälta vad som är funktionerna och deras fördelar när du använder MariaDB Cluster. Anledningen till att identifiera dessa är för att det i huvudsak är det som måste övervakas och kontrolleras för att du ska kunna fastställa prestanda, normala hälsotillstånd och om det fungerar i enlighet med dina planer.
I huvudsak identifieras det som ingen slavfördröjning, inga förlorade transaktioner, lässkalbarhet och mindre klientfördröjningar. Då kan frågor uppstå som, hur gör det ingen slavfördröjning eller förlorade transaktioner? Hur gör det att läsningen är skalbar eller med mindre latenser på klientsidan? Dessa områden är ett av nyckelområdena du behöver titta och övervaka speciellt för tung produktionsanvändning.
Även om själva MariaDB-klustret kan anpassas därefter. Att tillämpa ändringar av standardbeteendet som pc.weight eller pc.ignore_quorum, eller till och med använda multicast med UDP för ett stort antal noder, kan påverka hur du övervakar ditt MariaDB-kluster. Men å andra sidan är de mest väsentliga statusvariablerna vanligtvis ditt guldkant här med att veta att tillståndet och flödet av ditt kluster fungerar bra eller att det på förhand visar ett möjligt problem som leder till ett katastrofalt misslyckande.
Övervaka alltid din serveraktivitet (nätverk, disk, laddning, minne och CPU)
Att övervaka din serveraktivitet kan också vara en komplex uppgift om du har en mycket komplicerad stack som är sammanflätad i din databasarkitektur. Men för ett MariaDB-kluster är det alltid bäst att ha dina noder alltid inställda så dedikerade men ändå enkla som möjligt. Även om det inte begränsar dig från att använda alla reservresurser, nedan är de vanliga nyckelområdena du måste titta närmare på.
Nätverk
Galera Cluster 4 har strömmande replikering som en av nyckelfunktionerna och ändringarna från den tidigare versionen. Eftersom strömmande replikering tar itu med nackdelarna den hade i de tidigare utgåvorna men tillåter den att hantera mer än 2 GB skrivset sedan Galera Cluster 4. Detta gör att stora transaktioner kan fragmenteras och rekommenderas starkt för att aktivera detta enbart under sessionsnivå. Detta betyder att övervakning av din nätverksaktivitet är mycket viktig och avgörande för den normala aktiviteten i ditt MariaDB-kluster. Detta hjälper dig att identifiera vilken nod som hade mest eller högst nätverkstrafik baserat på tidsperioden.
Så hur kommer det att hjälpa dig att förbättra där noder med högst nätverkstrafik har identifierats? Tja, detta ger dig utrymme för förbättringar med din databastopologi eller det arkitektoniska lagret i ditt databaskluster. Genom att använda lastbalanserare eller en databasproxy kan du proaktivt konfigurera din databastrafik, särskilt när du bestämmer vilka specifika skrivningar som ska gå till en specifik nod. Låt oss säga att av de tre noderna är en av dem mer kapabel att hantera stora och stora frågor på grund av skillnader med hårdvaruspecifikationerna. Detta gör att du kan hantera mer av din capex och förbättra din kapacitetsplanering när kraven på en viss tidsperiod ändras.
Disk
Eftersom nätverksaktivitet också spelar roll för din diskprestanda, särskilt under spolningstiden. Det är också bäst att avgöra hur engagerad tid och hämtning presterar när hög toppbelastning uppnås. Det finns tillfällen då du fyller på din databasvärd med att inte bara vara dedikerad till en Galera Cluster-aktivitet utan även blanda ihop med andra verktyg som docker, SQL-proxyer som ProxySQL eller MaxScale. Detta ger dig kontroll med lågbelastningsservrar och låter dig använda de lediga resurserna som kan användas för andra fördelaktiga ändamål, särskilt för din databasarkitekturstack. När du väl kan bestämma vilken nod vid övervakning som har den lägsta belastningen men fortfarande kan hantera dess disk-IO-användning, kan du välja den specifika noden medan du tittar på tiden som går. Återigen, detta ger dig fortfarande bättre hantering av din kapacitetsplanering.
CPU, minne och laddningsaktivitet
Låt mig kort nämna dessa tre områden att titta på vid övervakning. I det här avsnittet är det alltid bäst att du har bättre observerbarhet för följande områden på en gång. Det är snabbare och lättare att förstå, speciellt utesluter en prestandaflaskhals eller identifierar buggar som gör att dina noder stannar och som också kan påverka de andra noderna och möjligheten att gå ner i klustret.
Så hur hjälper CPU, minne och laddningsaktivitet vid övervakning ditt MariaDB-kluster? Tja, som det jag har nämnt ovan är det en av de få sakerna som ändå är en stor faktor för dagliga rutinkontroller. Nu hjälper detta dig också att identifiera om dessa är periodiska eller slumpmässiga händelser. Om det är periodiskt kan det vara relaterat till säkerhetskopior som körs i en av dina Galera-noder, eller så är det en massiv fråga som kräver optimering. Till exempel dåliga frågor utan korrekta index, eller inbalanserad användning av datahämtning, som att göra en strängjämförelse för en så stor sträng. Det kan onekligen vara otillämpligt för databaser av OLTP-typ som MariaDB Cluster, särskilt om det verkligen är karaktären och kraven för din applikation. Bättre använd andra analytiska verktyg som MariaDB Columnstore, eller andra analytiska bearbetningsverktyg från tredje part (Apache Spark, Kafka eller MongoDB, etc.) för datahämtning av stora strängar och/eller strängmatchning.
Så med alla dessa nyckelområden som övervakas, är frågan hur det ska övervakas? Det måste övervakas minst per minut. Med förfinad övervakning, det vill säga per sekund av kollektiva mått kan vara resurskrävande och mycket giriga när det gäller dina resurser. Även om en halv minuts kollektivitet är acceptabelt, särskilt om din data och RPO (återställningspunktsmål) är mycket låg, så du behöver mer detaljerade och realtidsdatamått. Det är mycket viktigt att du kan övervaka hela bilden av ditt databaskluster. Bortsett från detta är det också bäst och viktigt att närhelst vilka mätvärden du övervakar, har du rätt verktyg för att fånga din uppmärksamhet när saker är i fara eller till och med bara varningar. Att använda rätt verktyg som ClusterControl hjälper dig att hantera dessa nyckelområden som ska övervakas. Jag använder här en gratisversion eller community-utgåva av ClusterControl och hjälper mig att övervaka mina noder utan krångel från installation till övervakning av noder med bara några få klick. Se till exempel skärmdumparna nedan:
Vyn är en mer förfinad och snabb översikt över vad som händer just nu. En mer detaljerad graf kan också användas,
eller med en mer kraftfull och rik datamodell som också stöder frågespråk kan ge dig analys av hur ditt MariaDB-kluster presterar baserat på historisk data som jämför dess prestanda i tid. Till exempel,
Det ger dig bara mer synlig statistik. Så du ser hur viktigt det verkligen är att ha rätt verktyg när du övervakar ditt MariaDB-kluster.
Se till kollektiv övervakning av dina MariaDB-klusterstatistikvariabler
Då och då kan det inte vara oundvikligt att MariaDB Cluster-versioner kommer att producera ny statistik för att övervaka eller förbättra typen av övervakning av databasen genom att tillhandahålla fler statusvariabler och förfina värden att titta på. Som jag har nämnt ovan använder jag ClusterControl för att övervaka mina noder i denna exempelblogg. Det betyder dock inte att det är det bästa verktyget som finns. Jag menar PMM från Percona är mycket rik när det gäller kollektiv övervakning för varje statistisk variabel. Närhelst MariaDB Cluster har nyare statistiska variabler att erbjuda kan du utnyttja detta och även ändra det eftersom PMM är ett verktyg med öppen källkod. Det är en stor fördel att du också har all synlighet för ditt MariaDB-kluster eftersom varje aspekt räknas, speciellt i en produktionsbaserad databas som tillgodoser hundratusentals förfrågningar per minut.
Men låt oss gå in mer specifikt på problemet här. Vilka är dessa statistiska variabler att titta på? Det finns många att räkna med för ett MariaDB-kluster men genom att återigen fokusera på funktionerna och fördelarna som vi tror att du använder MariaDB-klustret vad det har att erbjuda, så fokuserar vi på det.
Galera Cluster - Flödeskontroll
Flödeskontrollen för ditt MariaDB-kluster ger dig en översikt över hur replikeringshälsan fungerar i hela klustret. Replikeringsprocessen i Galera Cluster använder en återkopplingsmekanism, vilket innebär att den signalerar över hela noderna inom det klustret och flaggar om noden måste pausa eller återuppta replikering enligt sina behov. Detta förhindrar också att någon nod släpar för långt medan de andra tillämpar de inkommande transaktionerna. Så här fungerar flödeskontrollen som sin funktion inom Galera. Nu måste detta ses och inte förbises när du övervakar ditt MariaDB-kluster. Detta, som nämnts i en av fördelarna med att använda MariaDB Cluster är att undvikandet av att ha slavlag. Även om det är för naivt för att förstå om flödeskontrollen och slavfördröjningen, men med flödeskontroll kommer det att påverka ditt Galera-klusters prestanda när det är mycket kö och commits eller spolning av sidor till disken blir väldigt låg för sådana diskproblem eller det är bara frågan som körs är en dålig fråga. Om du är nybörjare på hur Galera fungerar kanske du är intresserad av att läsa det här externa inlägget om vad som är flödeskontroll i Galera.
Bytes skickade/mottagna
Byten som skickas eller tas emot korrelerar med nätverksaktiviteten och är till och med ett av nyckelområdena att titta sida vid sida med flödeskontroll. Detta låter dig avgöra vilken nod som är mest påverkad eller tillskriver prestandaproblemen som lider inom ditt Galera-kluster. Det är mycket viktigt eftersom du kan kontrollera om det kan vara någon försämring när det gäller hårdvara som din nätverksenhet eller den underliggande lagringsenheten för vilken synkronisering av smutsiga sidor kan ta för lång tid att göra.
Klusterladdning
Tja, detta är mer av databasaktiviteten för hur mycket ändringar eller datahämtning som har efterfrågats eller gjorts hittills sedan serverns drifttid. Det hjälper dig att utesluta vilken typ av frågor som mest påverkar ditt databasklusterprestanda. Detta gör att du kan ge utrymme för förbättringar, särskilt när det gäller att balansera belastningen på dina databasförfrågningar. Att använda ProxySQL hjälper dig här med en mer förfinad och detaljerad metod för frågedirigering. Även om MaxScale också erbjuder den här funktionen, har ProxySQL mer granularitet även om det också har en viss prestandapåverkan eller kostnad. Effekten kommer när du bara har en ProxySQL som SQL-proxy för att räkna ut frågedirigeringen och det kan kämpa när hög trafik pågår. Med kostnad, om du lägger till fler ProxySQL-noder för att balansera mer av trafiken som en underliggande KeepAlived. Även om detta är en perfekt kombination men den kan köras till en låg kostnad tills den behövs. Men hur kommer du att kunna avgöra om det behövs, eller hur? Det är frågan som återstår här, så ett skarpt öga för att övervaka dessa nyckelområden är mycket viktigt, inte bara för observerbarhet, utan också för att förbättra prestandan för ditt databaskluster allt eftersom tiden går.
Som sådan finns det massor av variabler att titta på i ett MariaDB-kluster. Det viktigaste här du måste ta hänsyn till är verktyget du använder för att övervaka ditt databaskluster. Som nämnts tidigare föredrar jag att använda gratisversionslicensen för ClusterControl (Community Edition) här i den här bloggen eftersom den ger mig fler sätt med flexibilitet att se på i ett Galera Cluster. Se exemplet nedan,
Jag har markerat eller inringat i rött de flikar som låter mig övervaka visuellt hälsan hos mitt MariaDB-kluster. Låt oss säga att om din applikation är girig på att använda strömmande replikering då och då och den skickar ett stort antal fragment (stor nätverksöverföring) för klusterinteraktivitet, är det bäst att avgöra hur väl dina noder kan hantera stressen. Särskilt under stresstester innan du driver specifika ändringar i din applikation, är det alltid bäst att försöka testa för att fastställa kapacitetshanteringen för din applikationsprodukt och avgöra om dina nuvarande databasnoder och design kan hantera belastningen av dina applikationskrav.
Även på en community-utgåva av ClusterControl kan jag samla detaljerade och mer förfinade resultat av hälsan hos mitt MariaDB-kluster. Se nedan,
Så här ska du närma dig övervakningen av ditt MariaDB-kluster. En perfekt visualisering är alltid enklare och snabbare att hantera. När det går söderut har du inte råd att förlora din produktivitet och även stilleståndstiden kan påverka din verksamhet. Även om det att ha gratis inte ger dig lyxen och komforten när du hanterar databaser med hög trafik, är att ha larm, aviseringar och databashantering i ett område ett tillägg som ClusterControl kan göra.
Slutsats
MariaDB Cluster är inte lika enkelt att övervaka jämfört med de traditionella asynkrona MySQL/MariaDB master-slave-inställningarna. Det fungerar annorlunda och du måste ha rätt verktyg för att avgöra vad som händer och vad som kommer in i ditt databaskluster. Förbered alltid din kapacitetsplanering innan du kör ditt MariaDB-kluster utan ordentlig övervakning i förväg. Det är alltid bäst att din databasbelastning och aktivitet är känd innan en katastrofal händelse.