Bug #102433 Lightweigth group replication consensus member without the full database
Submitted: 1 Feb 2021 8:49 Modified: 1 Feb 2021 9:38
Reporter: Eduardo Ortega 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

[1 Feb 2021 8:49] Eduardo Ortega
Description:
Group replication provides high availability thanks to the built-in leader election and automatic fail-over (re-election) in case the leader fails. It also prevents  potential split brain scenarios as writes to the DB require a majority of the group to acknowledge they have received them before they are actually committed. However, unlike other DB vendor HA solutions, GR requires at the very least three instances communicating with each other to be able to have a majority and make decisions based on it, thus making it, from the point of view of number of running DB instances, more expensive (needing at least 3 instead of 2).

The issue repeats itself at a larger scale if you use cross-site replication groups. If you have two sites, a replication group with the same number of members on each them will lose consensus in case of network partition. You could have one site with more members than the other, but if that site fails (e.g. loses power), the group loses consensus. If you add a third site, you can run group members there as well, so that network or power failure of a single site does not lead to the group failing; however, it requires running DB instances on the third  site, which, again, translates into higher costs.

How to repeat:
N/A - this is a feature request, nothing to repeat

Suggested fix:
This feature request  is about MySQL providing an additional daemon that can be configured to be part of a replication group solely for the purposes of participating in consensus, but without actually running the full database under it. It would allow to deploy a lightweight, not resource intensive process that can be used instead of the third DB instance mentioned above, thus providing the benefits of group replication without the cost of running a full DB instance. The process would keep minimal state information (the bare minimum to known which group it belongs to and who are its peers in the group). It would not need to store any other data, apply transactions, etc. Thus, it could be run in lower specs hardware / VM / container / cloud instance. i.e. something like Galera Arbitrator but for MySQL group replication.
[1 Feb 2021 9:38] MySQL Verification Team
Hello Eduardo Ortega,

Thank you for the reasonable feature request!

regards,
Umesh