MySQL Bugs: #70434: move replication_*_configuration from P_S to I

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:	None
Category:	MySQL Server: Replication	Severity:	S4 (Feature request)
Version:	5.7.2	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
There are two useful tables in P_S not related with Performance at all that in my opinion should be in I_S.

replication_connection_configuration
replication_execute_configuration

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:

SHOW SLAVE STATUS FOR CHANNEL ALL; 

would be helpful.

How to repeat:
Just configure multi source replication and SELECT from those tables.

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 ...

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.