Description:
We now have various places to find replication information:
* SHOW SLAVE STATUS
* 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.
