Version sans cache

Mise en cache désactivé. Réglage défaut pour cette page : actif (code DEF204)
Si l'affichage est trop lent, vous pouvez désactiver le mode utilisateur pour visualiser la version en cache.

Rechercher dans le manuel MySQL

22.6.6 Starting NDB Cluster Replication (Single Replication Channel)

Table des matières

This section outlines the procedure for starting NDB Cluster replication using a single replication channel.

  1. Start the MySQL replication master server by issuing this command: 

    shellM> mysqld --ndbcluster --server-id=id \
        --log-bin &

    In the previous statement, id is this server's unique ID (see Section 22.6.2, “General Requirements for NDB Cluster Replication”). This starts the server's mysqld process with binary logging enabled using the proper logging format.

    Note

    You can also start the master 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 (see Section 22.6.2, “General Requirements for NDB Cluster Replication”).

  2. Start the MySQL replication slave server as shown here: 

    shellS> mysqld --ndbcluster --server-id=id &

    In the command just shown, id is the slave server's unique ID. It is not necessary to enable logging on the replication slave.

    Note

    You should use the --skip-slave-start option with this command or else you should include skip-slave-start in the slave server's my.cnf file, unless you want replication to begin immediately. With the use of this option, the start of replication is delayed until the appropriate START SLAVE statement has been issued, as explained in Step 4 below.

  3. It is necessary to synchronize the slave server with the master server's replication binary log. If binary logging has not previously been running on the master, run the following statement on the slave:

    1. mysqlS> CHANGE MASTER TO
    2.      -> MASTER_LOG_FILE='',
    3.      -> MASTER_LOG_POS=4;

    This instructs the slave to begin reading the master's binary log from the log's starting point. Otherwise—that is, if you are loading data from the master using a backup—see Section 22.6.8, “Implementing Failover with NDB Cluster Replication”, for information on how to obtain the correct values to use for MASTER_LOG_FILE and MASTER_LOG_POS in such cases.

  4. Finally, you must instruct the slave to begin applying replication by issuing this command from the mysql client on the replication slave:

    1. mysqlS> START SLAVE;

    This also initiates the transmission of replication data from the master to the slave.

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 in Section 22.6.7, “Using Two Replication Channels for NDB Cluster Replication”.

It is also possible to improve cluster replication performance by enabling batched updates. This can be accomplished by setting the slave_allow_batching system variable on the slave mysqld processes. Normally, updates are applied as soon as they are received. However, the use of batching causes updates to be applied in 32 KB batches, which can result in higher throughput and less CPU usage, particularly where individual updates are relatively small.

Note

Slave 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:

  1. SET GLOBAL slave_allow_batching = 1;
  2. SET GLOBAL slave_allow_batching = ON;

If a particular batch causes problems (such as a statement whose effects do not appear to be replicated correctly), slave batching can be deactivated using either of the following statements:

  1. SET GLOBAL slave_allow_batching = 0;
  2. SET GLOBAL slave_allow_batching = OFF;

You can check whether slave batching is currently being used by means of an appropriate SHOW VARIABLES statement, like this one:

  1. mysql> SHOW VARIABLES LIKE 'slave%';
  2. +---------------------------+-------+
  3. | Variable_name             | Value |
  4. +---------------------------+-------+
  5. | slave_allow_batching      | ON    |
  6. | slave_compressed_protocol | OFF   |
  7. | slave_load_tmpdir         | /tmp  |
  8. | slave_net_timeout         | 3600  |
  9. | slave_skip_errors         | OFF   |
  10. | slave_transaction_retries | 10    |
  11. +---------------------------+-------+
  12. 6 rows in set (0.00 sec)

Rechercher dans le manuel MySQL

Traduction non disponible

Le manuel MySQL n'est pas encore traduit en français sur l'infobrol. Seule la version anglaise est disponible pour l'instant.

Document créé le 26/06/2006, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/mysql-rf-mysql-cluster-replication-starting.html

L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.

Références

  1. Consulter le document html Langue du document :en Manuel MySQL : https://dev.mysql.com/

Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.

Table des matières Haut