MySQL Shell 9.2
An InnoDB Cluster that uses MySQL Clone provides the following additional behavior.
By default, when a new cluster is created on an instance
where the MySQL Clone plugin is available, it is
automatically installed and the cluster is configured to
support cloning. The InnoDB Cluster recovery accounts are
created with the required
BACKUP_ADMIN privilege.
Set the disableClone Boolean option to
true to disable MySQL Clone for the
cluster. In this case a metadata entry is added for this
configuration and the MySQL Clone plugin is uninstalled if
it is installed. You can set the
disableClone option when you issue
dba.createCluster(), or at any time when
the cluster is running using
Cluster.setOption()
MySQL Clone can be used for a joining
instance if the new instance is
running MySQL 8.0.17 or later, and there is at least one
donor in the cluster (included in the
group_replication_group_seeds
list) running MySQL 8.0.17 or later. A cluster using MySQL
Clone follows the behavior documented at
Section 8.4.4, “Adding Instances to an InnoDB Cluster”, with the addition
of a possible choice of how to transfer the data required to
recover the instance from the cluster. How
Cluster.addInstance(instance)
Whether MySQL Clone is supported.
Whether incremental recovery is possible or not, which
depends on the availability of binary logs. For example,
if a donor instance has all binary logs required
(GTID_PURGED is empty) then
incremental recovery is possible. If no cluster instance
has all binary logs required then incremental recovery
is not possible.
Whether incremental recovery is appropriate or not. Even though incremental recovery might be possible, because it has the potential to clash with data already on the instance, the GTID sets on the donor and receiver are checked to make sure that incremental recovery is appropriate. The following are possible results of the comparison:
New: the receiver has an empty
GTID_EXECUTED GTID set
Identical: the receiver has a GTID set identical to the donor’s GTID set
Recoverable: the receiver has a GTID set that is missing transactions but these can be recovered from the donor
Irrecoverable: the donor has a GTID set that is missing transactions, possibly they have been purged
Diverged: the GTID sets of the donor and receiver have diverged
When the result of the comparison is determined to be Identical or Recoverable, incremental recovery is considered appropriate. When the result of the comparison is determined to be Irrecoverable or Diverged, incremental recovery is not considered appropriate.
For an instance considered New, incremental recovery
cannot be considered appropriate because it is
impossible to determine if the binary logs have been
purged, or even if the GTID_PURGED
and GTID_EXECUTED variables were
reset. Alternatively, it could be that the server had
already processed transactions before binary logs and
GTIDs were enabled. Therefore in interactive mode, you
have to confirm that you want to use incremental
recovery.
The state of the gtidSetIsComplete
option. If you are sure a cluster has been created with
a complete GTID set, and therefore instances with empty
GTID sets can be added to it without extra
confirmations, set the cluster level
gtidSetIsComplete Boolean option to
true.
Setting the gtidSetIsComplete
option to true means that joining
servers are recovered regardless of any data they
contain, use with caution. If you try to add an
instance which has applied transactions you risk data
corruption.
The combination of these factors influence how instances
join the cluster when you issue
Cluster.addInstance()recoveryMethod option is set to
auto by default, which means that in
MySQL Shell's interactive mode, the cluster selects the
best way to recover the instance from the cluster, and the
prompts advise you how to proceed. In other words the
cluster recommends using MySQL Clone or incremental recovery
based on the best approach and what the server supports. If
you are not using interactive mode and are scripting
MySQL Shell, you must set recoveryMethod
to the type of recovery you want to use - either
clone or incremental.
This section explains the different possible scenarios.
When you are using MySQL Shell in interactive mode, the main prompt with all of the possible options for adding the instance is:
Please select a recovery method [C]lone/[I]ncremental recovery/[A]bort (default Clone):
Depending on the factors mentioned, you might not be offered all of these options. The scenarios described later in this section explain which options you are offered. The options offered by this prompt are:
Clone: choose this option to clone
the donor to the instance which you are adding to the
cluster, deleting any transactions the instance
contains. The MySQL Clone plugin is automatically
installed. The InnoDB Cluster recovery accounts are
created with the required
BACKUP_ADMIN
privilege. Assuming you are adding an instance which is
either empty (has not processed any transactions) or
which contains transactions you do not want to retain,
select the Clone option. The cluster then uses MySQL
Clone to completely overwrite the joining instance with
a snapshot from an donor cluster member. To use this
method by default and disable this prompt, set the
cluster's recoveryMethod option to
clone.
Incremental recovery choose this
option to use incremental recovery to recover all
transactions processed by the cluster to the joining
instance using asynchronous replication. Incremental
recovery is appropriate if you are sure all updates ever
processed by the cluster were done with GTIDs enabled,
there are no purged transactions and the new instance
contains the same GTID set as the cluster or a subset of
it. To use this method by default, set the
recoveryMethod option to
incremental.
The combination of factors mentioned influences which of these options is available at the prompt as follows:
If the
group_replication_clone_threshold
system variable has been manually changed outside of
AdminAPI, then the cluster might decide to use Clone
recovery instead of following these scenarios.
In a scenario where
incremental recovery is possible
incremental recovery is not appropriate
Clone is supported
you can choose between any of the options. It is recommended that you use MySQL Clone, the default.
In a scenario where
incremental recovery is possible
incremental recovery is appropriate
you are not provided with the prompt, and incremental recovery is used.
In a scenario where
incremental recovery is possible
incremental recovery is not appropriate
Clone is not supported or is disabled
you cannot use MySQL Clone to add the instance to the cluster. You are provided with the prompt, and the recommended option is to proceed with incremental recovery.
In a scenario where
incremental recovery is not possible
Clone is not supported or is disabled
you cannot add the instance to the cluster and an
ERROR: The target instance must be either
cloned or fully provisioned before it can be added to
the target cluster. Cluster.addInstance: Instance
provisioning required (RuntimeError) is
shown. This could be the result of binary logs being
purged from all cluster instances. It is recommended to
use MySQL Clone, by either upgrading the cluster or
setting the disableClone option to
false.
In a scenario where
incremental recovery is not possible
Clone is supported
you can only use MySQL Clone to add the instance to the cluster. This could be the result of the cluster missing binary logs, for example when they have been purged.
Once you select an option from the prompt, by default the progress of the instance recovering the transactions from the cluster is displayed. This monitoring enables you to check the recovery phase is working and also how long it should take for the instance to join the cluster and come online. To cancel the monitoring of the recovery phase, issue CONTROL+C.