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
that differs from that of the master and from any of the other
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
A serves as the master for the slave
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
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.