MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Sauvegardes de bases de données - Comparaison de MariaDB Mariabackup et Percona Xtrabackup

Votre serveur de base de données stocke certaines des informations les plus précieuses de votre entreprise. Garantir des sauvegardes de base de données fiables pour éviter la perte de données en cas d'accident ou de panne matérielle est une case à cocher essentielle.

Qu'il s'agisse d'un serveur très chargé 24h/24 et 7j/7 ou d'un environnement à faible volume de transactions, vous devrez faire des sauvegardes une procédure transparente sans perturber les performances du serveur dans un environnement de production.

Dans ce blog, nous allons passer en revue deux des outils les plus utilisés pour accomplir cette tâche, à savoir Percona XtraBackup et Mariabackup. Nous passerons en revue les similitudes et les différences entre les deux, ainsi que la manière de les utiliser.

Qu'est-ce que Percona XtraBackup ?

Percona XtraBackup est un outil open source permettant d'effectuer des sauvegardes des bases de données MariaDB, MySQL et Percona Server. Il effectue des sauvegardes complètes en ligne non bloquantes (pour les moteurs pris en charge), étroitement compressées et sécurisées sur les systèmes transactionnels afin que les applications restent entièrement disponibles pendant la durée de la fenêtre de sauvegarde.

En utilisant cet outil, vous pouvez :

  • Créez des sauvegardes InnoDB à chaud, qui se terminent rapidement et de manière fiable, sans interrompre votre base de données ni ajouter de charge au serveur
  • Effectuer des sauvegardes incrémentielles
  • Déplacer des tables entre les serveurs MySQL en ligne
  • Créez facilement de nouveaux esclaves de réplication MySQL
  • Diffuser les sauvegardes MySQL compressées sur un autre serveur
  • Économisez de l'espace disque et de la bande passante réseau

Qu'est-ce que Mariabackup ?

Mariabackup est un outil open source fourni par MariaDB pour effectuer des sauvegardes physiques en ligne. Il s'agit d'un fork de Percona XtraBackup conçu pour fonctionner avec des tables cryptées et compressées. Il s'agit de la méthode de sauvegarde recommandée pour les bases de données MariaDB.

MariaDB Server 10.1 a introduit la compression MariaDB et le chiffrement des données au repos, mais les solutions de sauvegarde existantes ne prenaient pas en charge la capacité de sauvegarde complète pour ces fonctionnalités. MariaDB a donc décidé d'étendre XtraBackup (version 2.3.8) et a nommé cette solution Mariabackup.

Différences entre Percona XtraBackup et Mariabackup

Comme nous l'avons noté précédemment, Mariabackup est l'outil de sauvegarde recommandé pour MariaDB, et la principale différence avec XtraBackup est qu'il fonctionne avec des tables chiffrées et compressées.

Quoi qu'il en soit, si pour une raison particulière vous souhaitez utiliser XtraBackup pour votre base de données MariaDB, il y a quelques points à prendre en compte selon la version du serveur MariaDB dont vous disposez :

  • MariaDB 10.1 :avec des données MariaDB non compressées et non chiffrées, vous pouvez utiliser XtraBackup. Si le cryptage ou la compression est utilisé, ou si innodb_page_size est défini sur une valeur autre que 16K, cela ne fonctionnera pas.
  • MariaDB 10.2 :vous pouvez également essayer d'utiliser XtraBackup, mais sachez que les problèmes sont probablement dus au bogue d'incompatibilité du format de journal d'annulation de MySQL 5.7 qui a été corrigé dans MariaDB 10.2.2. En raison de ce bogue, les sauvegardes préparées avec XtraBackup peuvent échouer à récupérer certaines transactions. Seulement si vous exécutez le serveur avec le paramètre innodb_undo_logs=1, cela ne posera pas de problème.
  • MariaDB 10.3 et versions ultérieures :ce cas est plus simple. XtraBackup n'est pas compatible.

De plus, il existe certaines limitations à prendre en compte lors de l'utilisation de Mariabackup :

  • MyRocks :à partir de MariaDB 10.2.16 et MariaDB 10.3.8, Mariabackup sauvegardera les données du moteur de stockage MyRocks. La sauvegarde partielle des données MyRocks n'est actuellement pas prise en charge. La sauvegarde incrémentielle stockera une copie complète des données MyRocks.
  • Fonctionnalité d'exportation de fichier :avant MariaDB 10.2.9, Mariabackup ne prenait pas en charge la fonctionnalité --export (elle crée un fichier d'exportation pour exporter les données de la base de données). Vous pouvez contourner cette limitation en préparant la sauvegarde comme d'habitude (sans l'indicateur --export), puis démarrez le serveur et exécutez FLUSH TABLES FOR EXPORT.
  • Fichiers journaux :les versions de Mariabackup jusqu'à 10.2.8 ne créent pas de fichiers journaux vides et s'appuient sur l'action --copy-back exécutée par l'utilisateur (qui supprime les anciens fichiers journaux innodb, le cas échéant). Si l'utilisateur n'utilise pas --copy-back ou s'assure que le répertoire de données est vide avant la restauration, les sauvegardes créées avec ces versions risquent de devenir incohérentes/corrompues (à cause de la présence de journaux InnoDB restants).
  • Gcrypt :le chiffrement basé sur l'outil de sauvegarde (gcrypt) n'est pas pris en charge sur Mariabackup.
  • Option Innobackupex :aucun lien symbolique vers innobackupex (utilisez le paramètre --innobackupex à la place). L'outil innobackupex corrige et fournit des fonctionnalités supplémentaires par rapport à l'outil innobackup pour sauvegarder les tables InnoDB et MyISAM.
  • Option compacte :l'option --compact n'est pas prise en charge.
  • Option de reconstruction des index :l'option --rebuild_indexes n'est pas prise en charge.
  • Tar pour les fichiers de sauvegarde :la prise en charge de --stream=tar a été supprimée dans Mariabackup 10.1.24 (les options --streams diffusent les fichiers de sauvegarde vers stdout).

Enfin et surtout, Mariabackup peut être installé sur Windows.

Processus de sauvegarde Processus de restauration

Comment - Percona XtraBackup et Mariabackup

Voyons comment nous pouvons l'installer et l'utiliser.

Installation

Vous disposez de différentes méthodes pour installer à la fois XtraBackup et Mariabackup. Essayons l'installation à partir des référentiels.

Installation de XtraBackup

Sur Debian/Ubuntu
$ wget https://repo.percona.com/apt/percona-release_0.1-6.$(lsb_release -sc)_all.deb
$ sudo dpkg -i percona-release_0.1-6.$(lsb_release -sc)_all.deb
$ sudo apt-get update
$ sudo apt-get install percona-xtrabackup-24
Sur RedHat/CentOS
$ sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm
$ sudo yum install percona-xtrabackup-24

Installation de Mariabackup

Sur Debian / Ubuntu

Mariabackup fait partie de MariaDB Server à partir de MariaDB 10.1.23.

$ sudo apt-get install software-properties-common
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu bionic main'
$ sudo apt-get update
$ sudo apt-get install mariadb-server-10.1
Sur CentOS/RedHat
$ sudo vi /etc/yum.repos.d/MariaDB.repo
[mariadb]
name=MariaDB
baseurl=http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
$ sudo yum install MariaDB-backup

Configuration

Xtrabackup et Mariabackup lisent les sections [mysqld] et [xtrabackup] de n'importe quel fichier de configuration MySQL, dans cet ordre. De cette manière, il peut lire les paramètres MySQL, tels que les paramètres datadir ou InnoDB.

Nous pouvons modifier les paramètres inclus dans la section [mysqld] en modifiant leur valeur dans [xtrabackup], comme nous l'avons mentionné précédemment, ils sont lus dans l'ordre, donc la dernière chose que nous avons dans [xtrabackup] aura la priorité.

[mysqld]
datadir=/data/datadir
[xtrabackup]
target_dir=/backups/

L'utilisateur avec les privilèges minimum requis pour les sauvegardes complètes serait RELOAD, LOCK TABLES, PROCESS et REPLICATION CLIENT :

mysql> CREATE USER 'backupuser'@'localhost' IDENTIFIED BY 'Password';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'backupuser'@'localhost';

Et ensuite, vous pouvez ajouter cet utilisateur dans les fichiers de configuration MySQL :

[xtrabackup]
user=backupuser
password=Password

En outre, vous pouvez utiliser Xtrabackup ou Mariabackup pour effectuer les transferts d'instantanés d'état lorsque vous utilisez un cluster Percona XtraDB ou un cluster MariaDB Galera. Vous devez définir les variables wsrep_sst_method et wsrep_sst_auth dans les fichiers de configuration :

[mysqld]
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=backupuser:Password

Ou

[mysqld]
wsrep_sst_method=mariabackup
wsrep_sst_auth=backupuser:Password

Utilisation

Étant donné que Mariabackup est basé sur XtraBackup, il peut être utilisé de la même manière.

Voyons maintenant un exemple utilisant les deux méthodes pour créer, préparer et restaurer une sauvegarde complète.

Création d'une sauvegarde

Pour créer une nouvelle sauvegarde avec XtraBackup ou Mariabackup, vous devez ajouter les options --backup et --target-dir à la ligne de commande :

$ xtrabackup --backup --target-dir=/backups/

Ou

$ mariabackup --backup --target-dir=/backups/

Le répertoire cible, où la sauvegarde sera stockée, peut être spécifié dans les fichiers de configuration MySQL. Le processus de sauvegarde n'écrasera pas les fichiers existants. Si le fichier existe, la sauvegarde échouera.

Transaction log of lsn (9755450) to (9755467) was copied.
181122 23:02:44 completed OK!

Si tout s'est bien passé, la dernière ligne que vous voyez devrait être "completed OK!". Vous pouvez annuler la sauvegarde à tout moment, car elle ne modifie pas le contenu de la base de données.

[[email protected] ~]# ls -l /backups/
total 102448
-rw-r----- 1 root root       488 Nov 22 23:02 backup-my.cnf
-rw-r----- 1 root root       482 Nov 22 23:02 ib_buffer_pool
-rw-r----- 1 root root 104857600 Nov 22 23:02 ibdata1
drwxr-x--- 2 root root      4096 Nov 22 23:02 mysql
drwxr-x--- 2 root root      4096 Nov 22 23:02 performance_schema
drwxr-x--- 2 root root      4096 Nov 22 23:02 sakila
drwxr-x--- 2 root root     12288 Nov 22 23:02 sys
-rw-r----- 1 root root        64 Nov 22 23:02 xtrabackup_binlog_info
-rw-r----- 1 root root       113 Nov 22 23:02 xtrabackup_checkpoints
-rw-r----- 1 root root       533 Nov 22 23:02 xtrabackup_info
-rw-r----- 1 root root      2560 Nov 22 23:02 xtrabackup_logfile

Cela devrait être le contenu de votre sauvegarde. Cela peut changer en fonction de vos bases de données.

Préparer une sauvegarde

Lorsque vous avez créé votre sauvegarde avec XtraBackup ou Mariabackup, vous devez la préparer pour la restauration. Les fichiers de données ne sont pas cohérents tant qu'ils n'ont pas été préparés, car ils ont été copiés à différents moments pendant la durée de la sauvegarde. Si vous essayez de le restaurer et de démarrer votre base de données, il détectera la corruption et se bloquera pour vous empêcher de fonctionner sur des données incohérentes.

Pour préparer la sauvegarde, vous devez exécuter la commande xtrabackup ou mariabackup avec l'option --prepare et spécifier le répertoire cible où est stockée la sauvegarde.

$ xtrabackup --prepare --target-dir=/backups/

Ou

$ mariabackup --prepare --target-dir=/backups/
InnoDB: Shutdown completed; log sequence number 9757224
181122 23:05:29 completed OK!

La dernière ligne que vous voyez doit être "Arrêt terminé ; numéro de séquence de journal xxxxxxx" et "Terminé OK !" si tout s'est bien passé. Il n'est pas recommandé d'annuler le processus de préparation car cela pourrait entraîner une corruption du fichier de données et la sauvegarde deviendrait inutilisable.

Si vous souhaitez utiliser cette sauvegarde avec une sauvegarde incrémentielle ultérieurement, vous devez utiliser l'option --apply-log-only lors de sa préparation, sinon vous ne pourrez pas le faire.

Restauration d'une sauvegarde

Après avoir préparé la sauvegarde, vous pouvez utiliser l'option de restauration avec les paramètres --copy-back ou --move-back, pour copier ou déplacer la sauvegarde vers le répertoire de données. Si vous n'avez pas assez d'espace disque, vous devriez probablement utiliser l'option de déplacement. De plus, nous devons spécifier le répertoire cible où la sauvegarde est stockée. Gardez à l'esprit que le répertoire de données doit être vide et que le service de base de données doit être arrêté avant de restaurer la sauvegarde.

$ xtrabackup --copy-back --target-dir=/backups/

Ou

$ mariabackup --copy-back --target-dir=/backups/

Il copiera/déplacera d'abord les tables et index MyISAM, ensuite les tables et index InnoDB et enfin les fichiers journaux. Il conservera les attributs du fichier lors de leur copie, vous devrez peut-être changer la propriété des fichiers en mysql avant de démarrer le serveur de base de données, car ils appartiendront à l'utilisateur qui a créé la sauvegarde.

$ sudo chown -R mysql:mysql /var/lib/mysql

Il existe plusieurs paramètres à utiliser avec Xtrabackup et Mariabackup. Vous pouvez vérifier ces paramètres ici pour XtraBackup, et ici pour Mariabackup.

ClusterControlConsole unique pour l'ensemble de votre infrastructure de base de donnéesDécouvrez les autres nouveautés de ClusterControlInstallez ClusterControl GRATUITEMENT

Gestion de vos sauvegardes sur ClusterControl

Comme nous l'avons vu ci-dessus, exécuter une sauvegarde n'est pas sorcier. Il peut également être planifié avec cron (mais attention aux échecs silencieux !). Cependant, un script pour créer régulièrement des sauvegardes n'est pas une solution de gestion des sauvegardes. Vous avez besoin d'un moyen de générer des rapports sur vos sauvegardes et d'alerter en cas d'échec. Maintenant, configurer des sauvegardes dans votre environnement et voir les sauvegardes fonctionner sans erreur ne signifie pas que tout va bien. Vous avez peut-être entendu parler de la sauvegarde de Schrödinger, qui stipule que l'état de toute sauvegarde est inconnu jusqu'à ce qu'une restauration soit tentée. Parce que la pire chose qui puisse arriver est un désastre et vous vous rendez compte que les sauvegardes sont erronées pour une raison quelconque. Vous essayez de restaurer les fichiers qui ont été sauvegardés, et cela ne restaure pas ce que vous pensez avoir sauvegardé, ou cela ne restaure pas du tout ! Ensuite, il y a des choses comme déplacer des fichiers de sauvegarde hors site, par ex. vers un stockage cloud externe, pour la reprise après sinistre. Le cryptage et la gestion des clés sont importants pour la sécurité. La conservation des sauvegardes locales ainsi que des sauvegardes externes/archivées doit également être gérée.

Voyons comment ClusterControl peut vous aider.

Si vous souhaitez utiliser la fonctionnalité de sauvegarde de ClusterControl, accédez à ClusterControl -> Sélectionnez Cluster -> Sauvegarde, et là, vous pourrez voir vos sauvegardes actuelles, en créer ou en planifier une nouvelle.

Section de sauvegarde de ClusterControl

En utilisant l'option de création ou de planification, nous pouvons choisir les deux méthodes, XtraBackup ou Mariabackup. Dans la même section, nous pouvons choisir le serveur à partir duquel effectuer la sauvegarde, activer la sauvegarde partielle, choisir où vous souhaitez stocker la sauvegarde et si vous souhaitez télécharger la sauvegarde sur le cloud (AWS, Azure ou Google Cloud).

ClusterControl Créer une sauvegarde 1

Ensuite, nous pouvons sélectionner des paramètres de sauvegarde tels que la compression, le chiffrement et la rétention.

ClusterControl Créer une sauvegarde 2

Et celles-ci devraient être les commandes que ClusterControl exécutera pour vous :

[16:37:58]: 192.168.100.120: Launching ( LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/my.cnf --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - > /root/backups/BACKUP-13/backup-full-2018-11-14_193757.xbstream.gz ) 2>&1.

Ou

[16:29:57]: 192.168.100.131: Launching ( LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - > /root/backups/BACKUP-11/backup-full-2018-11-14_192957.xbstream.gz ) 2>&1.

Cette commande peut être différente selon les paramètres que vous avez choisis.

Comme nous avons pu le voir, ClusterControl est un bon ami si nous voulons utiliser XtraBackup ou Mariabackup. Nous pouvons exécuter des commandes de sauvegarde complexes de manière simple, en sélectionnant les options de l'interface utilisateur de ClusterControl.
ClusterControl prend en charge la sauvegarde complète ou incrémentielle, nous pouvons donc configurer toute notre stratégie de sauvegarde à partir d'une interface utilisateur conviviale.

Conclusion

Lors de la sauvegarde d'un serveur MariaDB, il est recommandé d'utiliser l'outil Mariabackup. Cependant, si pour une raison quelconque vous préférez utiliser XtraBackup, vous pouvez toujours le faire. Mais vous devez garder à l'esprit les restrictions qui s'appliquent, comme nous l'avons noté dans ce blog. Et enfin, nous avons discuté du fait qu'un script pour sauvegarder une base de données n'est pas la même chose qu'une solution de gestion de sauvegarde, et avons jeté un coup d'œil rapide à ClusterControl.

Faites-nous savoir si nous avons manqué des différences entre XtraBackup et MariaBackup.

Les sauvegardes non bloquantes sont prises en charge pour les moteurs de stockage InnoDB, XtraDB et HailDB. Les moteurs de stockage suivants peuvent être sauvegardés en interrompant brièvement les écritures à la fin de la sauvegarde :MyISAM, Merge et Archive, y compris les tables partitionnées, les déclencheurs et les options de base de données.