Si vous avez migré plus ou moins récemment de version de MySQL vers 5.7 ou 8.0, vous ne l’avez peut être pas encore remarqué, mais il y a eu quelques petits changements au niveau des variables de statut. Outre le fait de les avoir déplacé d’information_schema vers performance_schema ou le schéma sys à partir de la 5.7.9, en plus un certain nombre d’entre elles auront disparu:
– Avant la version 5.7:
mysql> select version() ; +-----------------------+ | version() | +-----------------------+ | 5.6.17-1~dotdeb.1-log | +-----------------------+ mysql> select count(1) from information_schema.global_status ; +----------+ | count(1) | +----------+ | 341 | +----------+
– à partir de la version 5.7 :
mysql> select version() ; +--------------+ | version() | +--------------+ | 5.7.10-3-log | +--------------+ mysql> select count(1) from performance_schema.global_status ; +----------+ | count(1) | +----------+ | 231 | +----------+
C’est particulièrement flagrant pour les compteurs orientés Commands, ou Com_%…
– avant 5.7:
mysql> select count(1) from information_schema.global_status
-> where VARIABLE_NAME like 'Com_%' ;
+----------+
| count(1) |
+----------+
| 142 |
+----------+
– en 5.7+:
mysql> select count(1) from performance_schema.global_status
-> where VARIABLE_NAME like 'Com_%' ;
+----------+
| count(1) |
+----------+
| 1 |
+----------+
mysql> select count(1) from sys.metrics
-> where Variable_name like 'Com_%' ;
+----------+
| count(1) |
+----------+
| 5 |
+----------+
Quand même… D’où la question éponyme.
Alors où sont-ils passés ?
En 2016, Peter Zaitsev lui-même remonte cette bizarrerie dans le bug request #81632, pour que finalement Oracle ne réponde que la localisation de ces compteurs Com_% à logiquement évolué vers les events de Performance Schema.
Dans la doc à partir de la version 5.7+:
“The Performance Schema does not collect statistics for Com_xxx status variables in the status variable tables. To obtain global and per-session statement execution counts, use the events_statements_summary_global_by_event_name and events_statements_summary_by_thread_by_event_name tables, respectively.”
Nous étions donc prévenus.
Par exemple si l’on veut retrouver l’équivalent des compteurs types Com_Select, Com_Update, Com_Delete, Com_Insert, Com_Insert_Select on ira chercher dans les vues de P_S de cette manière:
mysql> SELECT EVENT_NAME, COUNT_STAR
-> FROM performance_schema.events_statements_summary_global_by_event_name
-> WHERE EVENT_NAME in
-> ('statement/sql/select','statement/sql/update','statement/sql/delete',
-> 'statement/sql/insert','statement/sql/insert_select') ;
+-----------------------------+------------+
| EVENT_NAME | COUNT_STAR |
+-----------------------------+------------+
| statement/sql/select | 340039338 |
| statement/sql/update | 13467671 |
| statement/sql/insert | 1715801 |
| statement/sql/insert_select | 7680967 |
| statement/sql/delete | 19016156 |
+-----------------------------+------------+
Evidemment comme avant il faudra les sampler pour avoir une valeur par minute, une moyenne par seconde, etc… Plus possible d’utiliser pt-mext ou autres outils de l’époque de Maatkit pour pouvoir faire le job, donc à vous de trouver la méthode de rollover qui convient le mieux. Pour l’agent AllDB MySQL par exemple, nous avons choisi de ne pas utiliser d’objet relationnel pour faire le sampling pour minimiser l’impact potentiel sur les systèmes de production (binlogs, réplications, etc…).
A bientôt !
~David
Continuez votre lecture sur le blog :
- Texte SQL tronqué dans les vues performance_schema en 5.6 et 5.7, il faut migrer ! (David Baffaleuf) [MySQL]
- Faciliter la lecture des mesures de temps dans performance_schema (David Baffaleuf) [MySQL]
- Nouveautés MySQL 8.0 : Variables persistés (Capdata team) [MySQL]
- Nouveautés MySQL 8.0 : Les Histogrammes (Capdata team) [MySQL]
- default_password_lifetime à 360 jours entre la 5.7.4 et 5.7.10 (David Baffaleuf) [MySQL]