Rechercher dans le manuel MySQL
22.6 NDB Cluster Replication
[+/-]
- 22.6.1 NDB Cluster Replication: Abbreviations and Symbols
- 22.6.2 General Requirements for NDB Cluster Replication
- 22.6.3 Known Issues in NDB Cluster Replication
- 22.6.4 NDB Cluster Replication Schema and Tables
- 22.6.5 Preparing the NDB Cluster for Replication
- 22.6.6 Starting NDB Cluster Replication (Single Replication Channel)
- 22.6.7 Using Two Replication Channels for NDB Cluster Replication
- 22.6.8 Implementing Failover with NDB Cluster Replication
- 22.6.9 NDB Cluster Backups With NDB Cluster Replication
- 22.6.10 NDB Cluster Replication: Multi-Master and Circular Replication
- 22.6.11 NDB Cluster Replication Conflict Resolution
NDB Cluster supports asynchronous replication, more usually referred to simply as “replication”. This section explains how to set up and manage a configuration in which one group of computers operating as an NDB Cluster replicates to a second computer or group of computers. We assume some familiarity on the part of the reader with standard MySQL replication as discussed elsewhere in this Manual. (See Chapter 17, Replication).
NDB Cluster does not support replication using GTIDs;
semisynchronous replication is also not supported by the
NDB
storage engine.
Normal (non-clustered) replication involves a “master”
server and a “slave” server, the master being the
source of the operations and data to be replicated and the slave
being the recipient of these. In NDB Cluster, replication is
conceptually very similar but can be more complex in practice, as it
may be extended to cover a number of different configurations
including replicating between two complete clusters. Although an NDB
Cluster itself depends on the NDB
storage engine for clustering functionality, it is not necessary to
use NDB
as the storage engine for the
slave's copies of the replicated tables (see
Replication from NDB to other storage engines).
However, for maximum availability, it is possible (and preferable)
to replicate from one NDB Cluster to another, and it is this
scenario that we discuss, as shown in the following figure:
In this scenario, the replication process is one in which successive
states of a master cluster are logged and saved to a slave cluster.
This process is accomplished by a special thread known as the NDB
binary log injector thread, which runs on each MySQL server and
produces a binary log (binlog
). This thread
ensures that all changes in the cluster producing the binary
log—and not just those changes that are effected through the
MySQL Server—are inserted into the binary log with the correct
serialization order. We refer to the MySQL replication master and
replication slave servers as replication servers or replication
nodes, and the data flow or line of communication between them as a
replication channel.
For information about performing point-in-time recovery with NDB Cluster and NDB Cluster Replication, see Section 22.6.9.2, “Point-In-Time Recovery Using NDB Cluster Replication”.
NDB API _slave status variables.
NDB API counters can provide enhanced monitoring capabilities on
NDB Cluster replication slaves. These are implemented as NDB
statistics _slave
status variables, as seen in
the output of SHOW STATUS
, or in
the results of queries against the
SESSION_STATUS
or
GLOBAL_STATUS
table in a mysql client session connected to a
MySQL Server that is acting as a slave in NDB Cluster Replication.
By comparing the values of these status variables before and after
the execution of statements affecting replicated
NDB
tables, you can observe the
corresponding actions taken on the NDB API level by the slave,
which can be useful when monitoring or troubleshooting NDB Cluster
Replication. Section 22.5.17, “NDB API Statistics Counters and Variables”,
provides additional information.
Replication from NDB to non-NDB tables.
It is possible to replicate NDB
tables from an NDB Cluster acting as the master to tables using
other MySQL storage engines such as
InnoDB
or
MyISAM
on a slave
mysqld. This is subject to a number of
conditions; see
Replication from NDB to other storage engines, and
Replication from NDB to a nontransactional storage engine,
for more information.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-mysql-cluster-replication.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.