ClusterControl peut, entre autres, agir comme un excellent outil pour vous aider à concevoir et à exécuter le calendrier de sauvegarde. De nombreuses fonctionnalités sont disponibles, notamment la vérification des sauvegardes, le cryptage transparent des sauvegardes et bien d'autres. Ce qui manque le plus souvent, c'est la capacité de ClusterControl à régler les outils de sauvegarde que nous utilisons pour créer la sauvegarde. Dans ce blog, nous aimerions passer en revue certains des paramètres qui peuvent être appliqués à MariaBackup. Commençons.
Configuration initiale
La configuration initiale est un cluster MariaDB avec un maître et un réplica qui est en retard en ce moment en raison de l'importation des données exécutées en arrière-plan.
Nous avons deux nœuds ProxySQL et deux nœuds Keepalived, fournissant une adresse IP virtuelle et s'assurant que le ProxySQL est accessible. Nous remplissons le cluster (donc le décalage) avec des données générées par sysbench. Nous avons utilisé la commande suivante pour déclencher ce processus :
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 prepareCela générera environ 7,6 Go de données sur lesquelles nous allons tester différents paramètres de sauvegarde.
Paramètres de compression
Comme nous l'avons mentionné, il existe de nombreux paramètres que vous pouvez utiliser pour modifier MariaBackup et d'autres outils impliqués dans le processus de sauvegarde.
Dans cet article de blog, nous aimerions nous concentrer sur le niveau de compression et voir si cela a un impact réel sur notre processus de sauvegarde. Cela change-t-il la durée de l'exécution de la sauvegarde ? Cela change-t-il la taille de la sauvegarde ? Comment? Est-il utile d'utiliser autre chose que le paramètre par défaut ? Jetons-y un coup d'œil sous peu.
Nous allons exécuter des sauvegardes en utilisant tous les paramètres du menu déroulant Niveau de compression :
Les sauvegardes seront stockées sur le nœud, localement, pour minimiser l'impact causé par le réseau. Nous allons utiliser MariaBackup complet. Les données de la base de données ne sont ni cryptées ni compressées de quelque manière que ce soit.
Nous allons démarrer 9 tâches de sauvegarde, chacune avec un réglage différent du niveau de compression. Ce paramètre est passé à gzip qui est utilisé, par défaut, pour compresser les données. Ce que nous nous attendons à voir, c'est une augmentation du temps d'exécution de la sauvegarde et une réduction de la taille de la sauvegarde lorsque nous augmenterons ce paramètre.
Comme vous pouvez le voir, à l'exception de la sauvegarde 4, que nous pouvons compté comme une fluctuation transitoire, le temps d'exécution de la sauvegarde augmente à partir de 3 minutes et 41 secondes jusqu'à 17 minutes et 57 secondes. La taille de la sauvegarde passe de 3,5 Go à 3,3 Go. Nous pouvons également vérifier la taille exacte de la sauvegarde :
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-9Cela confirme que la taille de la sauvegarde, en fait, diminue avec chaque niveau de compression mais les différences sont assez faibles entre le premier et le dernier niveau que nous avons testé. La plus petite sauvegarde a 93,2 % de la taille de la plus grande. En revanche, son temps d'exécution (1077 secondes) est presque 5 fois plus long que le temps d'exécution de la plus grande sauvegarde (221 secondes).
Veuillez garder à l'esprit que votre kilométrage variera. Vous pouvez utiliser des données qui se compressent mieux, ce qui rend l'impact du niveau de compression plus important. Sur la base des résultats de ce test, pour l'ensemble de données sysbench, il n'est guère logique d'utiliser un niveau de compression supérieur à 3.
Compression Qpress
Une autre option que nous aimerions tester aujourd'hui est la compression Qpress. Qpress est une méthode de compression qui peut être utilisée pour remplacer gzip.
Comme vous pouvez le voir, il est définitivement plus rapide que gzip mais il est fourni avec une augmentation significative de la taille des données. Après 100 secondes de compression, nous avons obtenu 4,6 Go de données.
Choisir la méthode de compression la plus appropriée peut nécessiter une série de tests mais, comme nous espérons que vous pouvez le voir, cela fait définitivement un point. Pour les grands ensembles de données, il peut être très pratique d'échanger une archive un peu plus grande contre un processus de sauvegarde presque 5 fois plus rapide. Si nous envisageons d'utiliser Qpress, nous pouvons échanger de l'espace disque même contre un processus de sauvegarde 10 fois plus rapide. Cela peut signifier une différence entre 20 heures de sauvegarde et 2 heures de sauvegarde. Bien sûr, l'augmentation de l'espace disque nécessaire pour stocker de telles données sera visible mais, quand on y pense, obtenir un volume de disque plus important est faisable. Ajouter des heures supplémentaires à la journée, alors que 24 heures ne suffisent pas pour effectuer la sauvegarde, ne l'est pas.
Nous espérons que ce court blog a été perspicace pour vous et qu'il vous encouragera à jouer avec et à modifier différents paramètres pouvant être utilisés pour MariaBackup. Si vous souhaitez partager votre expérience avec eux, nous serions ravis de lire vos commentaires.
