If you are writing a replication test case, the test case file should begin with this command:
To switch between the master and slave, use these commands:
connection master; connection slave;
If you need to do something on an alternative connection, you can
connection master1; for the master and
connection slave1; for the slave.
To run the master with additional options for your test case, put
them in command-line format in
When a file named
exists, mysql-test-run.pl examines it for extra
options that the server needs to be run with when executing the
test_name test case. If no server has
yet been started or the current server is running with different
options, mysql-test-run.pl restarts the server
with the new options.
For the slave, similar principles apply, but you should list
additional options in
Several include files are available for use in tests that enable
better control over the behavior of slave server I/O and SQL
threads. The files are located in the
directory and have names of the form
wait_for_slave_*.inc. By using these files,
you can help make replication tests more stable because it will be
more likely that test failures are due to replication failures,
not due to problems with the tests themselves.
The slave-control include files address the issue that it is not
always sufficient to use a
START SLAVE or
STOP SLAVE statement by itself: When the
statement returns, the slave may not have reached the desired
operational state. For example, with
SLAVE, the following considerations apply:
It is not necessary to wait for the SQL thread after
START SLAVE SQL_THREADbecause the thread will have started by the time statement returns.
By contrast, it is necessary to wait for the I/O thread after
START SLAVE IO_THREADbecause although the thread will have started when the statement returns, it may not yet have established the connection to the master.
To verify that a slave has reached the desired state, combine the
START SLAVE or
SLAVE with an appropriate “wait” include
file. The file contains code that waits until the state has been
reached or a timeout occurs. For example, to verify that both
slave threads have started, do this:
START SLAVE; --source include/wait_for_slave_to_start.inc
Similarly, to stop both slave threads, do this:
STOP SLAVE; --source include/wait_for_slave_to_stop.inc
The following list describes the include files that are available for slave control:
wait_for_slave_to_start.inc(available as of 5.0.44, 5.1.20, 6.0.3)
Waits for both slave threads (I/O and SQL) to start. Should be preceded by a
wait_for_slave_to_stop.inc(available as of 5.0.44, 5.1.20, 6.0.3)
Waits for both slave threads (I/O and SQL) to stop. Should be preceded by a
wait_for_slave_sql_to_stop.inc(available as of 5.0.44, 5.1.20, 6.0.3)
Waits for the slave SQL thread to stop. Should be preceded by a
STOP SLAVE SQL_THREADstatement.
wait_for_slave_io_to_stop.inc(availaable as of 5.0.44, 5.1.20, 6.0.3)
Waits for the slave I/O thread to stop. Should be preceded by a
STOP SLAVE IO_THREADstatement.
wait_for_slave_param.inc(available as of 5.0.46, 5.1.20, 6.0.3)
SHOW SLAVE STATUSoutput contains a given value or a timeout occurs. Before including the file, you should set the
$slave_paramvariable to the column name to look for in
SHOW SLAVE STATUSoutput, and
$slave_param_valueto the value that you are waiting for the column to have.
let $slave_param= Slave_SQL_Running; let $slave_param_value= No; --source include/slave_wait_slave_param.inc
wait_for_slave_sql_error.inc(available as of 5.1.23, 6.0.4)
Waits until the SQL thread for the current connection has gotten an error or a timeout occurs. Occurrence of an error is determined by waiting for the
SHOW SLAVE STATUSoutput to have a nonzero value.