Sending Replication Events to Other Slaves
The log_slave_updates option lets you use a slave as a master of other slaves. It
instructs MySQL to write the events the slave SQL thread executes into its own
binary log, which its own slaves can then retrieve and execute.
Unless you’ve taken care to give each server a unique server ID, configuring a slave in
this manner can cause subtle errors and may even cause replication to complain and stop.
MySQL prevents an infinite loop in replication. When the slave SQL thread reads the relay log, it discards any event whose server ID matches its own. This breaks infinite loops in replication.
Preventing infinite loops is important for some of the more useful replication
topologies, such as master-master replication.
Replication Topologies
basic rules:
• A MySQL slave instance can have only one master.
• Every slave must have a unique server ID.
• A master can have many slaves (or, correspondingly, a slave can have many siblings).
• A slave can propagate changes from its master, and be the master of other slaves, if you enable log_slave_updates.
If you set up a master-master active-active configuration carefully, perhaps with wellpartitioned data and privileges, you can avoid some of these problems.* However, it’s
hard to do well, and there’s usually a better way to achieve what you need.
MySQL Does Not Support Multimaster Replication
沒有留言:
張貼留言