17.1.2.2 Setting the Replication Slave Configuration

Each replication slave must have a unique server ID. If this has not already been done, this part of slave setup requires a server restart.

If the slave server ID is not already set, or the current value conflicts with the value that you have chosen for the master server, shut down the slave server and edit the [mysqld] section of the configuration file to specify a unique server ID. For example:

[mysqld]
server-id=2

After making the changes, restart the server.

If you are setting up multiple slaves, each one must have a unique nonzero server-id value that differs from that of the master and from any of the other slaves.

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 option to be enabled. With this option, 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 option 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 --skip-log-slave-updates options for the slave.