Par défaut, la gestion des incidents de connexion est laissée à l'utilisateur. L'application est responsable de la vérification des valeurs de retour des fonctions concernant les bases de données, et doit réagir en cas de detection d'erreur. Par exemple, si le plugin reconnait une requête de type lecture-seule et l'aiguille vers un serveur esclave dont la connexion n'est pas disponible, il renverra une erreur.
Défaut : failover manuel
C'est à l'application de gérer l'erreur, et, si besoin, de re-présenter la requête afin qu'elle soit re-prise en charge par le plugin et aiguillée vers un autre serveur. Le plugin ne se charge pas de ça lui-même, car il pourrait risquer d'impacter l'état des connexions, ce qui n'est pas du tout désirable. Par exemple, l'application peut avoir envoyé une requête comportant des variables de session MySQL, celles-ci sont dépendantes de la connexion utilisée. Une telle requête ne pourrait donc être prise en charge par un mécanisme automatique implémenté dans le plugin. L'application doit donc gérer ces cas-là, et aucune gestion des incidents de connexion n'est implémentée à l'intérieur du plugin.
Un utilisateur ne changeant pas le statut d'une connexion après l'avoir ouverte peut activer la gestion des incidents. Notez que la logique de failover automatique n'est pas utilisée pour les connexions déjà ouvertes. Il n'y a aucune façon pour indiquer au plugin de tenter un failover sur une connexion qui a été déjà connectée à MySQL dans le passé.
Failover automatique
Cette gestion des incidents se configure dans le fichier de configuration du plugin au moyen de la directive failover.
Le failover automatique et silencieux peut être activé via la directive de configuration failover. Le failover automatique peut être configuré soit pour essayer exactement un maître après l'échec d'un esclave ou bien, pour parcourir tous les esclaves et tous les maîtres avant de retourner une erreur à l'utilisateur. Le nombre de tentative de connexion peut être limité et les hôtes en échec peuvent être exclus des futurs tentatives de balance de charge. Liimiter le nombre de tentatives et le fait de retenir les hôtes en échec sont considérés comme des fonctionalités expérimentales malgré le fait qu'elles sont relativement stables. Leur syntaxe et leur signification peuvent être modifiées dans les futures versions.
Un exemple d'échec manuel est fourni dans la section sur les gestionnaires d'erreurs.
Serveurs de secours
En utilisant la balance de charge pondérée, introduite en PECL/mysqlnd 1.4.0, il est possible de configurer des serveurs de secours qui sont peu utilisés lors d'opérations normales. Un server de secours qui est utilisé comme cible en failover peut se voir assigner une priorité/un poids faible par rapport aux autres serveurs. Tant que tous les serveurs sont prêts et fonctionnels, la mageur partie de la charge est assignée aux serveurs qui ont un poids élevé. Une petite partie des requêtes sera redirigée vers le système de secours qui possède un poids faible.
Lors d'un échec d'un serveur possédant une priorité élevée, vous pouvez toujours basculer vers le secours, qui s'est vu attribué une priorité de balance de charge faible en y assignant un poids faible. Le failover peut être manuel ou automatique. S'il est automatique, vous pouvez vouloir le combiner avec l'option remember_failed.
A ce moment là, il n'est pas possible d'indiquer à la balance de charge de ne rediriger aucune requête au secours. Ceci ne peut être considéré comme une limitation sachant que le poids le plus élevé pouvant être assigné à un serveur est 65535. Si l'on prend deux esclaves, dont un va servir de secours avec un poids de 1, le secours devra gérer moins de un pourcent de la charge totale.
Failover et copie primaire
Veuillez noter que si vous utilisez une copie de cluster primaire, comme une réplication MySQL, il est difficile de faire un failover de connexion dans le cas où la connexion au maître échoue. A tout moment, il n'y a qu'un seul maître dans le cluster pour un jeu de données. Le maître représent un seul point. Si il échoue, les clients n'ont plus de cible à utiliser pour effectuer les requêtes en écriture. Dans le cas où le maître tombe en panne, l'administrateur de base de données doit prendre en compte la situation et mettre à jour les configurations des clients.