Percona XtraDB Cluster er en meget kendt løsning med høj tilgængelighed i MySQL-verdenen. Det er baseret på Galera Cluster, og det giver praktisk talt synkron replikering på tværs af flere noder. Som med enhver database er det afgørende at holde styr på, hvad der sker i systemet, om ydeevnen er på de forventede niveauer, og hvis ikke, hvad er flaskehalsen. Dette er yderst vigtigt for at kunne reagere ordentligt i den situation, hvor præstationen påvirkes. Selvfølgelig kommer Percona XtraDB Cluster med flere metrikker, og det er ikke altid klart, hvilke af dem der er de vigtigste til at spore databasens tilstand. I denne blog vil vi diskutere et par af de vigtigste metrics, du vil holde øje med, mens du arbejder med PXC.
For at gøre det klart, vil vi fokusere på de målinger, der er unikke for PXC og Galera, vi vil ikke dække målinger for MySQL eller InnoDB. Disse målinger er blevet diskuteret i vores tidligere blogs.
Lad os tage et kig på nogle af de vigtigste oplysninger, som PXC præsenterer for os.
Flowkontrol
Flowkontrol er stort set den vigtigste metrik, du kan overvåge i en hvilken som helst Galera Cluster, så lad os have lidt baggrund. Galera er en multi-master, praktisk talt synkron klynge. Det er muligt at udføre skrivninger på enhver af de databasenoder, der danner den. Hver skrivning skal sendes til alle noderne i klyngen for at sikre, at den kan anvendes - denne proces kaldes certificeringen. Ingen transaktion kan anvendes, før alle noder er enige om, at den kan forpligtes. Hvis nogen af noderne har præstationsproblemer, der gør den ude af stand til at klare trafikken, vil den begynde at udsende flowkontrolmeddelelser, som har til formål at informere resten af klyngen om ydeevneproblemerne og bede dem om at reducere arbejdsbyrden og hjælpe de forsinkede. node for at indhente resten af klyngen.
Du kan spore, hvornår noder var nødt til at indføre kunstig pause for at lade deres haltende peers indhente det ved hjælp af flowkontrol pauset metric (wsrep_flow_control_paused):
Du kan også spore, om noden sender eller modtager flowkontrolmeddelelser (wsrep_flow_control_recv og wsrep_flow_control_sent).
Denne information hjælper dig med bedre at forstå, hvilken node der ikke fungerer på det samme niveau som sine jævnaldrende. Du kan derefter fokusere på den node og prøve at forstå, hvad der er problemet, og hvordan du fjerner flaskehalsen.
Send og modtag køer
Disse metrics er på en måde relateret til flowkontrollen. Som vi har diskuteret, kan en node halte bagefter andre noder i klyngen. Det kan være forårsaget af en ulige arbejdsbyrdefordeling eller af andre årsager (en eller anden proces, der kører i baggrunden, backup eller nogle brugerdefinerede, tunge forespørgsler). Inden flowkontrollen starter, vil haltende noder forsøge at gemme de indgående skrivesæt i modtagekøen (wsrep_local_recv_queue) i håb om, at ydeevnepåvirkningen er forbigående, og den vil være i stand til at indhente det meget snart. Kun hvis køen bliver for stor (den er styret af gcs.fc_limit-indstillingen), begynder der at blive sendt flowkontrolmeddelelser på tværs af klyngen.
Du kan tænke på en modtagekø som den tidlige markør, der viser, at der er der problemer med ydeevnen, og flowkontrollen kan slå ind.
På den anden side vil sendekø (wsrep_local_send_queue) fortælle dig, at noden ikke er i stand til at sende skrivesættene til andre medlemmer af klyngen, hvilket kan indikere problemer med netværksforbindelsen (skubber skrivesættene til netværket er ikke rigtig ressourcekrævende).
Parallelliseringsmetrics
Percona XtraDB-klyngen kan konfigureres til at bruge flere tråde til at anvende de indgående skrivesæt - det giver den mulighed for bedre at håndtere flere tråde, der forbinder til klyngen og udsteder skrivninger på samme tid. Der er to hovedmålinger, som du måske vil holde øje med.
For det første fortæller wsrep_cert_deps_distance os, hvad paralleliseringspotentialet er - hvor mange skrivesæt kan potentielt anvendes på samme tid. Baseret på denne værdi kan du konfigurere antallet af parallelle slavetråde (wsrep_slave_threads), der vil arbejde på at anvende indgående skrivesæt. Tommelfingerreglen er, at det ikke nytter noget at konfigurere flere tråde end værdien af wsrep_cert_deps_distance.
Anden metrik på den anden side fortæller os, hvor effektivt vi var i stand til at parallelisere processen med at anvende skrivesæt - wsrep_apply_oooe fortæller os, hvor ofte applieren begyndte at anvende skrivesæt ude af rækkefølge (hvilket peger mod bedre parallelisering ).
Konklusion
Som du kan se, er der et par metrics, der er værd at se på i Percona XtraDB Cluster. Selvfølgelig, som vi sagde i begyndelsen af denne blog, er disse målinger strengt relateret til PXC og Galera Cluster generelt.
Du bør også holde øje med almindelige MySQL- og InnoDB-metrics for at få en bedre forståelse af din databases tilstand. Og husk, du kan overvåge denne teknologi gratis ved at bruge ClusterControl Community Edition.