DBMS/MySQL/XtraBackup

Introduction

Ce document décrit l'utilisation de Xtrabackup, l'outil de sauvegarde distribué par Percona. Xtrabackup est un utilitaire open source de sauvegarde à chaud pour <app>MySQL</app> qui ne verrouille pas les bases de données pendant la sauvegarde.

• Il permet de sauvegarder des données de tables innoDB, XtraDB et MyISAM sur des serveurs MySQL 5.0, 5.1, 5.5 et 5.6 mais également sur Percona Server avec XtraDB.
• <class>Percona Xtrabackup</class> est la combinaison du programme C <app>xtrabackup</app> et du script Perl <app>innobackupex</app>.
• Percona assure que cet outil est plus performant et propose plus de fonctionnalités que MySQL Enterprise Backup (logiciel propriétaire).

Installation

• On installe le dépôt RPM Percona

  rpm -Uvh http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm

• On installe <app>xtrabackup</app> depuis le dépôt de Percona

  yum install xtrabackup

Le dépôt percona contient d'autres paquets intéressant mais hors sujet ici:

yum list | grep percona
percona-release.noarch                                  0.1-3                      @percona 
Percona-Server-55-debuginfo.x86_64                      5.5.40-rel36.1.el7         percona-release-x86_64
Percona-Server-56-debuginfo.x86_64                      5.6.21-rel69.0.el7         percona-release-x86_64
Percona-Server-client-55.x86_64                         5.5.40-rel36.1.el7         percona-release-x86_64
Percona-Server-client-56.x86_64                         5.6.21-rel69.0.el7         @percona-release-x86_64
Percona-Server-devel-55.x86_64                          5.5.40-rel36.1.el7         percona-release-x86_64
Percona-Server-devel-56.x86_64                          5.6.21-rel69.0.el7         percona-release-x86_64
Percona-Server-server-55.x86_64                         5.5.40-rel36.1.el7         percona-release-x86_64
Percona-Server-server-56.x86_64                         5.6.21-rel69.0.el7         @percona-release-x86_64
Percona-Server-shared-55.x86_64                         5.5.40-rel36.1.el7         percona-release-x86_64
Percona-Server-shared-56.x86_64                         5.6.21-rel69.0.el7         @percona-release-x86_64
Percona-Server-test-55.x86_64                           5.5.40-rel36.1.el7         percona-release-x86_64
Percona-Server-test-56.x86_64                           5.6.21-rel69.0.el7         percona-release-x86_64
Percona-Server-tokudb-56.x86_64                         5.6.21-rel69.0.el7         percona-release-x86_64
percona-toolkit.noarch                                  2.2.11-1                   @percona-release-noarch
percona-xtrabackup-debuginfo.x86_64                     2.2.5-5027.el7             percona-release-x86_64
percona-xtrabackup-test.x86_64                          2.2.5-5027.el7             @percona-release-x86_64
percona-xtrabackup.x86_64                               2.2.5-5027.el7             @percona-release-x86_64
Percona-XtraDB-Cluster-55-debuginfo.x86_64              1:5.5.39-25.11.824.el7     percona-release-x86_64
Percona-XtraDB-Cluster-55.x86_64                        1:5.5.39-25.11.824.el7     percona-release-x86_64
Percona-XtraDB-Cluster-56-debuginfo.x86_64              1:5.6.20-25.7.888.el7      percona-release-x86_64
Percona-XtraDB-Cluster-56.x86_64                        1:5.6.20-25.7.888.el7      percona-release-x86_64
Percona-XtraDB-Cluster-client-55.x86_64                 1:5.5.39-25.11.824.el7     percona-release-x86_64
Percona-XtraDB-Cluster-client-56.x86_64                 1:5.6.20-25.7.888.el7      percona-release-x86_64
Percona-XtraDB-Cluster-devel-55.x86_64                  1:5.5.39-25.11.824.el7     percona-release-x86_64
Percona-XtraDB-Cluster-devel-56.x86_64                  1:5.6.20-25.7.888.el7      percona-release-x86_64
Percona-XtraDB-Cluster-full-55.x86_64                   1:5.5.39-25.11.824.el7     percona-release-x86_64
Percona-XtraDB-Cluster-full-56.x86_64                   1:5.6.20-25.7.888.el7      percona-release-x86_64
Percona-XtraDB-Cluster-galera-2.x86_64                  2.11-1.2675.rhel7          percona-release-x86_64
Percona-XtraDB-Cluster-galera-2-debuginfo.x86_64        2.11-1.2675.rhel7          percona-release-x86_64     
Percona-XtraDB-Cluster-galera-3.x86_64                  3.7-1.3254.rhel7           percona-release-x86_64
Percona-XtraDB-Cluster-galera-3-debuginfo.x86_64        3.7-1.3254.rhel7           percona-release-x86_64
Percona-XtraDB-Cluster-garbd-2.x86_64                   2.11-1.2675.rhel7          percona-release-x86_64
Percona-XtraDB-Cluster-garbd-3.x86_64                   3.7-1.3254.rhel7           percona-release-x86_64
Percona-XtraDB-Cluster-server-55.x86_64                 1:5.5.39-25.11.824.el7     percona-release-x86_64
Percona-XtraDB-Cluster-server-56.x86_64                 1:5.6.20-25.7.888.el7      percona-release-x86_64
Percona-XtraDB-Cluster-shared-55.x86_64                 1:5.5.39-25.11.824.el7     percona-release-x86_64
Percona-XtraDB-Cluster-shared-56.x86_64                 1:5.6.20-25.7.888.el7      percona-release-x86_64
Percona-XtraDB-Cluster-test-55.x86_64                   1:5.5.39-25.11.824.el7     percona-release-x86_64
Percona-XtraDB-Cluster-test-56.x86_64                   1:5.6.20-25.7.888.el7      percona-release-x86_64
qpress-debuginfo.x86_64                                 11-1.el7                   percona-release-x86_64
qpress.x86_64                                           11-1.el7                   percona-release-x86_64
sysbench-debuginfo.x86_64                               0.5-4.el7                  percona-release-x86_64
sysbench.x86_64                                         0.5-4.el7                  percona-release-x86_64

Utilisation basique

Backup

• Backup full

  innobackupex --user=<USER> --password=<PASSWD> --databases=<BASE> <FULL BACKUP PATH>

• Backup incrémental

  innobackupex --incremental <INCREMENTAL BACKUP PATH> --incremental-basedir=<FULL BACKUP PATH> --user=<USER> --password=<PASSWD>

Restauration

• Depuis un backup Full
  1. On prépare le backup à être importer

     innobackupex --apply-log <FULL BACKUP PATH>

  2. On déplace/renomme les fichiers existants (ceux qui seront écraser par notre backup)

     mv /var/lib/mysql/dossier_de_la_base{,.old}

  3. On applique le backup (on remplace les fichiers)

     innobackupex --ibbackup=xtrabackup --copy-back <FULL BACKUP PATH>

• Depuis un backup incrémental
  1. On importe au backup les transactions déjà validée

     innobackupex --apply-log --redo-only <FULL BACKUP PATH> [--use-memory=1G] --user=<USER> --password=<PASSWD>

  2. On applique la sauvegarde incrémental au backup

     innobackupex --apply-log <FULL BACKUP PATH> --incremental-dir=<INCREMENTAL BACKUP PATH> [--use-memory=1G] --user=<USER> --password=<PASSWD>

  3. On prépare le backup à être importer

     innobackupex --apply-log <FULL BACKUP PATH> [--use-memory=1G] --user=<USER> --password=<PASSWD>

  4. On déplace/renomme les fichiers existants (ceux qui seront écraser par notre backup)

     mv /var/lib/mysql/dossier_de_la_base{,.old}

  5. On applique le backup (on remplace les fichiers)

     innobackupex --ibbackup=xtrabackup --copy-back <FULL BACKUP PATH>

Utilisation avancée

Backup STREAM

Le mode streaming, supporté par xtrabackup, envoi le backup sur la sortie standard dans un format tar spécial au lieu de copier les fichiers dans le répertoire de backup.

Cela permet de piper le stream vers d'autres programmes. Par exemple, la compression est obtenue en pipant le sortie vers un utilitaire de compression.

Pour utiliser cette fonctionnalité, vous devez utiliser l'option '--stream', en fournissant ainsi le format du stream (seul tar est supporté actuellement) et indiquer où seront stocker les fichiers temporaires:

# innobackupex --stream=tar /tmp

innobackupex démarre xtrabackup en mode '--log-stream' dans un process enfant, et redirige son log vers un fichier temporaire. Il utilise ensuite tar4ibd pour streamer tous les fichiers de données vers STDOUT,

dans un format tar spécial. Après avoir terminé le streaming de tous les fichiers de données vers STDOUT, il stoppe xtrabackup et streame aussi le fichier de log sauvé.

Pour stocker le backup dans une archive directement:

# innobackupex --stream=tar /root/backup/ > /root/backup/out.tar

Pour l'envoyer directement vers un autre hôte:

# innobackupex --stream=tar ./ | ssh user@destination \ "cat - > /data/backups/backup.tar"

Pour extraire l'archive xtrabackup, vous devez utiliser tar avec l'option '-i'
Sinon les blocs de données à zéro de l'archive seront interprétés comme EOF (End Of File), et le set de restauration ne sera pas complet.

# tar -xizf backup.tar.gz

Choisir l'outil de compression qui vous convient le mieux:

# innobackupex --stream=tar ./ | gzip - > backup.tar.gz
# innobackupex --stream=tar ./ | bzip2 - > backup.tar.bz2

Notez que les backups streaming devront être préparés avant la restauration. Le mode streaming ne prépare pas le backup.

Mise en pratique

Backup

# mkdir /home/backup && /home/backup
# innobackupex --stream=tar /tmp | gzip - > backup.tar.gz
# ll
-rw-r--r-- 1 root root 248660 14 déc.  16:53 backup.tar.gz
-rw-r--r-- 1 root root      0 14 déc.  16:52 stderr
-rw-r--r-- 1 root root    348 14 déc.  16:52 stdout

Restore

# tar -xizf backup.tar.gz
# ll
-rw-r--r-- 1 root  root       260 14 déc.  16:52 backup-my.cnf
-rw-r--r-- 1 root  root    248660 14 déc.  16:53 backup.tar.gz
-rw-r--r-- 1 mysql mysql 52428800 14 déc.  11:31 ibdata1
drwxr-xr-x 2 root  root      4096 14 déc.  17:03 mysql
drwxr-xr-x 2 root  root      4096 14 déc.  17:03 performance_schema
drwxr-xr-x 2 root  root      4096 14 déc.  17:03 poliakov
drwxr-xr-x 2 root  root      4096 14 déc.  17:03 poliakov.old
-rw-r--r-- 1 root  root         0 14 déc.  16:52 stderr
-rw-r--r-- 1 root  root       348 14 déc.  16:52 stdout
-rw-r--r-- 1 root  root         1 14 déc.  16:53 xtrabackup_binlog_info
-rw-r--r-- 1 root  root        77 14 déc.  16:53 xtrabackup_checkpoints
-rw-r--r-- 1 root  root      2048 14 déc.  16:52 xtrabackup_logfile

2 eme test

# innobackupex --stream=tar /tmp | ssh root@graylog2 \ "cat - > /root/backup.tar" 

Le deuxième test ne fonctionne pas, obligé de couper avec ctrl+c, erreur sur STDOUT:

>> log scanned up to (1606144)
>> log scanned up to (1606144)
>> log scanned up to (1606144)
>> log scanned up to (1606144)
>> log scanned up to (1606144)

111214 17:18:31  innobackupex: Starting mysql with options:  --unbuffered --
111214 17:18:31  innobackupex: Connected to database with mysql child process (pid=12282)
111214 17:18:35  innobackupex: Starting to lock all tables...
tar: - : la fonction write a échoué: Relais brisé (pipe)
tar: Error is not recoverable: exiting now
innobackupex: Error: Failed to stream 'xtrabackup_binlog_info': Ioctl() inappropré pour un périphérique at /usr/bin/innobackupex line 336.

Prendre des sauvegardes dans un environnement de réplication

Il y a des options spécifiques pour sauvegarder les serveurs dans un environnement de réplication.

• L'option --slave-info
  Cette option est utile lors de la sauvegarde d'un serveur esclave de réplication. Elle imprime la position du binary log et le nom du serveur maître. Elle écrit également ces informations dans le fichier xtrabackup_slave_info comme un état CHANGE MASTER.
  Ceci est utile pour la mise en place d'un nouvel esclave pour ce maitre, il peut être installé en démarrant le serveur esclave sur cette sauvegarde et émettre l'état sauvé dans le fichier <path>xtrabackup_slave_info</path>
• L'option --safe-slave-backup
  Afin d'assurer un état de réplication cohérent, cette option arrête le thread esclave et attend le démarrage de la sauvegarde jusqu'à ce que le paramètre Slave_open_temp_tables dans SHOW STATUS soit à zéro.
  S'il n'y a pas de tables temporaire ouvertes, la sauvegarde aura lieu, sinon le thread SQL va être lancé et arrêté jusqu'à ce qu'il n'y ai plus de tables temporaire ouvertes.
  La sauvegarde va échouer si le paramètre Slave_open_temp_tables ne devient pas zéro après --safe-slave-backup-timeout secondes (par défaut à 300 secondes). Le thread esclave va être redémarré lorsque la sauvegarde sera terminée.

L'utilisation de l'option --safe-slave-backup est toujours recommandée lors de la prise de sauvegardes à partir d'un serveur esclave.

Accelerating with --parallel copy

Lorsque vous effectuez une sauvegarde locale, plusieurs fichiers peuvent être copiés simultanément en utilisant l'option --parallel. Cette option spécifie le nombre de threads créés par xtrabackup pour copier des fichiers de données.

Pour profiter de cette option, l'option d'espace de tables multiples doit être activée (innodb_file_per_table) ou l'espace de tables partagées doit être stocké dans des fichiers ibdata multiples avec l'option: innodb_data_file_path.

Le fait d'avoir plusieurs fichiers pour la base de données (ou fractionner un fichier en plusieurs fichiers) n'a pas d'impact mesurable sur la performance.

Comme cette fonctionnalité est implémentée au niveau du fichier, le transfert de fichiers simultanés peut parfois augmenter le débit d'E / S lorsque vous faites une sauvegarde sur des fichiers de données très fragmenté, en raison du chevauchement d'un plus grand nombre de requêtes de lecture aléatoire.

Vous devriez envisager le tuning du système de fichiers également pour obtenir les performances maximales (controler la fragmentation par exemple).

Si les données sont stockées dans un fichier unique (ibdata), cette option n'aura aucun effet.

Pour utiliser cette fonctionnalité, il suffit d'ajouter l'option pour une sauvegarde locale, par exemple:

$ innobackupex --parallel /path/to/backup

Mise en pratique :

Arrêt de MySQL, ajout du paramètre innodb_file_per_table au fichier <path>/etc/my.cnf</path> et redémarrage du SGDB.

 mysql> SHOW VARIABLES LIKE '%file%';
 | innodb_file_per_table                 | ON                                           |

 mysql> CREATE DATABASE foodmart;
 Query OK, 1 row affected (0.00 sec)

 mysql> CREATE DATABASE BASE_BDF;
 Query OK, 1 row affected (0.00 sec)

 mysql> quit
 Bye

# cd /root/dump/
# mysql foodmart < foodmart-2.sql
# mysql BASE_BDF < BASE_BDF.sql
# time innobackupex /tmp/backup
...
innobackupex: Backup created in directory '/tmp/backup/2012-01-05_16-14-36'
innobackupex: MySQL binlog position: filename , position
120105 16:16:59  innobackupex: completed OK!

real    2m30.098s
user    0m4.221s
sys     0m3.241s

# time innobackupex --parallel 4 /tmp/backup
...
innobackupex: Backup created in directory '/tmp/backup/2012-01-05_16-18-24'
innobackupex: MySQL binlog position: filename , position
120105 16:21:09  innobackupex: completed OK!

real    2m51.227s
user    0m4.416s
sys     0m3.146s

# time innobackupex --parallel 8 /tmp/backup
...
innobackupex: Backup created in directory '/tmp/backup/2012-01-05_16-27-23'
innobackupex: MySQL binlog position: filename , position
120105 16:30:06  innobackupex: completed OK!

real    2m49.217s
user    0m4.368s
sys     0m3.306s

On ne constate pas réellement d'amélioration entre la méthode avec l'option parallel et la méthode sans dans notre exemple.

Sauvegardes par étranglement avec innobackupex (--throttle)

Bien que innobackupex ne bloque pas le fonctionnement de votre base de données, une sauvegarde peut ajouter une charge pour le système en cours de sauvegarde.

Sur les systèmes qui n'ont pas beaucoup de capacité au niveau des E/S, il pourrait être utile d'étrangler la vitesse à laquelle innobackupex lit et écrit InnoDB données. Vous pouvez faire cela avec l'option --throttle.

Cette option est passée directement au binaire xtrabackup et limite seulement les opérations sur les fichiers journaux et les fichiers des tables InnoDB.

Il n'y a pas d'altération sur la lecture ou l'écriture des fichiers dans les tables avec un autre moteur de stockage.

Une façon de vérifier les opérations courantes d'I/O sur un système est la commande iostat. Voir Throttling Backups pour les détails sur la méthode de fonctionnement de l'étranglement.

L'options --throttle est en quelque sorte similaire à l'option --sleep dans mysqlbackup et devrait être utilisé à la place de celle-ci, l'option --sleep peut alors être ignorée.

Envoi sauvegardes sur des hôtes distants avec innobackupex

Outre l'utilisation du --stream pour l'envoi de la sauvegarde sur un autre hôte via le piping (voir streaming et compression des sauvegardes ), innobackupex peut le faire directement avec le --remote-host

$ Innobackupex --remote-host=REMOTEUSER@REMOTEHOST /path/IN/REMOTE/HOST/to/backup/

innobackupex va tester la connexion à REMOTEHOST via ssh et créer les répertoires de sauvegarde nécessaires en tant que remoteuser spécifié.

Le chemin que vous fournissez pour stocker la sauvegarde sera créée sur le REMOTEHOST , pas sur l'hôte local.

Ensuite, tous les fichiers de log seront écrit dans un fichier temporaire (vous pouvez choisir où stocker ce fichier avec l'option --tmpdir) et sera copié par scp.

Les options pour scp peuvent être spécifiées avec --options-scp ( -Cp -c arcfour par défaut), par exemple:

$ innobackupex --remote-host=REMOTEUSER@REMOTEHOST /path/IN/REMOTE/HOST/to/backup/ \
--tmpdir=/tmp --options-scp="-Cp -c arcfour" 

Import et Export de tables individuelles

Par défaut avec l'InnoDB standard, il n'est pas possible de copier des tables entre les serveurs en copiant les fichiers, même avec innodb_file_per_table activé.

Mais xtrabackup permet de migrer des tables individuelles depuis n'importe quelle base InnoDB vers Percona Server avec XtraDB.

La table est requise pour être créée avec l'option innodb_file_per_table activée sur le serveur, étant donné que l'export est possible seulement quand la table est enregistrée dans son propre espace de table.

Le serveur d'import (pour le moment seulement supporté par Percona Server) doit avoir les options innodb_file_per_table et innodb_expand_import activées.

Export de tables:

L'export est effectué au niveau préparation, pas au moment de la création du backup. Une fois que le backup complet est crée, elle le prépare avec l'option --export:

$ innobackupex --apply-log --export /path/to/backup

Ca va créer un fichier, ayant pour extension .exp, pour chaque table InnoDB avec son propre espace de table. La sortie de cette procédure contiendra:

xtrabackup: export option is specified.
xtrabackup: export metadata of table 'mydatabase/mytable' to file
`./mydatabase/mytable.exp` (1 indexes)

Chaque fichier .exp sera utilisé pour importer cette table.

Import de tables:

Pour importer une table sur un autre serveur, créez d'abord une nouvelle table avec la même structure que celle qui sera importée sur le serveur:

mysql> CREATE TABLE mytable (...) ENGINE=InnoDB;

Ensuite, écarter son espace de table

mysql> ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Après ça, copier les fichiers mytble.ibd et mytable.exp vers le dossier de la base de données, et importer son espace de table

mysql> ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Une fois que ceci a été exécuté, les données dans la table importée sont disponibles.

Récupération Point-in-time

La récupération à un moment particulier dans l'historique de la base de données peut être effectué avec innobackupex et les logs binaires du serveur.

Notez que le log binaire contient les opérations qui ont modifié la base de données à partir d'un point dans le passé: il agit comme un "redo log".

Vous avez besoin d'un instantané du passé à partir duquel vous allez "refaire (redo)" les opérations jusqu'au Point-In-Time (point dans le temps) que vous voulez.

Pour prendre un instantané, nous allons utiliser innobackupex pour un backup complet:

$ innobackupex /path/to/backup --no-timestamp

(l'option --no-timestamp est pour plus de commodité dans cet exemple) et nous allons le préparer pour être prêt pour la restauration:

$ innobackupex --apply-log /path/to/backup

Pour plus de détails sur ces procédures, voir 'Créer un backup avec innobackupex' et 'Préparer un backup complet avec innobackupex'.

Maintenant, supposons que le temps est passé, et que vous voulez restaurer la base de données à certain point dans le passé, gardez à l'esprit qu'il ya la contrainte du point où l'instantané a été pris.

Pour savoir quelle est la situation des logs binaires dans le serveur, exécuter les requêtes suivantes:

mysql> SHOW BINARY LOGS;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |       126 |
| mysql-bin.000002 |      1306 |
| mysql-bin.000003 |       126 |
| mysql-bin.000004 |       497 |
+------------------+-----------+

Et

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000004 |      497 |              |                  |
+------------------+----------+--------------+------------------+

La première requête vous dira quels fichiers contiennent les logs binaires et la seconde quel fichier est utilisé et quelle est sa position actuelle. Ces fichiers sont stockés habituellement dans le datadir

(sauf si un autre emplacement est spécifié quand le serveur est lancé avec l' option --log-bin=).

Pour connaître la position à laquelle l'instantané a été pris, voir le xtrabackup_binlog_info dans le répertoire de backup:

$ cat /path/to/backup/xtrabackup_binlog_info
mysql-bin.000003      57

Cela vous indiquera quel fichier a été utilisé au moment de la sauvegarde pour le log binaire et sa position. Cette position sera celle en vigueur lorsque vous restaurez la sauvegarde:

$ innobackupex --copy-back /path/to/backup

Comme la restauration n'affectera les fichiers de binary log (vous pouvez avoir besoin de régler les permissions des fichiers, voir Restauration d'une sauvegarde complète avec innobackupex ), la prochaine étape est d'extraire les requêtes du log binaire avec mysqlbinlog à partir de la position de l'instantané et de les réorienter dans un fichier.

$ mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 > mybinlog.sql

Notez que si vous avez plusieurs fichiers pour le binary log, comme dans cet exemple, vous avez à traiter chacun d'eux avec un processus, comme indiqué ci-dessus.

Examinez le fichier avec les requêtes pour déterminer quelle position ou jour correspond au point dans le temps voulu. Une fois déterminé, pipez le sur le serveur. En supposant que le point est 11-12-25 01:00:00:

$ mysqlbinlog /path/to/datadir/mysql-bin.000003 /path/to/datadir/mysql-bin.000004 \
--start-position=57 --stop-datetime="11-12-25 01:00:00" | mysql -u root -p

et la base de données sera déployée en amont jusqu'à ce 'Point-In-Time'.

Comment innobackupex fonctionne

innobackupex est un script écrit en Perl qui encapsule les binaires xtrabackup et tar4ibd et exécute les tâches là où la performance et l'efficacité d'un programme C n'est pas nécessaire.

De cette façon, il offre une approche pratique et intégrée de la sauvegarde dans de nombreux scénarios courants.

La section suivante décrit le raisonnement des actions d'innobackupex.

Réaliser une sauvegarde:

Si aucun mode n'est spécifié, innobackupex assumera le mode de sauvegarde.

Par défaut, il lance xtrabackup avec l'option --suspend-at-end, et permet de copier les fichiers de données InnoDB.

Lorsque xtrabackup termine ceci, innobackupex voit qu'il a créé le fichier xtrabackup_suspended et exécute FLUSH TABLES WITH READ LOCK. Puis il commence à copier le reste des fichiers.

Si --ibbackup n'est pas indiquée, innobackupex va essayer de le détecter: si le fichier xtrabackup_binary existe dans le répertoire de backup, il va y lire quel binaire d'xtrabackup sera utilisé.

Sinon, il va tenter de se connecter au serveur de base de données dans le but de le déterminer. Si la connexion ne peut être établie, xtrabackup échoue et vous devez le spécifier (voir Choosing the Right Binary).

Lorsque le binaire est déterminé, la connexion au serveur de base de données est testée. Ceci est effectué en se connectant, en émettant une requête et en fermant la connexion. Si tout va bien, le binaire est lancé comme un processus enfant.

Si ce n'est pas une sauvegarde incrémentale, il se connecte au serveur. Il attend les esclaves dans une configuration de réplication si l'option --safe-slave-backup est définie et flushera toutes les tables avec READ LOCK , empêchant toutes les tables MyISAM d'écrire (à moins que l'option --no-lock soit spécifiée).

Une fois cela fait, la sauvegarde des fichiers va commencer. Il va sauvegarder les fichiers .frm , .MRG , .MYD , .MYI , .TRG , .TRN , .ARM , .ARZ , .CSM , .CSV et .opt.

Lorsque tous les fichiers sont sauvegardés, il reprend ibbackup et attend jusqu'à ce qu'il termine la copie des transactions effectuées pendant que la sauvegarde a été faite.

Ensuite, les tables sont débloquées, l'esclave est lancé (si l'option --safe-slave-backup a été utilisé) et la connexion avec le serveur est fermé.

Enfin, il supprime le fichier xtrabackup_suspended et permet à xtrabackup de quitter.

Il créera également les fichiers suivants dans le répertoire de la sauvegarde:

xtrabackup_checkpoints

contenant la LSN et le type de sauvegarde;

xtrabackup_binlog_info

contenant la position du log binaire au moment de la sauvegarde;

xtrabackup_binlog_pos_innodb

contenant la position du log binaire au moment de la sauvegarde par rapport aux transactions InnoDB;

xtrabackup_slave_info

contenant la position MySQL binlog du serveur maître dans une configuration de réplication via 'SHOW SLAVE STATUS \ G;' si l'option --slave-info est passée;

backup-my.cnf

ne contenant que les options my.cnf requises pour la sauvegarde;

xtrabackup_binary

contenant le binaire utilisé pour la sauvegarde;

mysql-stderr

contenant le STDERR de mysqld pendant le processus et

mysql-stdout

contenant le STDOUT du serveur.

Si --remote-host a été défini, innobackupex va tester la connexion à l'hôte via ssh et créer les répertoires de sauvegarde. Puis le même processus sera appliqué, mais le log sera écrit dans un fichier temporaire et sera copié via scp avec les options définies par --options-scp (-Cp -c arcfour par défaut).

Après chaque copie les fichiers seront supprimés. Le même raisonnement est utilisé pour le mode --stream.

Enfin, la position de log binaire sera imprimé sur STDERR et innobackupex va quitter en retournant 0 si tous s'est bien passé.

Notez que le STDERR d'innobackupex n'est pas écrit dans aucun fichier. Vous devez le rediriger dans un fichier, par exemple: innobackupex OPTIONS 2> backupout.log

Restaurer une sauvegarde:

Pour restaurer un backup avec innobackupex l'option --copy-back doit être utilisée.

innobackupex va lire le lire dans le my.cnf les variables datadir , innodb_data_home_dir , innodb_data_file_path , innodb_log_group_home_dir et vérifier que les répertoires existent.

Il va copier les tables MyISAM, les index, etc (les fichiers .frm , .MRG , .MYD , .MYI , .TRG , .TRN , .ARM , .ARZ , .CSM , .CSV et .opt) d'abord, les tables InnoDB et les index ensuite et les fichiers journaux à la fin.

Il permettra de préserver les attributs de fichier quand il va les copier, vous pouvez avoir à modifier la propriété des fichiers pour mysql avant de démarrer le serveur de base, car ils seront la propiété de l'utilisateur qui a créé la sauvegarde.

Références

• Toutes les options d'<app>innobackupex</app>