7.4.6.1 Working with a Cluster that uses MySQL Clone

An InnoDB Cluster that uses MySQL Clone provides the following additional behavior.

dba.createCluster() and MySQL Clone

From version 8.0.17, by default when a new cluster is created on an instance where the MySQL Clone plugin is available then 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().

Cluster.addInstance(instance) and MySQL Clone

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 7.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) behaves depends on the following factors:

• 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.

  Warning

  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(). The 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:

Note

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.

Cluster.checkInstanceState() and MySQL Clone

When the Cluster.checkInstanceState() operation is run to verify an instance against a cluster that is using MySQL Clone, if the instance does not have the binary logs, for example because they were purged but Clone is available and not disabled (disableClone is false) the operation provides a warning that the Clone can be used. For example:

The cluster transactions cannot be recovered on the instance, however,
Clone is available and can be used when adding it to a cluster.

{
"reason": "all_purged",
"state": "warning"
}

Similarly, on an instance where Clone is either not available or has been disabled and the binary logs are not available, for example because they were purged, then the output includes:

The cluster transactions cannot be recovered on the instance.

{
"reason": "all_purged",
"state": "warning"
}

dba.checkInstanceConfiguration() and MySQL Clone

When the dba.checkInstanceConfiguration() operation is run against an instance that has MySQL Clone available but it is disabled, a warning is displayed.