MySQL Shell 8.0  /  ...  /  Repairing Member Servers and Clusters in an InnoDB ClusterSet

8.9.3 Repairing Member Servers and Clusters in an InnoDB ClusterSet

Depending on the issues or maintenance requirements for the cluster, the following operations are available for you to work with its member servers. Unless otherwise stated, use Cluster and ClusterSet objects that you fetched with an InnoDB Cluster administrator account or server configuration account, so that the default user account stored in the ClusterSet object has the correct permissions.

  • Add further server instances to the cluster, using the cluster.addInstance() command, as described in the procedure at Section 8.4, “Deploying InnoDB ClusterSet”. For more details of the command, see Section 7.4.4, “Adding Instances to an InnoDB Cluster”.

    Note that for this operation, you need to use the InnoDB Cluster server configuration account and a Cluster object that was fetched using that account. The account must also exist on the server instance, as explained in Section 8.3, “User Accounts for InnoDB ClusterSet”.

    When you use this command to add a member server to an InnoDB Cluster that is part of an InnoDB ClusterSet deployment, the server instance is added to the cluster and provisioned with the data for the InnoDB ClusterSet. The ClusterSet replication channel is set up on the instance, and the required configuration to operate in an InnoDB ClusterSet deployment is applied.

  • Rejoin a server instance that was previously part of the cluster but could not automatically rejoin the cluster, using the cluster.rejoinInstance() command. For details of this operation, see Rejoining an Instance to a Cluster.

    When you use this command to rejoin a member server to an InnoDB Cluster that is part of an InnoDB ClusterSet deployment, the server instance is rejoined to the cluster and provisioned with the data for the InnoDB ClusterSet. The ClusterSet replication channel is set up on the instance, and the required configuration to operate in an InnoDB ClusterSet deployment is applied.

  • Remove a server instance from the cluster, using the cluster.removeInstance() command. Specify the host name and port number of the server instance that is to be removed. For details of this operation, see Removing Instances from an InnoDB Cluster. A force option is available, but this should only be used as a last resort.

    When you use this command with a member server in an InnoDB ClusterSet deployment, MySQL Shell resets all configuration that was applied for InnoDB ClusterSet and resets the ClusterSet replication channel settings.

  • Change the primary of the cluster to another member server, using the cluster.setPrimaryInstance(instance) command. Changing the primary allows you to carry out maintenance and upgrades on the current primary server, or to select a primary if Group Replication's own election process does not automatically elect the primary server that you want.

    Specify the host name and port number of the server instance that is to be the primary. From MySQL Shell 8.0.29, you can use the runningTransactionsTimeout option to specify a timeout between 0 and 3600 seconds for transactions that are running when you use the function, which also stops new incoming transactions. There is no default setting for the timeout, so if you do not set it, there is no upper limit to the wait time for the operation, and new transactions can start during that time.

    When you use this command with a member server in an InnoDB ClusterSet deployment, MySQL Shell stops the ClusterSet replication channel on the server beforehand, and restarts it afterwards. Also, if the cluster is a replica cluster, MySQL Shell keeps the primary as read-only, rather than making it read-write as would normally be the case with the primary of an InnoDB Cluster.

  • Restore a cluster that has lost quorum by forcing quorum with the remaining instances, using the cluster.forceQuorumUsingPartitionOf(instance) command. Specify the host name and port number of an online server instance with the correct metadata. The operation makes the cluster consist of this and the other reachable instances, and excludes the partitioned instances. This operation can create a split-brain scenario, so it should be considered a last resort. For details of this operation, see Restoring a Cluster from Quorum Loss.

    When you use this command with a member server in an InnoDB ClusterSet deployment, MySQL Shell checks whether the target cluster is still a valid part of the ClusterSet, and warns you if it has been invalidated. It also automatically restarts the ClusterSet replication channel afterwards. If the cluster is a replica cluster, MySQL Shell keeps the primary as read-only, rather than making it read-write as would normally be the case with the primary of an InnoDB Cluster.

  • Reboot a cluster that is completely offline, using the dba.rebootClusterFromCompleteOutage() command. For details of this operation, see Rebooting a Cluster from a Major Outage.

    When you use this command with a member server in an InnoDB ClusterSet deployment, MySQL Shell checks whether the target cluster is still a valid part of the ClusterSet, and warns you if it has been invalidated.

    Important

    If the target cluster has been invalidated, do not use the rejoinInstances or removeInstances option on the dba.rebootClusterFromCompleteOutage() command. These options create extra transactions on the member servers which prevent the cluster from rejoining the InnoDB ClusterSet deployment.

    If the cluster was not invalidated, MySQL Shell rejoins it to the InnoDB ClusterSet deployment immediately after the reboot. If the cluster was invalidated, you must use a clusterSet.rejoinCluster() operation to rejoin it to the InnoDB ClusterSet deployment. For instructions to do that, see Section 8.9.5, “Rejoining a Cluster to an InnoDB ClusterSet”.

    MySQL Shell also automatically restarts the ClusterSet replication channel after this operation. If the cluster is a replica cluster, MySQL Shell keeps the primary as read-only, rather than making it read-write as would normally be the case with the primary of an InnoDB Cluster.

You cannot dissolve an InnoDB Cluster that is currently part of an InnoDB ClusterSet deployment. If you do want to dissolve and discard the InnoDB Cluster, you must remove it from the InnoDB ClusterSet as described in Section 8.9.4, “Removing a Cluster from an InnoDB ClusterSet”.