Rechercher dans le manuel MySQL

21.2.5.2 Working with a Cluster that uses MySQL Clone

Contents

A InnoDB cluster that uses MySQL Clone provides the following additional behavior.

dba.createCluster() and MySQL Clone

By default, if the Section 21.2.5.1, “Prerequisites for using MySQL Clone with InnoDB cluster” are satisfied, 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 false 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() and MySQL Clone

A cluster using MySQL Clone follows the behavior documented at Adding Instances to a Cluster, with the addition of a possible choice of how to transfer the data required to synchronize the instance with the cluster. How Cluster.addInstance() behaves depends on the following factors:

  • 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 already had data in it before binary logs and GTIDs were enabled. Therefore in interactive mode, you have to confirm you want to use MySQL Clone and delete any data on the receiver. To override this behavior, set the gtidSetIsComplete Boolean option to true to assume it is appropriate to add an instance with an empty GTID_EXECUTED GTID set, bypassing the prompt to ask for confirmation.

  • whether MySQL Clone is supported. See Section 21.2.5.1, “Prerequisites for using MySQL Clone with InnoDB cluster”.

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 the cluster selects how to transfer the transactions processed by the cluster to the new instance. In other words the cluster chooses between using MySQL Clone and incremental recovery based on the best approach and what the server supports. 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 receiver instance with a snapshot from an existing 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 transfer all transactions processed by the cluster to the receiver 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 provided with the prompt, and the recommended option is to proceed with incremental recovery.

  • 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 must use 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 the prompt shows: 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). 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.


Find a PHP function

Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-mysql-innodb-cluster-working-with-clone.html

The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.

References

  1. View the html document Language of the document:en Manuel MySQL : https://dev.mysql.com/

These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.

Contents Haut