PDF (A4) - 43.4Mb
Man Pages (TGZ) - 297.2Kb
Man Pages (Zip) - 402.4Kb
Info (Gzip) - 4.3Mb
Info (Zip) - 4.3Mb
MySQL Globalization
MySQL Information Schema
MySQL Installation Guide
Security in MySQL
Starting and Stopping MySQL
MySQL and Linux/Unix
MySQL and Windows
MySQL and macOS
MySQL and Solaris
Building MySQL from Source
MySQL Restrictions and Limitations
MySQL Partitioning
MySQL Tutorial
MySQL Performance Schema
MySQL Replication
Using the MySQL Yum Repository
MySQL NDB Cluster 8.0
This section outlines the procedure for starting NDB Cluster replication using a single replication channel.
Start the MySQL replication source server by issuing this command, where
idis this server's unique ID (seeSection 25.7.2, “General Requirements for NDB Cluster Replication”):shellS> mysqld --ndbcluster --server-id=id \ --log-bin --ndb-log-bin &This starts the server'smysqld process with binary logging enabled using the proper logging format. It is also necessary in NDB 8.0 to enable logging of updates to
NDBtables explicitly, using the--ndb-log-binoption; this is a change from previous versions of NDB Cluster, in which this option was enabled by default.NoteYou can also start the source with
--binlog-format=MIXED, in which case row-based replication is used automatically when replicating between clusters. Statement-based binary logging is not supported for NDB Cluster Replication (seeSection 25.7.2, “General Requirements for NDB Cluster Replication”).Start the MySQL replica server as shown here:
shellR> mysqld --ndbcluster --server-id=id &In the command just shown,
idis the replica server's unique ID. It is not necessary to enable logging on the replica.NoteUnless you want replication to begin immediately, delay the start of the replication threads until the appropriate
START REPLICAstatement has been issued, as explained in Step 4 below. You can do this by starting the replica with the--skip-slave-startoption on the command line, by includingskip-slave-startin the replica'smy.cnffile, or in NDB 8.0.24 and later, by setting theskip_slave_startsystem variable. In NDB 8.0.26 and later, use--skip-replica-startandskip_replica_start.It is necessary to synchronize the replica server with the source server's replication binary log. If binary logging has not previously been running on the source, run the following statement on the replica:
mysqlR> CHANGE MASTER TO -> MASTER_LOG_FILE='', -> MASTER_LOG_POS=4;Beginning with NDB 8.0.23, you can also use the following statement:
mysqlR> CHANGE REPLICATION SOURCE TO -> SOURCE_LOG_FILE='', -> SOURCE_LOG_POS=4;This instructs the replica to begin reading the source server's binary log from the log's starting point. Otherwise—that is, if you are loading data from the source using a backup—seeSection 25.7.8, “Implementing Failover with NDB Cluster Replication”, for information on how to obtain the correct values to use for
SOURCE_LOG_FILE|MASTER_LOG_FILEandSOURCE_LOG_POS|MASTER_LOG_POSin such cases.Finally, instruct the replica to begin applying replication by issuing this command from themysql client on the replica:
mysqlR> START SLAVE;In NDB 8.0.22 and later, you can also use the following statement:
mysqlR> START REPLICA;This also initiates the transmission of data and changes from the source to the replica.
It is also possible to use two replication channels, in a manner similar to the procedure described in the next section; the differences between this and using a single replication channel are covered inSection 25.7.7, “Using Two Replication Channels for NDB Cluster Replication”.
It is also possible to improve cluster replication performance by enablingbatched updates. This can be accomplished by setting the system variablereplica_allow_batching (NDB 8.0.26 and later) orslave_allow_batching (prior to NDB 8.0.26) on the replicas'mysqld processes. Normally, updates are applied as soon as they are received. However, the use of batching causes updates to be applied in batches of 32 KB each; this can result in higher throughput and less CPU usage, particularly where individual updates are relatively small.
Batching works on a per-epoch basis; updates belonging to more than one transaction can be sent as part of the same batch.
All outstanding updates are applied when the end of an epoch is reached, even if the updates total less than 32 KB.
Batching can be turned on and off at runtime. To activate it at runtime, you can use either of these two statements:
SET GLOBAL slave_allow_batching = 1;SET GLOBAL slave_allow_batching = ON;Beginning with NDB 8.0.26, you can (and should) use one of the following statements:
SET GLOBAL replica_allow_batching = 1;SET GLOBAL replica_allow_batching = ON;If a particular batch causes problems (such as a statement whose effects do not appear to be replicated correctly), batching can be deactivated using either of the following statements:
SET GLOBAL slave_allow_batching = 0;SET GLOBAL slave_allow_batching = OFF;Beginning with NDB 8.0.26, you can (and should) use one of the following statements instead:
SET GLOBAL replica_allow_batching = 0;SET GLOBAL replica_allow_batching = OFF; You can check whether batching is currently being used by means of an appropriateSHOW VARIABLES statement, like this one:
mysql> SHOW VARIABLES LIKE 'slave%';In ŃDB 8.0.26 and later, use the following statement:
mysql> SHOW VARIABLES LIKE 'replica%';PDF (A4) - 43.4Mb
Man Pages (TGZ) - 297.2Kb
Man Pages (Zip) - 402.4Kb
Info (Gzip) - 4.3Mb
Info (Zip) - 4.3Mb
MySQL Globalization
MySQL Information Schema
MySQL Installation Guide
Security in MySQL
Starting and Stopping MySQL
MySQL and Linux/Unix
MySQL and Windows
MySQL and macOS
MySQL and Solaris
Building MySQL from Source
MySQL Restrictions and Limitations
MySQL Partitioning
MySQL Tutorial
MySQL Performance Schema
MySQL Replication
Using the MySQL Yum Repository
MySQL NDB Cluster 8.0