sql >> Databasteknik >  >> RDS >> MariaDB

ClusterControl - Advanced Backup Management - mariabackup del I

ClusterControl kan bland annat fungera som ett utmärkt verktyg för att hjälpa dig designa och utföra säkerhetskopieringsschemat. Många funktioner är tillgängliga, inklusive verifiering av säkerhetskopiering, transparent kryptering av säkerhetskopiering och många andra. Vad som ganska ofta saknas är förmågan hos ClusterControl att ställa in säkerhetskopieringsverktyg som vi använder för att skapa säkerhetskopian. I den här bloggen vill vi gå igenom några av de inställningar som kan tillämpas på MariaBackup. Låt oss komma igång.

Initial installation

Den initiala installationen är ett MariaDB-kluster med en master och en replik som är släpar för närvarande på grund av importen av data som körs i bakgrunden.

Vi har två ProxySQL-noder och två Keepalive-noder, som tillhandahåller virtuell IP och ser till att ProxySQL är tillgänglig. Vi fyller klustret (därmed eftersläpningen) med data som genereras av sysbench. Vi har använt följande kommando för att utlösa denna process:

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

Detta genererar cirka 7,6 GB data som vi ska testa olika säkerhetskopieringsinställningar på.

Kompressionsinställningar

Som vi nämnde finns det en hel del inställningar som du kan använda för att justera MariaBackup och andra verktyg som är involverade i säkerhetskopieringsprocessen.

I det här blogginlägget vill vi fokusera på komprimeringsnivån och se om det har någon form av verklig inverkan på vår säkerhetskopieringsprocess. Ändrar det längden på säkerhetskopieringen? Ändrar det storleken på säkerhetskopian? På vilket sätt? Är det någon mening med att faktiskt använda något annat än standardinställningen? Låt oss ta en titt på det snart.

Vi kommer att köra säkerhetskopior med alla inställningar från rullgardinsmenyn Kompressionsnivå:

Säkerhetskopieringar kommer att lagras på noden, lokalt, för att minimera påverkan som orsakas av nätverket. Vi kommer att använda fullständig MariaBackup. Data i databasen är inte krypterad eller komprimerad på något sätt.

Vi kommer att starta 9 säkerhetskopieringsjobb, var och en med olika inställning av komprimeringsnivån. Den här inställningen skickas till gzip som används som standard för att komprimera data. Det vi förväntar oss att se är en ökning av körningstiden för säkerhetskopiering och minskning av säkerhetskopieringsstorleken när vi ökar den här inställningen.

Som du kan se, med undantag för backup 4, som vi kan Räkna bara ut som en övergående fluktuation, säkerhetskopieringstiden ökar från 3 minuter och 41 sekunder upp till 17 minuter och 57 sekunder. Säkerhetskopieringsstorleken minskar från 3,5 GB till 3,3 GB. Vi kan också kontrollera den exakta storleken på säkerhetskopian:

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

Detta bekräftar att säkerhetskopieringsstorleken faktiskt minskar med varje komprimeringsnivå men skillnaderna är ganska små mellan den första och den sista nivån vi testade. Minsta backup har 93,2% av storleken på den största. Å andra sidan är dess körtid (1077 sekunder) nästan 5 gånger längre än körtiden för den största säkerhetskopian (221 sekunder).

Tänk på att din körsträcka kommer att variera. Du kan använda data som komprimerar bättre, vilket gör effekten av komprimeringsnivån mer betydande. Baserat på resultatet av detta test är det knappast meningsfullt att använda en komprimeringsnivå som är högre än 3 för sysbench-dataset.

Qpress-komprimering

Ett annat alternativ som vi skulle vilja testa idag är Qpress-komprimeringen. Qpress är en komprimeringsmetod som kan användas för att ersätta gzip.

Som du kan se är det definitivt snabbare än gzip men det kommer med en betydande ökning av datastorleken. Efter 100 sekunders komprimering fick vi 4,6 GB data.

Att välja den mest lämpliga komprimeringsmetoden kan kräva en rad tester, men som vi hoppas du kan se är det definitivt en poäng att göra det. För stora datamängder kan det vara ganska praktiskt att kunna byta ett något större arkiv mot en nästan 5 gånger snabbare säkerhetskopiering. Om vi ​​överväger att använda Qpress kan vi byta diskutrymme även för en 10 gånger snabbare säkerhetskopieringsprocess. Detta kan betyda skillnaden mellan 20 timmars backup och 2 timmars backup. Visst, ökningen av diskutrymmet som behövs för att lagra sådan data kommer att vara synlig, men när du tänker efter är det möjligt att få en större diskvolym. Att lägga till ytterligare timmar till dygnet, när 24 timmar inte räcker för att få säkerhetskopieringen klar, är inte det.

Vi hoppas att den här korta bloggen var insiktsfull för dig och att den kommer att uppmuntra dig att leka med och justera olika inställningar som kan användas för MariaBackup. Om du vill dela din upplevelse med dem vill vi gärna se dina kommentarer.


  1. Hur RandomBlob() fungerar i SQLite

  2. Hur man ansluter till flera SQL-servrar med ett klick (registrerad servergrupp) - SQL Server / TSQL självstudie del 5

  3. Chen Notation

  4. Hur får man exportutdata i riktigt CSV-format i SQL Server Management Studio?