Documentation Home
MySQL 8.0 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 48.1Mb
PDF (A4) - 48.1Mb
PDF (RPM) - 43.7Mb
HTML Download (TGZ) - 11.1Mb
HTML Download (Zip) - 11.1Mb
HTML Download (RPM) - 9.6Mb
Man Pages (TGZ) - 239.7Kb
Man Pages (Zip) - 343.4Kb
Info (Gzip) - 4.4Mb
Info (Zip) - 4.4Mb
Excerpts from this Manual

MySQL 8.0 Reference Manual  /  ...  /  Setting the Replication Slave Configuration Setting the Replication Slave Configuration

Each replication slave must have a unique server ID, as specified by the server_id system variable. If you are setting up multiple slaves, each one must have a unique server_id value that differs from that of the master and from any of the other slaves. If the slave's server ID is not already set, or the current value conflicts with the value that you have chosen for the master server or another slave, you must change it.

The default server_id value is 1. You can change the server_id value dynamically by issuing a statement like this:

SET GLOBAL server_id = 21;

Note that a value of 0 for the server ID prevents a replication slave from connecting to a master. If that server ID value (which was the default in earlier releases) was set previously, you must restart the server to initialize the replication slave with your new nonzero server ID. Otherwise, a server restart is not needed when you change the server ID, unless you make other configuration changes that require it. For example, if binary logging was disabled on the server and you want it enabled for your slave, a server restart is required to enable this.

If you are shutting down the slave server, you can edit the [mysqld] section of the configuration file to specify a unique server ID. For example:


Binary logging is enabled by default on all servers. A slave is not required to have binary logging enabled for replication to take place. However, binary logging on a slave means that the slave's binary log can be used for data backups and crash recovery. Slaves that have binary logging enabled can also be used as part of a more complex replication topology. For example, you might want to set up replication servers using this chained arrangement:

A -> B -> C

Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to work, B must be both a master and a slave. Updates received from A must be logged by B to its binary log, in order to be passed on to C. In addition to binary logging, this replication topology requires the log_slave_updates system variable to be enabled. With slave updates enabled, the slave writes updates that are received from a master server and performed by the slave's SQL thread to the slave's own binary log. The log_slave_updates system variable is enabled by default.

If you need to disable binary logging or slave update logging on a slave server, you can do this by specifying the --skip-log-bin and --log-slave-updates=OFF options for the slave. If you decide to re-enable these features on the server, remove the relevant options and restart the server.