MySQL Shell 8.4
If you make configuration changes to a cluster outside of the
AdminAPI commands, for example by changing an instance's
configuration manually to resolve configuration issues or after
the loss of an instance, you need to update the InnoDB Cluster
metadata so that it matches the current configuration of
instances. In these cases, use the
operation, which enables you to update the InnoDB Cluster
metadata either manually or using an interactive wizard. The
Cluster
.rescan()
operation can detect new active instances that are not
registered in the metadata and add them, or obsolete instances
(no longer active) still registered in the metadata, and remove
them. You can automatically update the metadata depending on the
instances found by the command, or you can specify a list of
instance addresses to either add to the metadata or remove from
the metadata. You can also update the topology mode stored in
the metadata, for example after changing from single-primary
mode to multi-primary mode outside of AdminAPI.
Cluster
.rescan()
group_replication_transaction_size_limit
is set to the maximum value in Replica Clusters. The original
value is stored in the metadata schema and is restored by
in the event of a switchover or failover.
Cluster
.rescan()
The syntax of the command is
.
The Cluster
.rescan([options])options
dictionary supports the
following:
addInstances
: list with the connection
data of the new active instances to add to the metadata, or
“auto” to automatically add missing instances
to the metadata. The value “auto” is
case-insensitive.
Instances specified in the list are added to the metadata, without prompting for confirmation
In interactive mode, you are prompted to confirm the
addition of newly discovered instances that are not
included in the addInstances
option
In non-interactive mode, newly discovered instances that
are not included in the addInstances
option are reported in the output, but you are not
prompted to add them
removeInstances
: list with the connection
data of the obsolete instances to remove from the metadata,
or “auto” to automatically remove obsolete
instances from the metadata.
Instances specified in the list are removed from the metadata, without prompting for confirmation
In interactive mode, you are prompted to confirm the
removal of obsolete instances that are not included in
the removeInstances
option
In non-interactive mode, obsolete instances that are not
included in the removeInstances
option are reported in the output but you are not
prompted to remove them
updateViewChangeUuid
: Boolean value used
to indicate if a value should be generated and set for the
group_replication_view_change_uuid
system variable on the cluster instances.
This is not required for Clusters running MySQL Server 8.3.0 or higher.
This system variable supplies an alternative UUID for view
change events generated by the group. For MySQL Server
instances at release 8.0.27 and above, for an
InnoDB Cluster that is part of an InnoDB ClusterSet, the
group_replication_view_change_uuid
system variable is required and must be set to the same
value on all member servers in the cluster. An
InnoDB Cluster that is created using the
dba.createCluster()
command gets a value
generated and set for the system variable on all the member
servers. An InnoDB Cluster created before MySQL Shell
8.0.27 might not have the system variable set, but the
InnoDB ClusterSet creation process checks for this and
fails with a warning if it is absent.
By default, updateViewChangeUuid
is set
to false
, and if the system variable is
not found or does not match on any of the instances, a
warning message is returned to let you know you must set a
value for the system variable and reboot the
InnoDB Cluster. If you set
updateViewChangeUuid
to
true
, the rescan operation generates and
sets a value for
group_replication_view_change_uuid
on all the member servers, following which you must reboot
the cluster to implement the changes. The
command automatically generates and sets the system variable
value in the same way as if Cluster
.rescan()true
was set,
with a cluster reboot required afterwards to implement the
changes. When you have rebooted the cluster, you can retry
the InnoDB ClusterSet creation process.
upgradeCommProtocol
: Boolean value used
to indicate if the Group Replication communication protocol
version should be upgraded (true) or not (false) to the
version supported by the instance in the cluster that is at
the lowest MySQL release. By default, the communication
protocol version is not upgraded (false). AdminAPI
operations that cause a topology change return a message if
the communication protocol version can be upgraded, and you
can use this option to carry out the upgrade at a suitable
time. It is advisable to upgrade to the highest available
version of the Group Replication communication protocol to
support the latest features, such as message fragmentation
for large transactions. For more information, see
Setting a Group's Communication Protocol Version.
If the value is true
then the Group
Replication communication protocol version is upgraded
to the version supported by the instance in the cluster
that is at the lowest MySQL release.
If the value is false
then the Group
Replication communication protocol version is not
upgraded.