evolix/wiki
22
0
Fork 0
Code Releases Activity

Fonctionnement de MariaBackup

Browse source
This commit is contained in:
emorino 2019-06-05 11:39:16 +02:00
parent 7fb8750337
commit f7377dc54f
1 changed files with 49 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

49
HowtoMySQL/mariabackup.md
View file

@ -315,3 +315,52 @@ CHANGE MASTER TO
MASTER_LOG_POS=327;
START SLAVE;
~~~
## Fonctionnement de MariaBackup
Voici les différentes étapes du fonctionnement de MariaBackup lors d'un backup complet.
### Phase d'initialisation
* Connexion à l'instance mysqld, récupération des variables importantes comme datadir ,InnoDB pagesize, encryption keys, encryption plugin etc...
* Scan du répertoire de la base de donnée, du datadir, recherche des tablespaces InnoDB et chargement des tablespaces.
* Si _--lock-ddl-per-table_ est utilisé : Des verrous MDL (Metadata Locking) sont fait pour les tablespaces InnoDB. Cela permet de s’assurer qu’il n’ya pas de table ALTER, RENAME, TRUNCATE ou DROP sur les tables que nous voulons copier.
* Si _--lock-ddl-per-table_ n'est pas utilisé : Mariabackup devra connaître toutes les tables créées ou modifiées au cours de la sauvegarde. Pour plus d'information voir https://jira.mariadb.org/browse/MDEV-16791
### Manipulation des Redo Log.
Un thread dédié à mariabackup est démarré pour copier le journal de restauration InnoDB (ib_logfile *).
* Cela est nécessaire pour enregistrer toutes les modifications effectuées pendant l'exécution de la sauvegarde.
* Le journal est également utilisé pour détecter si des TRUNCATE ou ONLINE ALTER TABLE sont effectués.
* On présume que le processus de copie est capable de rattraper les informations du serveur, pendant la copie, si le Redo Log est assez gros.
### Phase de copie des Tablespaces InnoDB
* Copie des Tablespaces InnoDB sélectionné, fichier par fichier, dans les threads dédiés de Mariabackup, sans impliquer le serveur mysqld.
* Il s'agit d'une copie "sécurisé", elle vérifié la cohérence des données avec la somme de contrôle.
* Les fichiers ne sont pas cohérent dans un point dans le temps (point-in-time consistent), car les données peuvent être modifié pendant la copie.
* L'idée est que la récupération d'InnoDB, notament avec les redo log, le rendrait cohérent a un moment précis dans le temps.
### Création d'un point de sauvegarde cohérent
* Exécution de FLUSH TABLE WITH READ LOCK. Ceci est effectué par défaut, si l'option --no-lock n'est pas passé.
La raison pour laquelle FLUSH est nécessaire est de s'assurer que toutes les tables sont dans un état cohérent
exactement au même moment, indépendamment du moteur de stockage.
* Si _--lock-ddl-per-table_ est utilisé et qu'une requête utilisateur est en attente de MDL (Metadata Locking) la requête utilisateur sera supprimée pour résoudre un blocage. Notez que ce ne sont que des requêtes de type ALTER, DROP, TRUNCATE ou RENAME TABLE qui empêche le backup de se faire correctement.
### Dernière phase de copie
* Copie des fichiers .frm, MyISAM, Aria et d'autres moteurs de stockage.
* Copie des tables crées pendant la sauvegarde et renommage des fichiers modifiés pendant la sauvegarde
* Copie du reste du journal de restauration InnoDB, arrêt du thread de copie des Redo Log.
* Ecriture des métadonnées (position du binlog, par exemple)
### Déverrouillage
* Si FLUSH TABLE WITH READ LOCK est terminé, exécution de UNLOCK TABLES
* Si _--lock-ddl-per-table_ est terminé, exécution de COMMIT
Si FLUSH TABLE WITH READ LOCK n'est pas utilisé, seules les tables InnoDB sont cohérentes (pas les tables dans la base de donnée mysql, ni les binlogs)
Le point de sauvegarde dépends du contenu des Redo logs dans le backup lui-même.