Bug #84868 Please make it possible to query replication information consistently
Submitted: 7 Feb 2017 20:26 Modified: 8 Feb 2017 9:42
Reporter: Simon Mudd (OCA) Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.7 OS:Any
Assigned to: CPU Architecture:Any
Tags: configuration, replication, STATUS

[7 Feb 2017 20:26] Simon Mudd
We now have various places to find replication information:
* mysql.slave* tables
* performance_schema.replication* tables

The problem now is that none of this is consistent.  Some information is provided in one place, and other information is provided elsewhere.  With GTID based replication some information has been added without including file/position information (even if it's not explicitly needed, it may be good for diagnostics etc), and it's likely that Group Replication will also add more places to check for configuration or status.

How to repeat:
When monitoring it becomes hard to be sure what information is available and where it should be retrieved from. This is more so as new information is added and may not be found where you expect it.

See also: https://datacharmer.blogspot.nl/2016/09/improving-design-of-mysql-replication.html which indirectly talks about this.

Suggested fix:
It would be convenient to have the information stored consistently.

That is:
* the status information being stored in performance_schema tables
* the configuration information being stored probably in mysql.* tables (as P_S tables are generally expected not to be persistent)

For backwards compatibility existing commands or tables should be generated as "views" from the final source data and it should be made clear which "source of truth" is preferred.

This will simplify the task of those who have to setup monitoring of the server as it will then be clearer where to look for the data.
[8 Feb 2017 9:41] MySQL Verification Team
Hello Simon,

Thank you for the report and feedback.
Verifying as feature request.