Bug #92293 MySQL InnoDB Cluster/Group Replication Server StartUp Sequence Request
Submitted: 5 Sep 2018 8:32 Modified: 17 Nov 2018 6:50
Reporter: Ivan Ma Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: Group Replication Severity:S4 (Feature request)
Version:5.7, 8.0 OS:Any
Assigned to: CPU Architecture:Any

[5 Sep 2018 8:32] Ivan Ma
It is a feature Request for MySQL Group Replication.

Can we have a feature to ensure the startup sequence in a proper order no matter which member is started up first.

Scenarios : A  group (member-A,B,C) which shutdown in sequence (A,B and then C).   The last member C before it is shut down, there are more transactions getting in.  GTID in memberC will have more than A and B.

Startup sequence has to start the C first in order to get the full image of latest Data.

This is very problematic to determine the Shutdown sequence when the GR is not shutdown in any sequence due to CRASH or some other reasons. 

If Startup is not in proper sequence, the LARGEST set of GTID at the end will be rejected to join the GR.

How to repeat:
1. Just shutdown A, B.  with C alone, more data to go into the C server.
2. Shutdown the C.
3. Startup A and B and Startup C
- C will be rejected to be the member of the GR (A&B)

Suggested fix:

1. Set a time (with timeout - e.g.5mins) to start up any members.  They synchronize themselves to get acknownlegement to which one is the TRUE master to be the SUPERSET.

2. With InnoDB Cluster, get a process (daemons) on each machine to startup servers where the daemon on each server to synchronize the Last Know Good Status of the Server and Determine which server to start up first and start the Server as a FULL GROUP REPLICATION.
[5 Sep 2018 8:39] Ivan Ma
Change S3 to S4 (feature Request)
[17 Nov 2018 6:50] MySQL Verification Team
Hello Ivan Ma,

Thank you for the feature request!

[19 Nov 2018 16:03] Miguel Araujo
Posted by developer:

This is a feature that shall be handled in the orchestration layer, i.e. within the scope of MySQL InnoDB Cluster. That said, this is a scenario that must be handled by the MySQL Shell / AdminAPI.

The AdminAPI has a command to recover a cluster from a complete outage, i.e. when **every** cluster member goes offline and the group is "dissolved". That's the command that has to be used in a scenario such as the one reported in this bug report.

The command is called: dba.rebootClusterFromCompleteOutage(), and amongst several validations, it does the following:

- Obtains the cluster members as registered in the Metadata.

- Determines which of the cluster members has the GTID superset.

- If the active session is not to the member with the GTID superset the command aborts and indicates to the user which is the instance with the GTID superset.

The command shall be improved/extended to have an optional parameter to determine whether it should automatically determine which of the cluster members has the GTID superset and use it to (re)bootstrap the group. That parameter should be enabled by default.