(PECL mysqlnd_ms >= 1.0.0)
mysqlnd_ms_get_stats — Retourne des statistiques quant à la distribution et la connexion de requêtes
Retourne un tableau de statistiques collectées par le plugin de réplication et d'équilibrage de charge.
La directive de configuration PHP mysqlnd_ms.collect_statistics contrôle la collection des statistiques. Elle est désactivée par défaut pour des raisons de performance.
Le scope des statistiques est le processus PHP. Suivant votre modèle de déploiement, un processus PHP peut gérer une ou plusieurs demandes.
Les statistiques sont agrégées pour toutes les connexions et tous les gestionnaires de stockage. Il n'est pas possible de demander le nombre de requêtes émanant d'appels API mysqli, PDO_MySQL ou mysql utilisées pour les valeurs agrégées.
Cette fonction ne contient aucun paramètre.
Retourne NULL si la directive de configuration PHP
mysqlnd_ms.enable
a désactivé le plugin. Sinon, la fonction retourne un tableau de statistiques.
Tableau de statistiques
| Statistique | Description | Version |
|---|---|---|
| use_slave |
La sémantique de cette statistique a changé entre les versions 1.0.1 et 1.1.0. La signification pour la version 1.0.1 est la suivante. Nombre de requêtes considérées comme en lecture seule par l'analyseur de requête interne. Ni les requêtes commençant par une astuce SQL pour forcer l'utilisation d'un esclave, ni les requêtes dirigées vers un esclave par une fonction de rappel définie par les utilisateurs ne sont inclus dans ce chiffre. Le nombre total de requêtes envoyées aux esclaves correspond à use_slave + use_slave_sql_hint + use_slave_callback. PECL/mysqlnd_ms 1.1.0 introduit un nouveau concept de filtres chaînés. Le statistique est maintenant définie par le filtre interne de balance de charge. Avec la version 1.1.0, le filtre de balance de charge est toujours le dernier dans un filtre chaîné, si utilisé. Dans les versions futures, un filtre de balance de charge pourra être suivi d'autres filtres, faisant ainsi une nouvelle fois évoluée la signification de cette statistique. Si, dans le futur, un filtre de balance de charge est suivi par un autre filtre, il ne sera plus garanti que la requête, qui incrémente use_slave, sera belle et bien exécutée sur un esclave. La signification pour la version 1.1.0 est la suivante. Nombre de requêtes envoyées aux esclabes. Les requêtes dirigées vers un esclave par un filtre utilisateur (une fonction de rappel définie par l'utilisateur) ne sont pas incluses. Elles le seront par la statistique use_slave_callback. |
Depuis la version 1.0.0. |
| use_master |
La sémantique de cette statistique a changée entre les versions 1.0.1 et 1.1.0. La signification pour la version 1.0.1 est la suivante. Nombre de requêtes considérées comme n'étant pas en lecture seule par l'analyseur interne de requêtes. Ni les requêtes commençant par une astuce SQL pour forcer l'utilisation d'un maître, ni les requêtes redirigées vers un maître par une fonction de rappel définie par l'utilisateur ne sont incluses dans cette statistique. Le nombre total de requêtes envoyées vers le maître correspond à use_master + use_master_sql_hint + use_master_callback. PECL/mysqlnd_ms 1.1.0 introduit un nouveau concept de filtres chaînés. La statistique est maintenant défini par le filtre de balance de charge interne. Avec la version 1.1.0, le filtre de balance de charge est toujours le dernier filtre d'un filtre chaîné, si utilisé. Dans les versions futures, un filtre de balance de charge pourra être suivi par d'autres filtres, faisant ainsi une nouvelle modification dans la signification de cette statistique. Si, dans le futur, un filtre de balance de charge est suivi par un autre filtre, il ne sera plus garanti que la requête, qui incrémente use_master, sera belle et bien exécutée sur un esclave. La signification pour la version 1.1.0 est la suivante. Nombre de requêtes envoyées aux maîtres. Les requêtes dirigées vers un maître par un filtre utilisateur (une fonction de rappel définie par l'utilisateur) ne sont pas incluses. Mais elles le seront dans la statistique use_master_callback. |
Depuis la version 1.0.0. |
| use_slave_guess | Nombre de requêtes dont l'analyseur de requêtes recommande d'envoyer vers un esclave car la requête ne contient aucune astuce SQL pour forcer l'utilisation d'un serveur en particulier. Cette recommandation peut être modifiée par la suite. Il n'est pas garanti que la requête soit bien exécutée sur un esclave. Cela signifie juste que la fonction is_select interne a indiqué qu'un esclave devrait être utilisé. Rapportez-vous à la fonction mysqlnd_ms_query_is_select() de l'espace utilisateur. | Depuis la version 1.1.0. |
| use_master_guess | Nombre de requêtes dont l'analyseur interne recommande d'envoyer vers un maître car la requête ne contient aucune astuce SQL pour forcer l'utilisation d'un serveur en particulier. Cette recommandation peut être modifiée par la suite. Il n'est pas garanti que la requête soit bien exécutée sur un esclave. Cela signifie juste que la fonction is_select interne a indiqué qu'un maître devrait être utilisé. Rapportez-vous à la fonction mysqlnd_ms_query_is_select() de l'espace utilisateur. | Depuis la version 1.1.0. |
| use_slave_sql_hint | Nombre de requêtes envoyées à un esclave par le fait que la requête commence par une astuce SQL pour forcer l'utilisation d'un esclave. | Depuis la version 1.0.0. |
| use_master_sql_hint | Nombre de requêtes envoyées au maître par le fait que la requête commence par une astuce SQL pour forcer l'utilisation du maître. | Depuis la version 1.0.0. |
| use_last_used_sql_hint | Nombre de requêtes envoyées au serveur qui a exécuté les précédentes requêtes, par le fait que la requête commence par une astuce SQL pour forcer l'utilisation du serveur précédemment utilisé. | Depuis 1.0.0. |
| use_slave_callback | Nombre de requêtes envoyées à l'esclave en raison d'une fonction de rappel utilisateur choisissant un serveur esclave pour l'exécution des requêtes. | Depuis 1.0.0. |
| use_master_callback | Nombre de requêtes envoyées au maître en raison d'une fonction de rappel utilisateur choisissant un serveur esclave pour l'exécution des requêtes. | Depuis 1.0.0. |
| non_lazy_connections_slave_success | Nombre de connexions ouvertes avec succès vers un esclave avec une configuration n'utilisant pas les lazy connections. Le nombre total de connexions ouvertes avec succès vers un esclave correspond à non_lazy_connections_slave_success + lazy_connections_slave_success | Depuis 1.0.0. |
| non_lazy_connections_slave_failure | Nombre de connexions échouées vers un esclave avec une configuration n'utilisant pas les lazy connections. Le nombre total de connexions échouées vers un esclave correspond à non_lazy_connections_slave_failure + lazy_connections_slave_failure | Depuis 1.0.0. |
| non_lazy_connections_master_success | Nombre de connexions ouvertes avec succès vers un maître avec une configuration n'utilisant pas les lazy connections. Le nombre total de connexions ouvertes avec succès vers un maître correspond à non_lazy_connections_master_success + lazy_connections_master_success | Depuis 1.0.0. |
| non_lazy_connections_master_failure | Nombre de connexions échouées vers un maître avec une configuration n'utilisant pas les lazy connections. Le nombre total de connexions échouées vers un maître correspond à non_lazy_connections_master_failure + lazy_connections_master_failure | Depuis 1.0.0. |
| lazy_connections_slave_success | Nombre de connexions ouvertes avec succès vers un esclave avec une configuration utilisant les lazy connections. | Depuis 1.0.0. |
| lazy_connections_slave_failure | Nombre de connexions échouées vers un esclave avec une configuration utilisant les lazy connections. | Depuis 1.0.0. |
| lazy_connections_master_success | Nombre de connexions ouvertes avec succès vers un maître avec une configuration utilisant les lazy connections. | Depuis 1.0.0. |
| lazy_connections_master_failure | Nombre de connexions échouées vers un maître avec une configuration utilisant les lazy connections. | Depuis 1.0.0. |
| trx_autocommit_on | Nombre d'activations du mode autocommit via des appels à l'API. Peut être utilisé pour surveiller l'activité relative à la configuration trx_stickiness du plugin. Si, par exemple, vous souhaitez savoir si un appel particulier à l'API invoque la fonction trx_autocommit() de la bibliothèque mysqlnd, ce qui est une nécessité pour trx_stickiness, vous pouvez appeler la fonction utilisation de l'API en question, et vérifier si les statistiques ont été modifiées. Les statistiques sont modifiées uniquement par la méthode trx_autocommit() interne du plugin. | Depuis 1.0.0. |
| trx_autocommit_off | Nombre de désactivations du mode autocommit via des appels à l'API. | Depuis 1.0.0. |
| trx_master_forced | Nombre de requêtes redirigées vers le maître alors que trx_stickiness=master et le mode autocommit sont désactivés. | Depuis 1.0.0. |
| gtid_autocommit_injections_success | Noombre d'injections SQL avec succès en mode autocommit, faisant parti du plugin côté client de l'émulation de l'ID de transaction globale. | Depuis 1.2.0. |
| gtid_autocommit_injections_failure | Nombre d'injections SQL échouées en mode autocommit, faisant parti du plugin côté client de l'émulation de l'ID de transaction globale. | Depuis 1.2.0. |
| gtid_commit_injections_success | Nombre d'injections SQL avec succès en mode commit, faisant parti du plugin côté client de l'émulation de l'ID de transaction globale. | Depuis 1.2.0. |
| gtid_commit_injections_failure | Nombre d'injections SQL échouées en mode commit, faisant parti du plugin côté client de l'émulation de l'ID de transaction globale. | Depuis 1.2.0. |
| gtid_implicit_commit_injections_success | Nombre d'injections SQL avec succès lorsqu'un commit implicite est détecté, faisant parti du plugins côté client de l'émulation de l'ID de transaction globale. Les commits implicites surviennent, par exemple, lorsque l'autocommit a été désactivé, une requête est exécutée, puis, l'autocommit ré-activé. Dans ce cas, la requête sera commité par le serveur et le SQL sera injecté avant la ré-activation de l'autocommit. | Depuis 1.2.0. |
| gtid_implicit_commit_injections_failure | Nombre d'injections SQL échouées lorsque le commit implicite est détecté, faisant parti du plugins côté client de l'émulation de l'ID de transaction globale. Les commits implicites surviennent, par exemple, lorsque l'autocommit a été désactivé, une requête est exécutée, puis, l'autocommit ré-activé. Dans ce cas, la requête sera commité par le serveur et le SQL sera injecté avant la ré-activation de l'autocommit. | Depuis 1.2.0. |
Exemple #1 Exemple avec mysqlnd_ms_get_stats()
<?php
printf("mysqlnd_ms.enable = %d\n", ini_get("mysqlnd_ms.enable"));
printf("mysqlnd_ms.collect_statistics = %d\n", ini_get("mysqlnd_ms.collect_statistics"));
var_dump(mysqlnd_ms_get_stats());
?>
L'exemple ci-dessus va afficher :
mysqlnd_ms.enable = 1
mysqlnd_ms.collect_statistics = 1
array(26) {
["use_slave"]=>
string(1) "0"
["use_master"]=>
string(1) "0"
["use_slave_guess"]=>
string(1) "0"
["use_master_guess"]=>
string(1) "0"
["use_slave_sql_hint"]=>
string(1) "0"
["use_master_sql_hint"]=>
string(1) "0"
["use_last_used_sql_hint"]=>
string(1) "0"
["use_slave_callback"]=>
string(1) "0"
["use_master_callback"]=>
string(1) "0"
["non_lazy_connections_slave_success"]=>
string(1) "0"
["non_lazy_connections_slave_failure"]=>
string(1) "0"
["non_lazy_connections_master_success"]=>
string(1) "0"
["non_lazy_connections_master_failure"]=>
string(1) "0"
["lazy_connections_slave_success"]=>
string(1) "0"
["lazy_connections_slave_failure"]=>
string(1) "0"
["lazy_connections_master_success"]=>
string(1) "0"
["lazy_connections_master_failure"]=>
string(1) "0"
["trx_autocommit_on"]=>
string(1) "0"
["trx_autocommit_off"]=>
string(1) "0"
["trx_master_forced"]=>
string(1) "0"
["gtid_autocommit_injections_success"]=>
string(1) "0"
["gtid_autocommit_injections_failure"]=>
string(1) "0"
["gtid_commit_injections_success"]=>
string(1) "0"
["gtid_commit_injections_failure"]=>
string(1) "0"
["gtid_implicit_commit_injections_success"]=>
string(1) "0"
["gtid_implicit_commit_injections_failure"]=>
string(1) "0"
}