ClusterControl può, tra l'altro, fungere da ottimo strumento per aiutarti a progettare ed eseguire la pianificazione del backup. Sono disponibili numerose funzionalità tra cui la verifica del backup, la crittografia del backup trasparente e molte altre. Ciò che manca abbastanza comunemente è la capacità di ClusterControl di ottimizzare gli strumenti di backup che utilizziamo per creare il backup. In questo blog vorremmo esaminare alcune delle impostazioni che possono essere applicate a MariaBackup. Iniziamo.
Configurazione iniziale
La configurazione iniziale è un cluster MariaDB con un master e una replica che è in questo momento in ritardo a causa dell'importazione dei dati in esecuzione in background.
Abbiamo due nodi ProxySQL e due nodi Keepalived, fornendo IP virtuale e assicurandoci che ProxySQL sia raggiungibile. Stiamo popolando il cluster (quindi il ritardo) con i dati generati da sysbench. Abbiamo usato il seguente comando per attivare questo processo:
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
Questo genererà circa 7,6 GB di dati su cui testeremo diverse impostazioni di backup.
Impostazioni di compressione
Come accennato, ci sono alcune impostazioni che puoi utilizzare per modificare MariaBackup e altri strumenti coinvolti nel processo di backup.
In questo post del blog vorremmo concentrarci sul livello di compressione e vedere se ha un qualsiasi tipo di impatto reale sul nostro processo di backup. Cambia la durata della corsa di backup? Cambia la dimensione del backup? Come? Ha senso usare effettivamente qualcosa di diverso dall'impostazione predefinita? Diamo un'occhiata a breve.
Eseguiremo i backup utilizzando tutte le impostazioni dal menu a discesa Livello di compressione:
I backup verranno archiviati sul nodo, localmente, per ridurre al minimo l'impatto causato dalla rete. Utilizzeremo MariaBackup completo. I dati nel database non sono crittografati o compressi in alcun modo.
Inizieremo 9 processi di backup, ciascuno con una diversa impostazione del livello di compressione. Questa impostazione viene passata a gzip che viene utilizzato, per impostazione predefinita, per comprimere i dati. Quello che ci aspettiamo di vedere è un aumento del tempo di esecuzione del backup e una riduzione delle dimensioni del backup quando aumenteremo questa impostazione.
Come puoi vedere, ad eccezione del backup 4, che possiamo conta solo come una fluttuazione transitoria, il tempo di esecuzione del backup aumenta a partire da 3 minuti e 41 secondi fino a 17 minuti e 57 secondi. La dimensione del backup diminuisce da 3,5 GB a 3,3 GB. Possiamo anche controllare la dimensione esatta del backup:
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
Ciò conferma che la dimensione del backup, infatti, diminuisce ad ogni livello di compressione ma le differenze sono piuttosto piccole tra il primo e l'ultimo livello che abbiamo testato. Il backup più piccolo ha il 93,2% delle dimensioni di quello più grande. D'altra parte, il suo tempo di esecuzione (1077 secondi) è quasi 5 volte più lungo del tempo di esecuzione del backup più grande (221 secondi).
Tieni presente che il tuo chilometraggio varierà. È possibile utilizzare dati che si comprimono meglio, rendendo più significativo l'impatto del livello di compressione. Sulla base dell'esito di questo test, per il set di dati sysbench non ha senso utilizzare un livello di compressione superiore a 3.
Compressione Qpress
Un'altra opzione che vorremmo testare oggi è la compressione Qpress. Qpress è un metodo di compressione che può essere utilizzato per sostituire gzip.
Come puoi vedere, è decisamente più veloce di gzip ma viene fornito con un aumento significativo della dimensione dei dati. Dopo 100 secondi di compressione, abbiamo ottenuto 4,6 GB di dati.
Scegliere il metodo di compressione più adatto potrebbe richiedere una serie di test ma, come speriamo tu possa vedere, è sicuramente importante farlo. Per set di dati di grandi dimensioni, essere in grado di scambiare un archivio un po' più grande con un processo di backup quasi 5 volte più veloce può essere abbastanza utile. Se prendiamo in considerazione l'utilizzo di Qpress, possiamo scambiare spazio su disco anche con un processo di backup 10 volte più veloce. Ciò può significare una differenza tra 20 ore di backup e 2 ore di backup. Certo, l'aumento dello spazio su disco necessario per archiviare tali dati sarà visibile ma poi, a pensarci bene, è possibile ottenere un volume del disco più grande. Aggiungere ore aggiuntive alla giornata, quando 24 ore non sono sufficienti per eseguire il backup, non lo è.
Ci auguriamo che questo breve blog sia stato utile per te e ti incoraggi a giocare e modificare diverse impostazioni che possono essere utilizzate per MariaBackup. Se desideri condividere la tua esperienza con loro, ci piacerebbe vedere i tuoi commenti.