La dernière version de XtraDB, le moteur de stockage proposé par Percona, dispose d’une fonctionnalité plutôt pertinente avec MySQL : La sauvegarde du cache InnoDB (InnoDB Buffer Pool)
Sauvegarder le cache, oui, mais pour quoi faire ?
Vous devez effectivement comprendre l’intérêt de la chose si vous vous êtes déjà frotté à l’administration d’un MySQL mais je dois vous avouer qu’en abordant le sujet pendant la pose café, tout le monde n’était pas forcement convaincu.
En effet, la mise en œuvre d’une telle fonctionnalité soulève une autre question : Pourquoi redémarrer MySQL ?
Effectivement, le véritable intérêt de cette sauvegarde est de pouvoir couper son MySQL sans perdre les informations stockées dans le cache. Intérêt évidemment compris de tous dans le cas d’un crash du serveur MySQL.
Dans les faits, XtraDB permet de sauvegarder et restaurer le cache même si il n’y a pas eu d’arrêt de l’instance. Ce qui peut d’ailleurs s’avérer utile dans certaines conditions, après le passage d’un gros batch par exemple, afin de retrouver un cache d’activité transactionnelle standard.
Pour en revenir à la question posée par mon collègue, en dehors du contexte de crash, pourquoi redémarrer MySQL ?
Alors que d’autres éditeurs de bases de données concentrent leurs efforts pour justement limiter au maximum le redémarrage des instances, il semble que MySQL soit plus exposé que les autres à ce type de problématique.
Et effectivement, même si la modification dynamique de paramètres gagne du terrain avec les nouvelles versions, la gestion des fichiers physiques reste problématique dans un environnement de production critique.
Il s’agit donc ici de se poser la question à l’envers et c’est donc pour ces différentes raisons que la sauvegarde du cache de données est pertinente avec MySQL !
Comment ça marche ?
Le pré-requis est évidemment d’installer et d’utiliser le moteur de stockage XtraDB fourni par Percona (lien en fin d’article).
Pour comprendre le fonctionnement de cette sauvegarde, j’ai réalisé un petit test en utilisant le compteur Innodb_buffer_pool_pages_data qui indique combien de pages du cache sont utilisées :
1 – Arrêt et relance de l’instance MySQL (Tous les caches sont vidés)
2 – Je contrôle l’état de mon cache :
- mysql> show global status like ‘Innodb_buffer_pool_pages_data’;
+-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | Innodb_buffer_pool_pages_data | 14 | +-------------------------------+-------+
3 – Je fais une requête simple sur ma table ETAT :
- mysql> select * from capdata_innodb.ETAT;
4 -Nouvelle vérification du cache, à ce stade, la table ETAT a bien été montée dans le cache (au moins une partie de ses données) :
- mysql> show global status like ‘Innodb_buffer_pool_pages_data’;
+-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | Innodb_buffer_pool_pages_data | 17 | +-------------------------------+-------+
5 – Je lance une sauvegarde du cache :
- mysql> select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_DUMP*/;
+------------------------------+ | result_message | +------------------------------+ | XTRA_LRU_DUMP was succeeded. | +------------------------------+
6 – Arrêt et relance de l’instance MySQL (Tous les caches sont vidés)
7 – Vérification du cache :
- mysql> show global status like ‘Innodb_buffer_pool_pages_data’;
+-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | Innodb_buffer_pool_pages_data | 14 | +-------------------------------+-------+
8 -Restauration du cache :
- mysql> select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_RESTORE*/;
+---------------------------------+ | result_message | +---------------------------------+ | XTRA_LRU_RESTORE was succeeded. | +---------------------------------+
9 – Dernière vérification du cache :
- mysql> show global status like ‘Innodb_buffer_pool_pages_data’;
+-------------------------------+-------+ | Variable_name | Value | +-------------------------------+-------+ | Innodb_buffer_pool_pages_data | 17 | +-------------------------------+-------+
Le cache a bien été restauré, à vous le warm restart facile !
Percona a réalisé un petit benchmark comparatif dont voici le résultat :
Retrouvez toutes les informations sur le moteur XtraDB ici : https://www.percona.com/docs/wiki/percona-xtradb:start
Continuez votre lecture sur le blog :
- Nouveautés MySQL 8.0 : Configuration automatique de variables avec innodb_dedicated_server (Capdata team) [MySQL]
- MySQL & Performance Schema : mais où sont passés les compteurs Com_% ?? (David Baffaleuf) [MySQL]
- Nouveautés MySQL 8.0 : Les Histogrammes (Capdata team) [MySQL]
- Nouveautés MySQL 8.0 : Variables persistés (Capdata team) [MySQL]
- Réplication MySQL : Resynchronisation d’un Slave MySQL (Capdata team) [MySQL]
L’autre intérêt et non des moindre, est qu’on peut remettre un tel serveur en prod directement, sans avoir à le mettre à faible charge pour qu’il “chauffe”, c’est à dire monte les index en mémoire, puisqu’ils le sont déjà !!!