Bug #106815 improve instrumentation of group replication group changes
Submitted: 24 Mar 2022 8:45 Modified: 18 Jan 7:21
Reporter: Simon Mudd (OCA) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Group Replication Severity:S4 (Feature request)
Version:8.0.28 OS:Any
Assigned to: CPU Architecture:Any
Tags: group replication, instrumentation

[24 Mar 2022 8:45] Simon Mudd
Description:
Related to bug#106526 we notice there is very little information related to instrumentation of group replication "topology changes". This makes it hard to identify issues as referenced in bug#106526 and thus to more easily identify the cause (and hopefully resolve it).

How to repeat:
Try to identify information about the group and see that a lot of useful information may be missing.

Suggested fix:
Provide something like the following instrumented values:
- timestamp of group creation
- timestamp of group startup 

- timestamp of last group state change
- type of last group change
- time to achieve last group change (latency from begin to end)
- number of changes in the group state (not transaction but "topology changes")
- sum_of_group_change_latency
- min_group_change_latency
- max_group_change_latency

- group_member_timestamp_joined_group
- group_member_timestamp_of_last_member_state_change (I can imagine joined, change between multi-write / single write, or from secondary to primary)
- group_member_version_supported (I think this is already provided somewhere)
- group_member_version_used (I think this is already provided somewhere and probably common to all group members)

This extra information, or something like it would I think be useful for identifying "group topopology/state changes". That information is partly visible now but only via logs so hard(er) to query or monitor externally.
[24 Mar 2022 9:12] MySQL Verification Team
Hello Simon,

Thank you for the feature request!

regards,
Umesh
[18 Jan 7:19] Simon Mudd
related: bug#106815
[18 Jan 7:21] Simon Mudd
related: bug#113675 (correction)