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
[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! regards, Umesh
[19 Nov 2018 16:03]
Miguel Araujo
Posted by developer: Hi, 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.