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
server_id value 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
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
variable is enabled by default.