1.5.0-stable
Note:
C'est la série actuellement stable. Veuillez l'utiliser en environnement de production.
La documentation est complète.
1.5.0-alpha
Correction de bogues
Correction du bogue #60605 relatif à une erreur de segmentation lorsque mysqlnd_ms est activé.
Le fait des définir les transactions gluantes désactive toutes les balances de charge, incluant le failover automatique, pour la durée d'une transaction. Jusqu'alors, les switches de connexion peuvaient survenir au milieu d'une transaction en configuration multi-maîtres ainsi que durant le failover automatique bien que la surveillance des transactions avait détectée correctement les limites de la transaction.
Compatibilité ascendante rompue, et corrections de bogues.
Les astuces SQL permettant de forcer l'utilisation d'une sorte
de serveur (MYSQLND_MS_MASTER_SWITCH
,
MYSQLND_MS_SLAVE_SWITCH
,
MYSQLND_MS_LAST_USED_SWITCH
) étaient ignorées
pour la durée d'une transaction (gluante) alors que les limites
de la transaction avait été détectée correctement.
Ceci est une modification dans le comportement. Cependant, c'est également une correction de bogue, et une étape nécessaire pour rendre cohérent le comportement. Si, dans les précédentes versions, dans un contexte de transaction gluante, une de ces astuces SQL ainsi qu'une qualité de service se basant sur le filtrage étaient combinées, il pouvait arriver que les astuces SQL étaient ignorées. Dans quelques cas, les astuces SQL fonctionnaient normalement, dans d'autres, elles ne fonctionnaient pas. Ce nouveau comportement est plus cohérent. Les astuces SQL seront toujours ignorées pour la durée de la transaction, si les transactions gluantes sont actives.
Notez que la détection des limites des transactions continue d'être basée sur des appels de l'API de surveillance. Les commandes SQL contrôlant les transactions ne sont pas surveillées.
Compatibilité ascendante rompue, et corrections de bogues. Les appels à la fonction mysqlnd_ms_set_qos() échoueront lorsqu'effectués au milieu d'une transaction si les transactions gluantes sont actives. Les swtiches de connexion ne sont pas autorisées pour la durée d'une transaction. Le changement de qualité de service revient à qualifier un jeu de serveurs différent pour l'exécution de la requête, et donc, il se peut qu'il soit nécessaire de changer de connexions. Aussi, l'appel n'est pas autorisé durant une transaction. La qualité de service peut, cependant, être changée entre les transactions.
Modification de fonctionalités
Introduction du filtre node_group. Le filtre vous permet d'organiser les serveurs (maîtres et esclaves) dans des groupes. Les requêtes peuvent être dirigées vers un certain groupe de serveurs en préfixant la requête avec une astuce/commentaire SQL qui contient le nom de configuration du groupe. Les groupes peuvent être utilisés pour le partionnement et le partage, mais aussi pour optimiser localement le cache. Dans le cas du partage, le nom du groupe sera la clé du partage. Toutes les requêtes pour une clé de partage donnée seront exécutées sur le partage configuré. Notez qu'il est nécessaire qu'à la fois le client et le serveur supportent le partage pour être utilisé avec mysqlnd_ms.
Validation étendue du fichier de configuration lors du démarrage de PHP
(RINIT). Une erreur de niveau E_WARNING
sera émise si le
fichier de configuration ne peut pas être lu (en raison d'un problème de
permissions par exemple), s'il est vide, ou si le fichier (JSON) ne peut être
analysé. Ces alertes peuvent apparaître dans les fichiers de log, suivant
la configuration de PHP.
Les distributions qui fournissent une installation pré-configurée, incluant un exemple de fichier de configuration, doivent placer des {} dans le fichier de configuration pour éviter ces alertes à propos d'un fichier de configuration invalide.
Les prochaines validations du fichier de configuration seront effectuées lors de l'analyse des sections sur l'ouverture d'une connexion. Notez qu'il peut y avoir des situations où un fichier invalide de configuration d'un plugin n'émette pas la bonne alerte mais résulte en une erreur de connexion.
Depuis PHP 5.5.0, amélioration de la détection des limites d'une transaction pour mysqli. L'extension mysqli a été modifiée pour utiliser les nouveaux appels C API de la bibliothèque mysqlnd pour commencer, valider ou annuler une transaction ou un point de sauvegarde. Si le paramètre trx_stickiness est utilisé pour activer la balance de charge des transactions, les appels aux fonctions mysqli_begin(), mysqli_commit() et mysqli_rollback() seront maintenant surveillés par le plugin, en plus de la fonction mysqli_autocommit() qui l'était déjà. Toutes les fonctionalités SQL pour contrôler les transactions sont aussi disponibles via les fonctions de contrôles des transactions mysqli associées. Cela signifie qu'il n'est pas nécessaire d'utiliser des requêtes SQL à la place d'appels API. Les applications utilisant uniquement des appels API appropriés peuvent faire de la balance de charge avec PECL/mysqlnd_ms d'une façon totalement sécurisée pour les transactions.
Notez que PDO_MySQL n'a pas été mis à jour pour utiliser
les nouveaux appels API de mysqlnd. Aussi, la détection des limites d'une
transaction avec PDO_MySQL continue d'être limitée à la
surveillance en utilisant la constante PDO::ATTR_AUTOCOMMIT
à la méthode PDO::setAttribute().
Introduction de trx_stickiness=on. Cette option trx_stickiness diffère de trx_stickiness=master car elle tente d'exécuter une transaction uniquement en lecture sur un esclave, si la qualité de service (niveau de consistence) autorise d'utiliser un esclave. Les transactions uniquement en lecture ont été introduites en MySQL 5.6, offrant un gain important en terme de performance.
Le support du cache des requêtes est considéré comme béta si vous l'utilisez avec l'API mysqli. Il devrait fonctionner parfaitement avec des clusters basés sur une copie primaire. Pour toutes les autres APIs, cette fonctionalité est toujours expérimentale.
Les exemples de code dans les sources de mysqlnd_ms ont été mis à jour.