MySQL Bugs: #111210: please add weight to replication_group

Bug #111210	please add weight to replication_group_members
Submitted:	31 May 2023 6:40	Modified:	31 May 2023 7:01
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: Group Replication	Severity:	S4 (Feature request)
Version:	8.0	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	group_replication, performance schema, replication_group_members, weight

Description:
There is an article here about weighting of members: https://dev.mysql.com/blog-archive/group-replication-prioritise-member-for-the-primary-mem...

The way to see the weights of the group (which all members must know given they use this information to decide on failover criteria) yet that information is not visible for the cluster globally without querying each member in turn.

There is a variable group_replication_member_weight but I think it would be better to share the cluster state by including weight in performance_schema.replication_group_members.

How to repeat:
Check the docs.
Look for cluster state where weight can be seen for each member and notice that this information is not visible for the whole cluster.

Suggested fix:
Expose the server's weight setting in performance_schema.replication_group_members.

If there are other global configuration settings that the members also share perhaps including them would be useful too.

There is a new innovation release expected shortly so maybe this is the time to make such a change?

Hello Simon,

Thank you for the feature request!

regards,
Umesh

The documentation is rather vague here about the extreme values that can be set.
If I want to PREVENT a server being used for failovers yet want it to participate under normal circumstances I do not appear to have a way to do that.

The weight of 0 does not necessarily imply that a failover to this server should not take place.  Consider maintenance windows and/or when we may really not want to promote a specific server (e.g. a test version) for one or more reasons.  The promotion rules as they stand reduce the possibility of the failover taking place on a server I give a weight of 0 to but do not prevent that.  I believe such a feature would be convenient using the value of 0 (current minimum value) or perhaps something like -1.

This would allow the failover logic to behave as now and PREVENT the server(s) with such a priority to be failed over to. Clearly doing so may mean that a failover is not possible and the expected redundancy may actually be lower than implicitly defined by the group members being ONLINE but this is a policy decision in the configuration.

I identified the same need while evaluating MySQL Group Replication.

I have implemented support for group_replication_group_member_weight in performance_schema.replication_group_members in https://github.com/mysql/mysql-server/pull/601 .

However, note that with this implementation if group_replication_group_member_weight is changed on one member that the weight will not be propagated to other nodes (see https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_gro...). If you want the changed value to be propagated, you need to `stop group_replication; start group_replication` on the node in question. This limitation is acceptable for my needs, so I haven't explored making the change propagate without this (it would probably be a lot more work as new cluster membership messages may be required).

Note that I have been added to an existing corporate CLA and my contribution is covered by that CLA.

Contribution submitted via Github - Bug#111210 Extend pfs.replication_group_members to include MEMBER_WEIGHT (*) Contribution by Buchan Milne (Github bgmilne, mysql-server/pull/601#issuecomment-2668975815): "I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it."

Contribution: git_patch_2344536258.txt (text/plain), 7.33 KiB.