But

Pouvoir utiliser un réplicat MySQL afin de traiter les cas suivants :
  • base MySQL maître innacessible
  • traitements lourds que l'on ne veut pas effectuer sur la base de production pour ne pas faire baisser les performances

Ce qui a été implémenté

Ajout d'un menu dans Administration appelé "Réplicat MySQL"
L'activation du réplicat entraine la création d'un fichier config_db_slave.php dans le répertoire config. Ce fichier contient la classe DbSlave, qui stocke les paramètres d'accès à la base répliquée.

L'écran de configuration du réplicat propose les paramètres suivants :
  • hôte, port, user, password et base MySQL
  • option pour indiquer si l'on veut être notifié quand la base esclave est désynchronisée
  • email de la personne à notifier
  • délai en secondes à partir duquel on estime l'esclave désynchronisé

Ajout d'un cron

Un script cron a été ajouté afin de vérifier périodiquement si l'eslave est toujours synchronisé avec le maître

Fonctionnement de l'esclave

Il y a 2 utilisations de l'esclave.

Perte de connexion à la base maître

Si la base maître cesse de répondre, GLPI basculera automatiquement sur la base esclave.
Au niveau du code, cela se traduit par le fait que la variable $DB pointera sur la base esclave, et non la base maître.
un message apparaît en haut à gauche de l'écran (similaire à celui qui indique mode debug, mais en bleu et situé juste à côté de celui-ci) indiquant que GLPI est en lecture seule.

Lorsque GLPI utilise la base esclave, aucune modification n'est possible dans l'interface :
  • la fonction haveRight renverra toujours 'r' si on a demandé un droit 'w'
  • les fonctions add, update et delete de commondbtm ne mettent pas à jour la base
  • le cron de synchronisation des machines OCS n'effectue aucun import
  • la procédure d'authentification fonctionne, mais ne met pas à jour les données utilisateur (aussi bien sur la base interne que par LDAP)
  • aucun évènement n'est loggé dans le journal GLPI

Bascule volontaire sur la base esclave

Il est possible, pour certaines pages, de préciser le comportement de connexion à la base de données. Cela peut avoir du sens, par exemple, où l'on désire afficher un rapport très gourmand en requêtes sur la base de données.
La version 0.71 de GLPI introduit 2 nouvelles variables qui permettent de règler le fonctionnement de la connexion à la base :
  • $USEDBREPLICATE : la valeur 1 indique que l'on demande explicitement l'utilisation de l'esclave
  • $DBCONNECTION_REQUIRED : la valeur 1 indique que si la connexion demandée n'est pas disponible, un message d'erreur apparaît et bloque la poursuite de la navigation
Cas de figure :
  • $USEDBREPLICATE=1 et $DBCONNECTION_REQUIRED=1 : on demande l'utilisation de la base esclave uniquement. Si celle-ci n'est pas disponible, un message d'erreur apparaît
  • $USEDBREPLICATE=1 et $DBCONNECTION_REQUIRED=0 : on demande l'utilisation de la base esclave. Si celle-ci n'est pas disponible, GLPI bascule automatiquement sur la base maître
  • $USEDBREPLICATE=0 et $DBCONNECTION_REQUIRED=1 : on demande l'utilisation de la base maître uniquement. Si celle-ci n'est pas disponible, un message d'erreur apparaît
  • $USEDBREPLICATE=0 et $DBCONNECTION_REQUIRED=0 : on demande l'utilisation de la base ma$itre. Si celle-ci n'est pas disponible, GLPI bascule automatiquement sur la base esclave

Sur la version 0.70, ces options ne sont pas prises en compte. Il est possible de les indiquer (par exemple pour un plugin qui doit les utiliser dans la version 0.71), elles ne perturberont pas l'exécution.