# Utiliser les outils Percona pour les grandes bases GLPI ## Qui est Percona ? [Percona](https://www.percona.com) est un fournisseur leader de solutions de base de données open source impartiales, ils offrent une large gamme de produits (complète de la solution de serveur/clustering de base de données aux outils de monitoring ou d'administration). ## Quel outil utiliser et pourquoi ? Pour les changements (modification de colonnes ou migration de données) **dans les grandes bases de données GLPI**, basées sur MySQL / MariaDB, vous pouvez utiliser l'outil **"pt-online-schema-change"**, qui est inclus dans le **"percona-toolkit"** développé par Percona, par exemple : * Convertir toutes les données du moteur **MyISAM** vers le moteur **InnoDB** * Migrer toutes les colonnes **DATETIME** vers le format **TIMESTAMP** (pour le support des fuseaux horaires) * Ajouter / supprimer / récupérer un Index sur la table **glpi\_logs** En disant "grande base de données", nous entendons celles dont la table **glpi\_logs** dépasse 5GB de données, mais bien sûr il est possible d'utiliser ces outils sur toutes les bases de données (peu importe leur taille). **pt-online-schema-change** est plus efficace et plus sécurisé que les outils en ligne de commande (**bin/console**) fournis dans la version core de GLPI (utile pour les bases de données moins importantes). ## Documentation officielle * Installation de **percona-toolkit** : * * OU * Utilisation de **pt-online-schema-change** : * ## Risques Comme indiqué dans la documentation officielle : Percona Toolkit est mature, éprouvé dans le monde réel, et bien testé, mais tous les outils de base de données peuvent poser un risque au système et au serveur de base de données (comme tous les autres outils sysadmin/DBA). {% hint style="danger" %} **Danger** **Avant d'utiliser cet outil, veuillez :** * Lire la documentation de l'outil * Examiner les "BUGS" connus de l'outil * Tester l'outil sur un serveur non-production * Sauvegarder votre serveur de production et vérifier les sauvegardes {% endhint %} **TECLIB ne peut être tenu responsable d'une utilisation incorrecte conduisant à une perte de données.** ## Avertissement sur l'utilisation du disque Le principe principal de **pt-online-schema-change** est de créer une table temporaire qui correspond à l'ALTER que vous voulez faire, puis copier les données de l'ancienne table vers la nouvelle, et supprimer l'ancienne table si tout va bien. Par conséquent, faites attention à l'utilisation de l'espace disque : il doublera temporairement (ou triplera), puis reviendra à la normale (ou diminuera en cas d'"OPTIMIZE"). {% hint style="success" %} **Taille du disque** Si votre table **glpi\_logs** (avant intervention) fait 25GB, nous recommandons d'avoir un espace disque **libre** d'au moins 50/75GB pour effectuer l'opération. {% endhint %} ## Avertissement sur le temps d'exécution Bien que grâce à cet outil, les migrations de données soient beaucoup plus rapides (qu'avec l'outil bin/console de GLPI), nous conseillons toujours (comme tout bon administrateur système Linux qui se respecte) d'exécuter toutes vos commandes dans un terminal virtuel ou multiplexeur de terminal (comme : tmux ou screen). Si pour une raison quelconque vous perdez la connexion/session SSH, étant dans un terminal virtuel l'exécution de votre commande continuera sans vous ! :sunglasses: {% hint style="success" %} **Exemple avec** [**tmux**](https://fr.wikipedia.org/wiki/Tmux) * Sur Ubuntu 20.04 LTS : `apt-get install tmux` * Créer une nouvelle session tmux : `tmux new -s innodb_migration` * Exécuter vos commandes ... * Se détacher sans fermer la session : `CTRL+b` puis touche `d` * Se connecter à la session existante : `tmux attach -t innodb_migration` * Quitter une session : `exit` {% endhint %} ## Migrer les données de MyISAM vers InnoDB Commande GLPI : * Commande **pt-online-schema-change** : * `--alter "ENGINE=InnoDB"` Voici l'utilisation complète en cli, vous pouvez tester avec `--dry-run` au lieu de `--execute` : ```bash $ pt-online-schema-change \ --alter "ENGINE=InnoDB" \ --ask-pass \ --execute \ D=glpi,t=glpi_logs,u=root,h=localhost ``` Vous pouvez changer les variables : * `u` comme utilisateur base de données * `h` comme hôte base de données * `D` comme nom de base de données * `t` comme table glpi à modifier ## Utiliser le type de données timestamp Commande GLPI : * Commande **pt-online-schema-change** : * `--alter "MODIFY COLUMN date_mod TIMESTAMP NULL DEFAULT NULL"` Voici l'utilisation complète en cli, vous pouvez tester avec `--dry-run` au lieu de `--execute` : ```bash $ pt-online-schema-change \ --alter "MODIFY COLUMN date_mod TIMESTAMP NULL DEFAULT NULL" \ --ask-pass \ --execute \ D=glpi,t=glpi_logs,u=root,h=localhost ``` Vous pouvez changer les variables : * `u` comme utilisateur base de données * `h` comme hôte base de données * `D` comme nom de base de données * `t` comme table glpi à modifier ## Réparer les INDEX corrompus Si par accident ou erreur, les INDEX d'une de vos tables sont corrompus (vous l'avez découvert grâce à la commande MySQL **CHECK**), nous recommandons de relancer la commande `--alter "ENGINE=InnoDB"`, vos **INDEX** de table seront reconstruits tout en gardant vos données en sécurité. ## Récupérer l'espace disque après suppression de données Après avoir fait beaucoup de nettoyage dans votre table **glpi\_logs** (supprimant des millions de lignes par exemple) vous vous rendez compte que l'espace disque utilisé n'a pas changé côté système de fichiers. Sans entrer dans les détails du fonctionnement du moteur de stockage InnoDB, dites-vous que c'est normal vous devez "OPTIMIZER" votre table. Pour cela, nous recommandons une fois de plus de relancer la commande `--alter "ENGINE=InnoDB"`, vos **INDEX** de table seront reconstruits tout en gardant vos données en sécurité et récupérer l'espace disque utilisé. ## Exécuter pour toutes les tables Voici un script pour modifier toutes les tables pour une base de données spécifique. Assurez-vous d'adapter la commande **ALTER\_COMMAND** avec la bonne action à effectuer (voir les chapitres précédents). (vous pouvez tester avec `--dry-run` au lieu de `--execute`) ```bash #!/bin/bash DBNAME=glpi DBUSER=root DBPWD=password DBHOST=localhost ALTER_COMMAND="MODIFY COLUMN date_mod TIMESTAMP NULL DEFAULT NULL" for TABLENAME in $(mysql -h$DBHOST -u$DBUSER -p$DBPWD --batch --column-names=false -e "show tables" $DBNAME); do pt-online-schema-change \ --alter $ALTER_COMMAND \ --execute \ D=$DBNAME,t=$TABLENAME,u=$DBUSER,p=$DBPWD,h=$DBHOST done ```