La fonction de gestion centralisée des sauvegardes de ClusterControl prend en charge les sauvegardes standard mysqldump, Percona Xtrabackup et Mariabackup fournies par MariaDB. Nous pensons que les arguments de ligne de commande choisis pour les méthodes respectives sont optimaux pour la plupart des charges de travail de base de données et conformes aux meilleures pratiques de sauvegarde MySQL. Nous nous basons sur tous les retours que nous avons reçus au fil des ans, lorsque nous travaillons avec des DBA et des administrateurs système. Cependant, la configuration peut ne pas être suffisante dans certaines circonstances. Vous voudrez peut-être toujours le personnaliser en fonction de votre environnement, en utilisant la méthode de sauvegarde correspondante. Dans cet article, nous vous montrerons comment procéder.
mysqldump
Pour effectuer une sauvegarde à partir de l'interface utilisateur de ClusterControl, accédez à la section ClusterControl -> Sélectionner un cluster -> Sauvegarde. Ici, vous pouvez voir les sauvegardes générées et vous pouvez en créer ou en planifier une nouvelle.
À partir de l'interface utilisateur de ClusterControl, nous avons différentes options pour effectuer la sauvegarde. Nous pouvons créer un fichier de vidage pour chaque base de données, activer la sauvegarde partielle, stocker la sauvegarde sur le nœud ou sur le serveur ClusterControl ; nous pouvons spécifier le répertoire et le sous-répertoire de sauvegarde, ou nous pouvons archiver automatiquement la sauvegarde dans le cloud (AWS, Google Cloud ou Azure) à l'aide de la fonctionnalité de téléchargement dans le cloud.
De plus, nous pouvons utiliser la compression, chiffrer notre sauvegarde et spécifier la période de conservation.
Par défaut, ClusterControl nous permet de choisir entre 4 types de dump différents pour effectuer la sauvegarde :
- Schéma et données :schéma et données de la base de données
- Schéma uniquement :schéma de la base de données
- Données uniquement :données de la base de données
- MySQL Db uniquement :base de données système MySQL
Disons que nous avons 5 bases de données et que nous avons choisi de toutes les sauvegarder. Voici ce que ClusterControl exécutera lors de l'exécution de la sauvegarde à l'aide de la méthode mysqldump (les commandes sont coupées avec une barre oblique inverse pour plus de lisibilité) :
- Schéma et données
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --single-transaction \ --skip-lock-tables \ --triggers \ --routines \ --events \ --set-gtid-purged=OFF \ --databases mysql proxydemo sakila sbtest mydb \ --ignore-table='mysql.innodb_index_stats' \ --ignore-table='mysql.innodb_table_stats' \ |gzip -6 -c > /root/backups/BACKUP-1/mysqldump_2018-11-06_203010_schemaanddata.sql.gz'. - Schéma uniquement
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --no-data \ --add-drop-table \ --triggers \ --routines \ --events \ --single-transaction \ --skip-comments \ --skip-lock-tables \ --set-gtid-purged=OFF \ --databases mysql proxydemo sakila sbtest mydb \ |gzip -6 -c > /root/backups/BACKUP-2/mysqldump_2018-11-06_210040_schemaonly.sql.gz'. - Données uniquement
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --no-create-info \ --single-transaction \ --skip-comments \ --skip-lock-tables \ --skip-triggers \ --skip-add-locks \ --set-gtid-purged=OFF \ --databases mysql proxydemo sakila sbtest mydb \ --ignore-table='mysql.innodb_index_stats' \ --ignore-table='mysql.innodb_table_stats' \ |gzip -6 -c > /root/backups/BACKUP-3/mysqldump_2018-11-06_210445_dataonly.sql.gz'. - Base de données MySQL uniquement
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --single-transaction \ --skip-comments \ --skip-lock-tables \ --skip-add-locks \ --set-gtid-purged=OFF mysql \ |gzip -6 -c > /root/backups/BACKUP-5/mysqldump_2018-11-06_211135_mysqldbonly.sql.gz'.
Si notre nœud MySQL génère des journaux binaires, nous aurons le paramètre master-data=2 inclus dans les commandes ci-dessus et 1 type de vidage supplémentaire disponible :
- Complet
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --master-data=1 \ --single-transaction \ --skip-lock-tables \ --skip-lock-tables \ --triggers \ --routines \ --events \ --all-databases \ |gzip -6 -c > /root/backups/BACKUP-6/mysqldump_2018-11-06_211451_complete.sql.gz'.
À partir des lignes de commande ci-dessus, nous pouvons voir que sur chaque commande mysqldump, ClusterControl inclut le fichier de configuration MySQL dans son argument --defaults-file. Grâce à cela, le processus mysqldump est capable de lire le contenu de la directive mysqldump. Par défaut, ClusterControl configure les informations d'identification de l'utilisateur de sauvegarde dans un fichier séparé dans /etc/my.cnf.d/secrets-backup.cnf et le max_allowed_packet dans my.cnf, semblable à ce qui suit :
$ mon.cnf
[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8$ secrets-backup.cnf
[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniEL'avantage est que nous pouvons inclure des options supplémentaires pour mysqldump. Malheureusement, l'argument --defaults-file ne peut être spécifié que comme argument principal. Faites attention à ce que ces derniers arguments de ligne de commande aient la priorité sur ce qui a été configuré dans my.cnf sous la directive [mysqldump] en fonction de l'ordre dans lequel ils apparaissent. Par exemple, si nous ajoutons skip-comments=0 dans my.cnf, alors qu'à la fin de la commande mysqldump, il y a un --skip-comments (ou --skip-comments=1), le premier sera ignoré et ce dernier sera utilisé.
Néanmoins, nous pouvons toujours l'utiliser dans le cadre de notre personnalisation de sauvegarde en utilisant d'autres options de sauvegarde mysqldump. Par exemple, nous pouvons exclure les tables que nous ne voulons pas sauvegarder en utilisant le paramètre ignore-table (avec le formatage "database.table"). Ajoutez les lignes suivantes dans le fichier de configuration MySQL :
[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
ignore-table=sbtest.sbtest9
ignore-table=sbtest.sbtest10
ignore-table=sbtest.sbtest1Une fois configuré, nous pouvons simplement déclencher une nouvelle tâche mysqldump à partir de ClusterControl et ces tables seront ignorées par mysqldump. Aucun redémarrage de MySQL n'est requis.
Vous pouvez consulter la documentation de mysqldump pour plus d'informations.
Percona Xtrabackup
ClusterControl exécute Xtrabackup en fonction des options que vous avez choisies. Il peut être complet ou incrémentiel et vous pouvez choisir plusieurs variables dans l'interface utilisateur de ClusterControl. Considérez ce qui suit :
Dans cette étape, vous pouvez choisir certaines variables que nous avons mentionnées précédemment dans la section mysqldump, puis :
Nous pouvons spécifier certains détails comme le nœud de désynchronisation pendant la sauvegarde, les threads de copie parallèle Xtrabackup, et plus encore.
Sur la base des options ci-dessus, la commande Xtrabackup complète serait :
$ ulimit -n 256000 && LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - | socat - TCP4:192.168.100.110:9999 ) 2>&1.La première commande "ulimit -n 256000" est de s'assurer que Percona Xtrabackup dispose de privilèges suffisants pour accéder à un grand nombre de descripteurs de fichiers (au cas où les bases de données contiennent de nombreuses tables). Prenez note du --defaults-file=/etc/mysql/my.cnf, qui est similaire à mysqldump, où innobackupex lit le contenu de la configuration MySQL sur les directives et variables suivantes :
[mysqld]
datadir=[physical path to MySQL data directory]
tmpdir=[path to temporary directory]
[xtrabackup]
user=backupuser
password=[random password]Si vous souhaitez personnaliser les options de sauvegarde pour Percona Xtrabackup, vous pouvez les ajouter directement sous la directive [xtrabackup]. Par exemple, disons que nous voulons que Xtrabackup imprime la position du journal binaire lorsque la sauvegarde est effectuée, nous pouvons ajouter quelque chose comme ceci :
[xtrabackup]
user=backupuser
password=[random password]
slave-info=1Le déclenchement de la tâche xtrabackup inclura alors un fichier appelé fichier xtrabackup_slave_info. Aucun redémarrage de MySQL n'est requis.
Vous pouvez consulter la documentation Percona pour plus d'informations sur son fonctionnement.
Mariabackup
Mariabackup est un fork de Percona XtraBackup avec une prise en charge supplémentaire de la compression MariaDB 10.1 et du chiffrement des données au repos. Il est inclus avec MariaDB 10.1.23 et versions ultérieures.
La méthode de sauvegarde peut être complète ou incrémentielle et vous pouvez sélectionner les mêmes variables que vous avez pour Percona XtraBackup, comme la compression, Xtrabackup Parallel Copy Threads ou le chiffrement.
La commande Mariabackup serait :
$ /usr/bin/mariabackup \
--defaults-file=/etc/my.cnf \
--backup \
--galera-info \
--parallel 1 \
--stream=xbstream \
--no-timestamp \
| gzip -6 - > /root/backups/BACKUP-8/backup-full-2018-11-07_015807.xbstream.gz ) 2>&1.Mariabackup est basé sur Percona XtraBackup, il utilise donc les mêmes informations que Percona pour effectuer la sauvegarde. Par défaut, ClusterControl ajoute les lignes suivantes dans le fichier my.cnf :
[xtrabackup]
databases-exclude=lost+found
# ssl_mode = DISABLED
ssl = 0Et les identifiants dans le fichier secrets-backup.cnf :
[xtrabackup]
user=backupuser
password=[random password]Si vous souhaitez ajouter une variable, vous pouvez l'ajouter dans la section [xtrabackup].
Vous pouvez consulter la documentation de MariaDB pour plus d'informations sur le paramètre à ajouter.
Dans chaque cas, vous pouvez vérifier vos sauvegardes à partir de la section Sauvegarde sur l'interface utilisateur de ClusterControl :
Nous espérons que cela vous aidera à mieux configurer vos sauvegardes MySQL - vous pouvez télécharger ClusterControl depuis notre site Web (c'est gratuit).
