1.4.0-beta
Note:
C'est la série courante de développement. Toutes les fonctionnalités sont à un stade précoce. Des modifications peuvent survenir à tout moment sans aucune annonce préalable. Veuillez ne pas utiliser cette version en environnement de production.
La documentation peut ne pas refléter toutes les modifications.
1.4.0-alpha
Modifications des fonctionnalités
Compatibilité ascendante rompue : Renommage de l'option de configuration du plugin ini_file en config_file. Dans les versions précédentes, le fichier de configuration du plugin utilisait un style ini. A ce moment là, l'option de configuration était nommé en conséquent. Il a donc été renommé pour refléter le nouveau format de fichier et pour le distinguer depuis le fichier ini propre à PHP (fichier de configuration des directives).
Introduction de l'option de configuration du jeu de caractères par défaut server_charset pour permettre une échappement propre avant qu'une connexion ne soit ouverte. Ceci est pratique lors de l'utilisation des connexions paraisseuses, qui sont utilisées par défaut.
Introduction de l'option wait_for_gtid_timeout pour limiter les lectures d'un esclave qui a besoin d'une consistence de session. Si un identifiant de transaction globale est utilisé, et que le niveau de service est défini à une consistence de session, alors le plugin tentera de trouver des esclaves à jour. La vérification du statut de l'esclave est effectuée via une requête SQL. Si rien d'autre n'est défini, le statut de l'esclave est vérifié une seule fois, puis la recherche d'un esclave à jour continue immédiatement après. Le fait de définir l'option wait_for_gtid_timeout indique au plugin d'interroger le statut des esclaves pendant wait_for_gtid_timeout secondes si la première exécution de la requête SQL montre que l'esclave n'est pas encore à jour. L'interrogation sera effectuée une fois par seconde. De cette façon, le plugin va attendre d'attraper les esclaves et d'étrangler le client.
Nouvelle stratégie de failover loop_before_master. Par défaut, le plugin ne fait pas de failover. Il est possible d'activer un failover automatique si une tentative de connexion échoue. A partir de la version 1.3, seule la stratégie master existe pour le failover vers un maître si la connexion vers un esclave échoue. loop_before_master est similaire mais effectue une tentative sur tous les autres esclaves avant de tenter une connexion vers le maître si une connexion vers un esclave échoue.
Le nombre de tentative peut être limité en utilisant l'option max_retries. Les hôtes en échec peuvent être listés et ainsi, évités lors de la balance de charge pour le reste de la requête web. Les options max_retries et remember_failed sont considérées comme expérimentales tant qu'une certaine stabilité n'est pas atteinte. La syntaxe et leur signification peuvent changer dans le futur sans avertissement préalable.