Bug #70434 move replication_*_configuration from P_S to I_S
Submitted: 26 Sep 2013 11:30 Modified: 2 Oct 2013 19:50
Reporter: Miguel Angel Nieto Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: Replication Severity:S4 (Feature request)
Version:5.7.2 OS:Any
Assigned to: CPU Architecture:Any

[26 Sep 2013 11:30] Miguel Angel Nieto
There are two useful tables in P_S not related with Performance at all that in my opinion should be in I_S.


Those two tables show us the channels configured for multi source and some other different configuration parameters that are useful when we have to gather information from a server. Since those two tables are not performance related they should be moved to I_S. I found "strange" to have to enable P_S just to get configuration information from a slave server.

Also, something like:


would be helpful.

How to repeat:
Just configure multi source replication and SELECT from those tables.
[2 Oct 2013 10:37] Hartmut Holzgraefe
Yes, back then when i created the replication status I_S plugins i was told (simply as tables producing the same result set on SELECT as a SHOW MASTER/SLAVE STATUS would), i was told that most data in there belonged into the "soon to come" P_S.

Now some six or more years later we finally have an alternative to parsing SHOW output, but now static config info ends up on the P_S side instead of being in I_S, even though unlike in my "naive" approach back then the config information is in separate tables form the actual status info ...
[2 Oct 2013 19:50] Marc ALFF
The INFORMATION_SCHEMA is for metadata.

The PERFORMANCE_SCHEMA is for the server runtime state.

The performance schema contains a lot of data related to performance measurements, but it is not "only" about performance.

See for example the HOST_CACHE table.

The new replication tables do work as intended.