Documentation Home
MySQL 8.0 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 45.6Mb
PDF (A4) - 45.7Mb
PDF (RPM) - 41.1Mb
HTML Download (TGZ) - 10.5Mb
HTML Download (Zip) - 10.6Mb
HTML Download (RPM) - 9.1Mb
Man Pages (TGZ) - 209.4Kb
Man Pages (Zip) - 311.6Kb
Info (Gzip) - 4.1Mb
Info (Zip) - 4.1Mb
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. 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:


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.

User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
  Posted by Richard Lynch on November 4, 2011
WARNING: My fail-over experience is very tiny, despite using MySQL for dozens of sites with zero budget for decades...

Maybe I'm missing something, but unless you set the log-bin=mysql-bin to the SAME value as you set in the Master Setup[1] instructions, your slave isn't really ready to become the new master when you fail-over.

At least, that's what my one experiment so far has shown.

And when I changed the log-bin on the slave to match and re-started, any queries that happened in between didn't make it back to the former-master/new-slave when I started that back up.

So I believe these Master Setup and Slave Setup should both have log-bin=xyz values that match in these docs, or leave them out and use the defaults.

But don't document one and not the other, making readers think they can change it only on the Master setup.

Please forgive me if I'm just completely off-base. Will experiment more and try to give a Beginner's Guide in a blog.

It seems like there are so many options and scenarios being documented here, that the baseline "HowTo" is obscured by the "gothcas" and "edge cases" and "if this, then that" docs...

I'm not unwilling to help, once I actually plow through it for myself :-)


  Posted by Stephen Wylie on January 25, 2012
You should also put


into your my.cnf on the slave, so that the 'show slave hosts' command will work on the master.