Description:
See slack thread: https://mysqlcommunity.slack.com/archives/CL7F7MAGP/p1705492363825459
Currently there seems to be some missing information about a GR cluster which it might be useful to expose. Reasons for exposing would be better visibility on cluster health or when cluster configuration changes.
Examples of such "missing" (I think) configuration is:
Having a set of PS values which give some more global GR state would be useful.
Interesting metrics/timestamps to share would be:
- time of creation of the cluster (this may be considerably longer than the uptime of all current running members)
- count of changes in the cluster state since its creation (is this the cluster view?)
- count of changes and time of last change of the primary configuration
- if single primary when a primary changes or
- time when changing between single and multi-primary modes
- count of cluster membership changes, (addition of new members or removal/expulsion of members). It might be convenient to record "requested changes" from "forced changes" (due to failures) as that would help separate maintenance changes from cluster partial failures etc.
I imagine all this information is or could be available in the cluster but it is not exposed at the moment.
How to repeat:
I'm not aware of this information being available now.
LeFred suggested finding the time of the last primary change using something like select * from performance_schema.error_log where subsystem='Repl' and data like '%elected%';
but this is fragile as it depends on the information being in the error log and after some time log rotation may mean the data disappears.
Suggested fix:
These metrics would improve cluster visibility.
I think they should be straightforward to keep and then monitoring of cluster health would be much simpler as a single SELECT whatever FROM performance_schema.SOME_NEW_TABLE would given the required values.
Given cluster configuration changes are infrequent this should not cause any issues with performance or locking.
Getting this into 8.4 would be nice as I imagine modifying 8.0 to include this now is unlikely to happen.
