If an instance leaves the cluster, for example because it lost
connection, and for some reason it could not automatically
rejoin the cluster, it might be necessary to rejoin it to the
cluster at a later stage. To rejoin an instance to a cluster
issue
.
Cluster
.rejoinInstance(instance
)
If the instance has
super_read_only=ON
then you
might need to confirm that AdminAPI can set
super_read_only=OFF
. See
Instance Configuration in Super Read-only Mode for more
information.
In the case where an instance has not had its configuration
persisted (see Section 6.2.3, “Persisting Settings”),
upon restart the instance does not rejoin the cluster
automatically. The solution is to issue
cluster.rejoinInstance()
so that the instance
is added to the cluster again and ensure the changes are
persisted. Once the InnoDB Cluster configuration is persisted
to the instance's option file it rejoins the cluster
automatically.
If you are rejoining an instance which has changed in some way
then you might have to modify the instance to make the rejoin
process work correctly. For example, when you restore a MySQL Enterprise Backup
backup, the server_uuid
changes. Attempting to rejoin such an instance fails because
InnoDB Cluster instances are identified by the
server_uuid
variable. In such a
situation, information about the instance's old
server_uuid
must be
removed from the InnoDB Cluster metadata and then a
must be executed to add the instance to the metadata using the
new Cluster
.rescan()server_uuid
. For example:
cluster.removeInstance("root@instanceWithOldUUID:3306", {force: true})
cluster.rescan()
In this case you must pass the force
option
to the
method because the instance is unreachable from the cluster's
perspective and we want to remove it from the InnoDB Cluster
metadata anyway.
Cluster
.removeInstance()
rejoinInstance()
also checks the
communication stack used by the instance and ensures it is
supported by the cluster. If the cluster supports the
communication stack, rejoinInstance()
adds
the instance to the cluster.