Rechercher dans le manuel MySQL
21.6.1 InnoDB ReplicaSet Introduction
The AdminAPI includes support for InnoDB ReplicaSet, that
enables you to administer a set of MySQL instances running
asynchronous GTID-based replication in a similar way to
InnoDB cluster. An InnoDB ReplicaSet consists of a single
primary and multiple secondaries (traditionally referred to as
the MySQL replication master and slaves). You administer your
ReplicaSets using a ReplicaSet object and the
AdminAPI operations, for example to check the status of the
InnoDB ReplicaSet, and manually failover to a new primary in
the event of a failure. Similar to InnoDB cluster, MySQL Router
supports bootstrapping against InnoDB ReplicaSet, which means
you can automatically configure MySQL Router to use your
InnoDB ReplicaSet without having to manually configure it.
This makes InnoDB ReplicaSet a quick and easy way to get MySQL
replication and MySQL Router up and running, making it well suited
to scaling out reads, and provides manual failover capabilities
in use cases that do not require the high availability offered
by InnoDB cluster.
In addition to deploying an InnoDB ReplicaSet using AdminAPI, you can adopt an existing replication setup. AdminAPI configures the InnoDB ReplicaSet based on the topology of the replication setup. Once the replication setup has been adopted, you administer it in the same way as an InnoDB ReplicaSet deployed from scratch. This enables you to take advantage of AdminAPI and MySQL Router without the need to create a new ReplicaSet. For more information see Section 21.6.4, “Adopting an Existing Replication Set Up”.
InnoDB ReplicaSet Limitations
An InnoDB ReplicaSet has several limitations compared to a InnoDB cluster and thus, it is recommended that you deploy InnoDB cluster wherever possible. Generally, a InnoDB ReplicaSet on its own does not provide high availability. Among the limitations of InnoDB ReplicaSet are:
No automatic failover. In events where the primary becomes unavailable, a failover needs to be triggered manually using AdminAPI before any changes are possible again. However, secondary instances remain available for reads.
No protection from partial data loss due to an unexpected halt or unavailability. Transactions that have not yet been applied by the time of the halt could become lost.
No protection against inconsistencies after a crash or unavailability. If a failover promotes a secondary while the former primary is still available (for example due to a network partition), inconsistencies could be introduced because of the split-brain.
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-replicasets-introduction.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.
