sql >> Database >  >> RDS >> MariaDB

ClusterControl - Geavanceerd back-upbeheer - mariabackup Deel I

ClusterControl kan onder andere fungeren als een geweldig hulpmiddel om u te helpen bij het ontwerpen en uitvoeren van het back-upschema. Er zijn tal van functies beschikbaar, waaronder back-upverificatie, transparante back-upversleuteling en vele andere. Wat vrij vaak ontbreekt, is de mogelijkheid van ClusterControl om back-uptools af te stemmen die we gebruiken om de back-up te maken. In deze blog willen we enkele instellingen bespreken die op MariaBackup kunnen worden toegepast. Laten we beginnen.

Eerste installatie

De initiële installatie is een MariaDB-cluster met één master en één replica die loopt op dit moment achter vanwege het importeren van de gegevens die op de achtergrond worden uitgevoerd.

We hebben twee ProxySQL-knooppunten en twee Keepalived-knooppunten, die virtuele IP bieden en ervoor zorgen dat de ProxySQL bereikbaar is. We vullen het cluster (dus de lag) met gegevens die zijn gegenereerd door sysbench. We hebben de volgende opdracht gebruikt om dit proces te activeren:

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

Dit genereert ongeveer 7,6 GB aan gegevens waarop we verschillende back-upinstellingen gaan testen.

Compressie-instellingen

Zoals we al zeiden, zijn er nogal wat instellingen die je kunt gebruiken om MariaBackup en andere tools die betrokken zijn bij het back-upproces aan te passen.

In deze blogpost willen we ons concentreren op het compressieniveau en als het enige echte impact heeft op ons back-upproces. Verandert het de lengte van de back-uprun? Verandert het de grootte van de back-up? Hoe? Heeft het enig zin om iets anders te gebruiken dan de standaardinstelling? Laten we er binnenkort eens naar kijken.

We gaan back-ups maken met alle instellingen uit de vervolgkeuzelijst Compressieniveau:

Back-ups worden lokaal op het knooppunt opgeslagen om de veroorzaakte impact te minimaliseren door het netwerk. We gaan de volledige MariaBackup gebruiken. Gegevens in de database zijn op geen enkele manier versleuteld of gecomprimeerd.

We zullen 9 back-uptaken starten, elk met een andere instelling van het compressieniveau. Deze instelling wordt doorgegeven aan gzip dat standaard wordt gebruikt om de gegevens te comprimeren. Wat we verwachten te zien, is een toename van de uitvoeringstijd van back-ups en een vermindering van de back-upgrootte wanneer we deze instelling verhogen.

Zoals u kunt zien, met uitzondering van back-up 4, die we kunnen reken maar uit als een voorbijgaande fluctuatie, de uitvoeringstijd van de back-up neemt toe vanaf 3 minuten en 41 seconden tot 17 minuten en 57 seconden. De back-upgrootte neemt af van 3,5 GB naar 3,3 GB. We kunnen ook de exacte grootte van de back-up controleren:

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

Dit bevestigt dat de back-upgrootte in feite afneemt met elk compressieniveau, maar de verschillen zijn vrij klein tussen het eerste en het laatste niveau dat we hebben getest. De kleinste back-up heeft 93,2% van de grootte van de grootste. Aan de andere kant is de uitvoeringstijd (1077 seconden) bijna 5 keer langer dan de uitvoeringstijd van de grootste back-up (221 seconden).

Houd er rekening mee dat uw kilometerstand kan variëren. U kunt gegevens gebruiken die beter worden gecomprimeerd, waardoor de impact van het compressieniveau groter wordt. Op basis van de uitkomst van deze test heeft het voor de sysbench-dataset nauwelijks zin om een ​​compressieniveau hoger dan 3 te gebruiken.

Qpress-compressie

Een andere optie die we vandaag willen testen, is de Qpress-compressie. Qpress is een compressiemethode die kan worden gebruikt om gzip te vervangen.

Zoals je kunt zien, is het zeker sneller dan gzip, maar het wordt geleverd met een aanzienlijke toename van de omvang van de gegevens. Na 100 seconden compressie kregen we 4,6 GB aan gegevens.

Het kiezen van de meest geschikte compressiemethode kan een reeks tests vereisen, maar zoals we hopen dat je kunt zien, is het zeker een punt om dat te doen. Voor grote datasets kan het best handig zijn om een ​​wat groter archief in te ruilen voor een bijna 5 keer sneller back-upproces. Als we overwegen om Qpress te gebruiken, kunnen we zelfs schijfruimte inruilen voor een 10 keer sneller back-upproces. Dit kan een verschil betekenen tussen 20 uur back-up en 2 uur back-up. Natuurlijk zal de toename van de schijfruimte die nodig is voor het opslaan van dergelijke gegevens zichtbaar zijn, maar als je erover nadenkt, is het mogelijk om een ​​groter schijfvolume te krijgen. Extra uren aan de dag toevoegen, wanneer 24 uur niet genoeg zijn om de back-up te maken, is dat niet.

We hopen dat deze korte blog je inzicht heeft gegeven en dat het je zal aanmoedigen om te spelen met de verschillende instellingen die voor MariaBackup kunnen worden gebruikt en deze aan te passen. Als u uw ervaringen met hen wilt delen, zien we graag uw opmerkingen tegemoet.


  1. oracle sql:update indien bestaat, anders invoegen

  2. Mysql Zoekprestaties verbeteren met jokertekens (%%)

  3. Alle tabellen in een Postgres-database afkappen

  4. Toegang tot database beperken in PostgreSQL