Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space ML1 and version 9.2


If the Slave is already running, this command has no effect. To start any Slaves that are configured on this cluster and not already running, issue the following command. To load-balance replication traffic, Slaves are started in a round-robin fashion across the nodes in the cluster which means that the slaves are not consistently bound to one specific node.  This doesn't have an impact to replication as the slave is configured to communicate to a specific master host, but replication errors are logged on the node that the slave process is running from.


To stop a specified Slave, issue the following command:


  • Inserting error codes into system.mysql_slave_skip_errors
  • Setting the slave_exec_mode global variable
Inserting error codes into system.mysql_slave_skip_errors


MySQL row-based replication specifies the expected (pre-update) contents of each row to be updated or deleted. In case the row specified does not exactly match the row present on ClustrixDB, there are two modes of operation, determined by the setting of the global variable slave_exec_mode:

  • STRICT: In this mode, as long as the PRIMARY KEY or first UNIQUE key of the row matches, the update/delete is applied. This is the default setting, and also matches MySQL's default behavior.
  • EXACT: In this mode, if the row specified does not exactly match (for all columns) a row present in the table, the slave will error (with "Row Not Found"), and stop. Note that this mode is unique to ClustrixDB.


slave> CHANGE SLAVE 'slave_name' to nodeid=nodeid; 

Replicating from MariaDB

ClustrixDB does not provide support for MariaDB GTIDs, but can replicate from MariaDB 10.2+ using its support for old-style replication. The normal syntax for creating a replication slave can be used to set ClustrixDB up as a replication slave.  

Replicating from MySQL 5.7