Keine Cache-Version
Caching deaktiviert Standardeinstellung für diese Seite:aktiviert (code DEF204)Wenn die Anzeige zu langsam ist, können Sie den Benutzermodus deaktivieren, um die zwischengespeicherte Version anzuzeigen.
Rechercher dans le manuel MySQL
21.2.5.2 Working with a Cluster that uses MySQL Clone
A InnoDB cluster that uses MySQL Clone provides the following additional behavior.
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()
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()
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_PURGEDis 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_EXECUTEDGTID setIdentical: 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_PURGEDandGTID_EXECUTEDvariables 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 thegtidSetIsCompleteBoolean option totrueto assume it is appropriate to add an instance with an emptyGTID_EXECUTEDGTID 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()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_ADMINprivilege. 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'srecoveryMethodoption toclone.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
recoveryMethodoption toincremental.
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 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
disableCloneoption tofalse.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.
When the
Cluster.checkInstanceState()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"
}
Deutsche Übersetzung
Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.
Vielen Dank im Voraus.
Dokument erstellt 26/06/2006, zuletzt geändert 26/10/2018
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/mysql-rf-mysql-innodb-cluster-working-with-clone.html
Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.
Referenzen
Diese Verweise und Links verweisen auf Dokumente, die während des Schreibens dieser Seite konsultiert wurden, oder die zusätzliche Informationen liefern können, aber die Autoren dieser Quellen können nicht für den Inhalt dieser Seite verantwortlich gemacht werden.
Der Autor Diese Website ist allein dafür verantwortlich, wie die verschiedenen Konzepte und Freiheiten, die mit den Nachschlagewerken gemacht werden, hier dargestellt werden. Denken Sie daran, dass Sie mehrere Quellinformationen austauschen müssen, um das Risiko von Fehlern zu reduzieren.
