I den foregående del har vi testet backup-tid og effektivitet af komprimeringen for forskellige backup-komprimeringsniveauer og -metoder. I denne blog vil vi fortsætte vores indsats, og vi vil tale om flere indstillinger, som sandsynligvis de fleste af brugerne ikke rigtig ændrer, men de kan have en synlig effekt på backup-processen.
Opsætningen er den samme som i den foregående del:vi vil bruge MariaDB master-slave replikeringsklynge med ProxySQL og Keepalived.
Vi har genereret 7,6 GB data ved hjælp af sysbench:
sysbench /root/sysbench/src/lua/oltp_read_write.lua --threads=4 --mysql-host=10.0.0.111 --mysql-user=sbtest --mysql-password=sbtest --mysql-port=6033 --tables=32 --table-size=1000000 prepareBrug af PIGZ
Denne gang vil vi aktivere Brug PIGZ til parallel gzip til vores sikkerhedskopier. Som før vil vi teste hvert komprimeringsniveau for at se, hvordan det fungerer.
Vi gemmer sikkerhedskopien lokalt på instansen, instansen er konfigureret med 4 vCPU'er.
Resultatet er på en måde forventet. Sikkerhedskopieringsprocessen var betydeligt hurtigere, end da vi kun brugte en enkelt CPU-kerne. Størrelsen af sikkerhedskopien forbliver stort set den samme, der er ingen reel grund til, at den ændrer sig væsentligt. Det er klart, at brug af pigz forbedrer backup-tiden. Der er dog en mørk side ved at bruge parallel gzip, og det er CPU-udnyttelse:
Som du kan se, springer CPU-udnyttelsen i vejret, og den når næsten 100 % for højere kompressionsniveauer. At øge CPU-udnyttelsen på databaseserveren er ikke nødvendigvis den bedste idé, da vi typisk ønsker, at CPU skal være tilgængelig for databasen. På den anden side, hvis vi tilfældigvis har en replika, der er dedikeret til at tage sikkerhedskopier og, lad os sige, tungere forespørgsler - en node, der ikke bruges til at betjene en OLTP-type trafik, kan vi aktivere parallel gzip for at reducere sikkerhedskopien betydeligt tid. Som det tydeligt kan ses, er det ikke en mulighed for alle, men det er bestemt noget, du kan finde nyttigt i nogle bestemte scenarier. Bare husk på, at CPU-udnyttelse er noget, du skal spore, da det vil påvirke latensen af forespørgslerne, og som gennem det vil det påvirke brugeroplevelsen - noget vi altid bør overveje, når vi arbejder med databaserne.
Xtrabackup Parallel Copy Threads
En anden indstilling, vi ønsker at fremhæve, er Xtrabackup Parallel Copy Threads. For at forstå, hvad det er, lad os tale lidt om den måde, Xtrabackup (eller MariaBackup) fungerer på. Kort sagt udfører disse værktøjer to handlinger på samme tid. De kopierer dataene, fysiske filer, fra databaseserveren til backup-placeringen, mens de overvåger InnoDB-redo-logfilerne for eventuelle opdateringer. Sikkerhedskopien består af filerne og registreringen af alle ændringer i InnoDB, der skete under backup-processen. Dette, med backup-låse eller FLUSH TABELS WITH LÆS-LÅS, gør det muligt at lave backup, der er konsistent på det tidspunkt, hvor dataoverførslen er afsluttet. Xtrabackup Parallel Copy Threads definerer antallet af tråde, der skal udføre dataoverførslen. Hvis vi sætter den til 1, kopieres én fil på samme tid. Hvis vi indstiller det til 8, kan der teoretisk overføres op til 8 filer på én gang. Selvfølgelig skal der være hurtig nok lagerplads for rent faktisk at drage fordel af sådan en indstilling. Vi skal udføre adskillige tests og ændre Xtrabackup Parallel Copy Threads fra 1 til 2 og 4 til 8. Vi vil køre test på komprimeringsniveau 6 (standard en) med og uden parallel gzip aktiveret.
De første fire sikkerhedskopier (27 - 30) er blevet oprettet uden parallel gzip, startende fra 1 til 2, 4 og 8 parallelle kopitråde. Derefter gentog vi den samme proces for sikkerhedskopier 31 til 34, denne gang ved hjælp af parallel gzip. Som du kan se, er der i vores tilfælde næppe forskel på de parallelle kopitråde. Dette vil højst sandsynligt have mere effekt, hvis vi ville øge størrelsen af datasættet. Det ville også forbedre sikkerhedskopieringsydelsen, hvis vi ville bruge hurtigere og mere pålidelig lagring. Som sædvanligt vil din kilometertal variere, og i forskellige miljøer kan denne indstilling påvirke backupprocessen mere, end hvad vi ser her.
Netværksregulering
Til sidst vil vi i denne del af vores korte serie gerne tale om muligheden for at begrænse netværksforbruget.
Som du måske har set, kan sikkerhedskopier gemmes lokalt på noden eller det kan også streames til controller-værten. Dette sker over netværket, og som standard vil det blive gjort "så hurtigt som muligt".
I nogle tilfælde, hvor din netværksgennemstrømning er begrænset (for eksempel skyforekomster), vil du måske reducere netværksforbruget forårsaget af MariaBackup ved at sætte en grænse for netværksoverførslen. Når du gør det, vil ClusterControl bruge 'pv'-værktøjet til at begrænse den tilgængelige båndbredde for processen.
Som du kan se, tog den første sikkerhedskopiering omkring 3 minutter, men da vi droslede netværkets gennemstrømning, backup tog 13 minutter og 37 sekunder.
I begge tilfælde brugte vi pigz og komprimeringsniveau 1. Grafen ovenfor viser, at regulering af netværket også reducerede CPU-udnyttelsen. Det giver mening, hvis pigz skal vente på, at netværket overfører dataene, behøver det ikke at presse hårdt på CPU'en, da den skal være inaktiv det meste af tiden.
Forhåbentlig fandt du denne korte blog interessant, og måske vil den opmuntre dig til at eksperimentere med nogle af de ikke så almindeligt anvendte funktioner og muligheder i MariaBackup. Hvis du gerne vil dele noget af din oplevelse, vil vi gerne høre fra dig i kommentarerne nedenfor.