Dans la partie précédente, nous avons testé le temps de sauvegarde et l'efficacité de la compression pour différents niveaux et méthodes de compression de sauvegarde. Dans ce blog, nous poursuivrons nos efforts et nous parlerons d'autres paramètres que, probablement, la plupart des utilisateurs ne changent pas vraiment, mais ils peuvent avoir un effet visible sur le processus de sauvegarde.
La configuration est la même que dans la partie précédente :nous allons utiliser le cluster de réplication maître-esclave MariaDB avec ProxySQL et Keepalived.
Nous avons généré 7,6 Go de données à l'aide de 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 prepareUtiliser PIGZ
Cette fois, nous allons activer Utiliser PIGZ pour gzip parallèle pour nos sauvegardes. Comme précédemment, nous testerons chaque niveau de compression pour voir comment il fonctionne.
Nous stockons la sauvegarde localement sur l'instance, l'instance est configurée avec 4 vCPU.
Le résultat est en quelque sorte attendu. Le processus de sauvegarde était nettement plus rapide que lorsque nous n'utilisions qu'un seul cœur de processeur. La taille de la sauvegarde reste à peu près la même, il n'y a aucune raison réelle pour qu'elle change de manière significative. Il est clair que l'utilisation de pigz améliore le temps de sauvegarde. Il y a cependant un côté sombre à l'utilisation de gzip parallèle, et c'est l'utilisation du processeur :
Comme vous pouvez le constater, l'utilisation du processeur monte en flèche et atteint presque 100 % pour des niveaux de compression plus élevés. Augmenter l'utilisation du processeur sur le serveur de base de données n'est pas nécessairement la meilleure idée car, généralement, nous souhaitons que le processeur soit disponible pour la base de données. D'un autre côté, s'il nous arrive d'avoir une réplique dédiée à la prise de sauvegardes et, disons, des requêtes plus lourdes - un nœud qui n'est pas utilisé pour servir un type de trafic OLTP, nous pouvons activer gzip parallèle pour réduire considérablement la sauvegarde temps. Comme on peut le voir clairement, ce n'est pas une option pour tout le monde, mais c'est certainement quelque chose que vous pouvez trouver utile dans certains scénarios particuliers. Gardez simplement à l'esprit que l'utilisation du processeur est quelque chose que vous devez suivre car cela aura un impact sur la latence des requêtes et, à travers elle, cela aura un impact sur l'expérience utilisateur - quelque chose que nous devrions toujours prendre en compte lorsque nous travaillons avec les bases de données.
Threads de copie parallèle Xtrabackup
Un autre paramètre que nous souhaitons mettre en évidence est Xtrabackup Parallel Copy Threads. Pour comprendre de quoi il s'agit, parlons un peu du fonctionnement de Xtrabackup (ou MariaBackup). En bref, ces outils effectuent deux actions en même temps. Ils copient les données, les fichiers physiques, du serveur de base de données vers l'emplacement de sauvegarde tout en surveillant les journaux redo InnoDB pour toute mise à jour. La sauvegarde se compose des fichiers et de l'enregistrement de toutes les modifications apportées à InnoDB qui se sont produites pendant le processus de sauvegarde. Ceci, avec des verrous de sauvegarde ou FLUSH TABLES WITH READ LOCK, permet de créer une sauvegarde cohérente au moment où le transfert de données est terminé. Les threads de copie parallèle Xtrabackup définissent le nombre de threads qui effectueront le transfert de données. Si nous le mettons à 1, un fichier sera copié en même temps. Si nous le réglons sur 8, théoriquement jusqu'à 8 fichiers peuvent être transférés à la fois. Bien sûr, il doit y avoir un stockage suffisamment rapide pour réellement bénéficier d'un tel réglage. Nous allons effectuer plusieurs tests, en modifiant les threads de copie parallèle Xtrabackup de 1 à 2 et de 4 à 8. Nous allons exécuter des tests au niveau de compression 6 (par défaut) avec et sans gzip parallèle activé.
Les quatre premières sauvegardes (27 - 30) ont été créées sans gzip parallèle, à partir de 1 à 2, 4 et 8 threads de copie parallèles. Ensuite, nous avons répété le même processus pour les sauvegardes 31 à 34, cette fois en utilisant gzip parallèle. Comme vous pouvez le voir, dans notre cas, il n'y a guère de différence entre les threads de copie parallèles. Cela aura probablement plus d'impact si nous augmentons la taille de l'ensemble de données. Cela améliorerait également les performances de sauvegarde si nous utilisions un stockage plus rapide et plus fiable. Comme d'habitude, votre kilométrage variera et dans différents environnements, ce paramètre peut affecter le processus de sauvegarde plus que ce que nous voyons ici.
Limitation du réseau
Enfin, dans cette partie de notre courte série, nous aimerions parler de la possibilité de limiter l'utilisation du réseau.
Comme vous l'avez peut-être vu, les sauvegardes peuvent être stockées localement sur le nœud ou il peut également être diffusé sur l'hôte du contrôleur. Cela se passe sur le réseau et, par défaut, cela se fera « aussi vite que possible ».
Dans certains cas, où le débit de votre réseau est limité (instances cloud, par exemple), vous souhaiterez peut-être réduire l'utilisation du réseau causée par MariaBackup en définissant une limite sur le transfert réseau. Lorsque vous faites cela, ClusterControl utilisera l'outil "pv" pour limiter la bande passante disponible pour le processus.
Comme vous pouvez le voir, la première sauvegarde a pris environ 3 minutes mais lorsque nous limitait le débit du réseau, la sauvegarde prenait 13 minutes et 37 secondes.
Dans les deux cas, nous avons utilisé pigz et le niveau de compression 1. Le graphique ci-dessus montre que la limitation du réseau a également réduit l'utilisation du processeur. C'est logique, si pigz doit attendre que le réseau transfère les données, il n'a pas à pousser fort sur le CPU car il doit rester inactif la plupart du temps.
J'espère que vous avez trouvé ce court blog intéressant et qu'il vous encouragera peut-être à expérimenter certaines des fonctionnalités et options peu utilisées de MariaBackup. Si vous souhaitez partager une partie de votre expérience, nous aimerions avoir de vos nouvelles dans les commentaires ci-dessous.
