ClusterControl kan blandt andet fungere som et fantastisk værktøj til at hjælpe dig med at designe og udføre backup-planen. Adskillige funktioner er tilgængelige, herunder sikkerhedskopieringsbekræftelse, gennemsigtig backupkryptering og mange andre. Hvad der ofte mangler, er ClusterControls evne til at tune sikkerhedskopieringsværktøjer, som vi bruger til at oprette sikkerhedskopien. I denne blog vil vi gerne gennemgå nogle af de indstillinger, der kan anvendes på MariaBackup. Lad os komme i gang.
Indledende opsætning
Den indledende opsætning er en MariaDB-klynge med en master og en replika, som er halter i øjeblikket på grund af importen af de data, der kører i baggrunden.
Vi har to ProxySQL-noder og to Keepalived-noder, der leverer virtuel IP og sikrer, at ProxySQL er tilgængelig. Vi udfylder klyngen (dermed forsinkelsen) med data genereret af sysbench. Vi har brugt følgende kommando til at udløse denne proces:
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 prepare
Dette vil generere omkring 7,6 GB data, som vi skal teste forskellige sikkerhedskopieringsindstillinger på.
Kompressionsindstillinger
Som vi nævnte, er der en del indstillinger, som du kan bruge til at justere MariaBackup og andre værktøjer, der er involveret i sikkerhedskopieringsprocessen.
I dette blogindlæg vil vi gerne fokusere på komprimeringsniveauet og se hvis det har nogen form for reel indflydelse på vores backup-proces. Ændrer det længden af sikkerhedskopieringen? Ændrer det størrelsen på sikkerhedskopien? Hvordan? Giver det nogen mening rent faktisk at bruge noget andet end standardindstillingen? Lad os tage et kig på det om lidt.
Vi vil køre sikkerhedskopier ved at bruge alle indstillingerne fra rullemenuen Kompressionsniveau:
Sikkerhedskopier vil blive gemt på noden lokalt for at minimere den forårsagede påvirkning af netværket. Vi kommer til at bruge fuld MariaBackup. Data i databasen er ikke krypteret eller komprimeret på nogen måde.
Vi starter 9 backupjob, hver med en anden indstilling af komprimeringsniveauet. Denne indstilling overføres til gzip, der som standard bruges til at komprimere dataene. Det, vi forventer at se, er en stigning i sikkerhedskopieringsudførelsestiden og reduktion af sikkerhedskopieringsstørrelsen, når vi øger denne indstilling.
Som du kan se, med undtagelse af backup 4, som vi kan tæller blot ud som en forbigående udsving, backup-udførelsestiden øges fra 3 minutter og 41 sekunder op til 17 minutter og 57 sekunder. Sikkerhedskopieringsstørrelsen falder fra 3,5 GB til 3,3 GB. Vi kan også kontrollere den nøjagtige størrelse af sikkerhedskopien:
du -s /root/backups/*
3653288 /root/backups/BACKUP-1
3643088 /root/backups/BACKUP-2
3510420 /root/backups/BACKUP-3
3486304 /root/backups/BACKUP-4
3449392 /root/backups/BACKUP-5
3437504 /root/backups/BACKUP-6
3429152 /root/backups/BACKUP-7
3425492 /root/backups/BACKUP-8
3405348 /root/backups/BACKUP-9
Dette bekræfter, at sikkerhedskopieringsstørrelsen faktisk falder for hvert komprimeringsniveau, men forskellene er ret små mellem det første og det sidste niveau, vi testede. Mindste backup har 93,2 % af størrelsen på den største. På den anden side er dens eksekveringstid (1077 sekunder) næsten 5 gange længere end eksekveringstiden for den største backup (221 sekunder).
Husk venligst, at dit kilometertal vil variere. Du kan bruge data, der komprimerer bedre, hvilket gør indvirkningen af komprimeringsniveauet større. Baseret på resultatet af denne test giver det næppe mening for sysbench-datasæt at bruge et komprimeringsniveau højere end 3.
Qpress-komprimering
En anden mulighed, vi gerne vil teste i dag, er Qpress-komprimeringen. Qpress er en komprimeringsmetode, der kan bruges til at erstatte gzip.
Som du kan se, er det bestemt hurtigere end gzip, men det kommer med en markant stigning i datastørrelsen. Efter 100 sekunders komprimering fik vi 4,6 GB data.
At vælge den bedst egnede komprimeringsmetode kan kræve en række tests, men som vi håber, du kan se, er det bestemt vigtigt at gøre det. For store datasæt kan det være ganske praktisk at kunne bytte et noget større arkiv til en næsten 5 gange hurtigere backup-proces. Hvis vi overvejer at bruge Qpress, kan vi bytte diskplads selv for en 10 gange hurtigere backup-proces. Dette kan betyde en forskel mellem 20 timers backup og 2 timers backup. Sikker på, at stigningen i den nødvendige diskplads til lagring af sådanne data vil være synlig, men når du tænker over det, er det muligt at få en større diskvolumen. Det er ikke at tilføje yderligere timer til dagen, hvor 24 timer ikke er nok til at få lavet backup.
Vi håber, at denne korte blog var indsigtsfuld for dig, og den vil opmuntre dig til at lege med og tilpasse forskellige indstillinger, der kan bruges til MariaBackup. Hvis du gerne vil dele din oplevelse med dem, vil vi meget gerne se dine kommentarer.