I föregående del har vi testat säkerhetskopieringstiden och effektiviteten av komprimeringen för olika säkerhetskopieringskomprimeringsnivåer och -metoder. I den här bloggen kommer vi att fortsätta våra ansträngningar och vi kommer att prata om fler inställningar som förmodligen de flesta av användarna inte riktigt ändrar men de kan ha en synlig effekt på säkerhetskopieringsprocessen.
Inställningen är densamma som i föregående del:vi kommer att använda MariaDB master-slave replikeringskluster med ProxySQL och Keepalived.
Vi har genererat 7,6 GB data med hjälp av 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 prepareAnvända PIGZ
Den här gången kommer vi att aktivera Använd PIGZ för parallell gzip för våra säkerhetskopior. Som tidigare kommer vi att testa varje komprimeringsnivå för att se hur den fungerar.
Vi lagrar säkerhetskopian lokalt på instansen, instansen är konfigurerad med 4 vCPU:er.
Resultatet är ungefär förväntat. Säkerhetskopieringsprocessen var betydligt snabbare än när vi bara använde en enda CPU-kärna. Storleken på säkerhetskopian förblir i stort sett densamma, det finns ingen verklig anledning till att den ändras nämnvärt. Det är tydligt att användningen av pigz förbättrar backuptiden. Det finns dock en mörk sida av att använda parallell gzip, och det är CPU-användning:
Som du kan se skjuter CPU-användningen i höjden och den når nästan 100 % för högre kompressionsnivåer. Att öka CPU-användningen på databasservern är inte nödvändigtvis den bästa idén eftersom vi vanligtvis vill att CPU ska vara tillgänglig för databasen. Å andra sidan, om vi råkar ha en replik som är dedikerad till att ta säkerhetskopior och, låt oss säga, tyngre frågor - en nod som inte används för att betjäna en OLTP-typ av trafik, kan vi aktivera parallell gzip för att kraftigt minska säkerhetskopieringen tid. Som tydligt kan ses är det inte ett alternativ för alla men det är definitivt något som du kan hitta användbart i vissa speciella scenarier. Tänk bara på att CPU-användning är något du behöver spåra eftersom det kommer att påverka fördröjningen av frågorna och, liksom genom det, kommer det att påverka användarupplevelsen - något vi alltid bör tänka på när vi arbetar med databaserna.
Xtrabackup Parallel Copy Threads
En annan inställning vi vill lyfta fram är Xtrabackup Parallel Copy Threads. För att förstå vad det är, låt oss prata lite om hur Xtrabackup (eller MariaBackup) fungerar. Kort sagt, dessa verktyg utför två åtgärder samtidigt. De kopierar data, fysiska filer, från databasservern till säkerhetskopieringsplatsen medan de övervakar InnoDB-redologgarna för eventuella uppdateringar. Säkerhetskopieringen består av filerna och registreringen av alla ändringar i InnoDB som hände under säkerhetskopieringen. Detta, med säkerhetskopieringslås eller SPOLATABELLER MED LÄSSLÅS, gör det möjligt att skapa en säkerhetskopia som är konsekvent vid den tidpunkt då dataöverföringen har slutförts. Xtrabackup Parallel Copy Threads definierar antalet trådar som ska utföra dataöverföringen. Om vi sätter den till 1 kommer en fil att kopieras samtidigt. Om vi ställer in den till 8 kan teoretiskt sett upp till 8 filer överföras på en gång. Naturligtvis måste det finnas tillräckligt snabbt lagringsutrymme för att faktiskt dra nytta av en sådan inställning. Vi kommer att utföra flera tester och ändra Xtrabackup Parallel Copy Threads från 1 till 2 och 4 till 8. Vi kommer att köra tester på komprimeringsnivå 6 (standard ett) med och utan parallell gzip aktiverad.
De fyra första säkerhetskopiorna (27 - 30) har skapats utan parallell gzip, från 1 till 2, 4 och 8 parallella kopiatrådar. Sedan upprepade vi samma process för säkerhetskopior 31 till 34, denna gång med parallell gzip. Som du kan se är det i vårt fall knappast någon skillnad mellan de parallella kopiatrådarna. Detta kommer sannolikt att få större effekt om vi skulle öka storleken på datamängden. Det skulle också förbättra säkerhetskopieringsprestandan om vi skulle använda snabbare, mer pålitlig lagring. Som vanligt kommer din körsträcka att variera och i olika miljöer kan den här inställningen påverka säkerhetskopieringsprocessen mer än vad vi ser här.
Nätverksbegränsning
Slutligen, i den här delen av vår korta serie vill vi prata om möjligheten att strypa nätverksanvändningen.
Som du kanske har sett kan säkerhetskopior lagras lokalt på noden eller den kan också strömmas till styrenhetsvärden. Detta sker över nätverket och som standard kommer det att göras "så snabbt som möjligt".
I vissa fall, där din nätverksgenomströmning är begränsad (till exempel molninstanser), kanske du vill minska nätverksanvändningen som orsakas av MariaBackup genom att sätta en gräns för nätverksöverföringen. När du gör det kommer ClusterControl att använda "pv"-verktyget för att begränsa den tillgängliga bandbredden för processen.
Som du kan se tog den första säkerhetskopieringen cirka 3 minuter men när vi strypte nätverkets genomströmning, säkerhetskopieringen tog 13 minuter och 37 sekunder.
I båda fallen använde vi pigz och komprimeringsnivå 1. Grafen ovan visar att strypning av nätverket också minskade CPU-användningen. Det är vettigt, om pigz måste vänta på att nätverket ska överföra data behöver den inte trycka hårt på CPU:n eftersom den måste vara inaktiv för det mesta.
Förhoppningsvis fann du den här korta bloggen intressant och kanske kommer den att uppmuntra dig att experimentera med några av de inte så vanligt använda funktionerna och alternativen i MariaBackup. Om du vill dela med dig av dina erfarenheter vill vi gärna höra från dig i kommentarerna nedan.