Description:
As of now, there is no way for a slave to have multiple masters in MySQL. We have a need for more than just a simple voting algorithm to pick a master to replication with. This is because all of our clients connect to local servers on their hard drives during the day to add their changes, and then dial-in to SEND AND RECEIVE changes from/to ONE SERVER(which is both Master and Slave). As I see it, the fundemental replication theory(Master/Slave) for MySQL will work great for this.
The problem is that MySQL's replication connection theory needs some serious thought to work in this situation. In this case, the (above mentioned "ONE SERVER")slave needs to keep track of all the Masters that it has replicated with and where in the binary log it has last replicated with that specific Master. That "ONE SERVER" slave also has the duty of trying to replicate with EACH OF THE MASTERS. NOT JUST THE FIRST MASTER IT CAN FIND. THIS IS IMPORTANT BECAUSE EACH MASTER HAS IT'S OWN SET OF DATA THAT NEEDS TO BE ADDED TO THE SLAVE.
This could cause 2 side effects:
1. The database administrator must be EXTREMELY careful which Masters a slave can replicate with as not to re-aply previously applied updates.
AND
2. Database developers must be EXTREMELY careful not to make the order important for changes to be applied. (The usual problem with two-way replication except on a much more dangerous scale.)
What I propose is that MySQL could give a Slave database multiple connection options since MySQL's newly proposed "master voting algorithm" simply won't work for this "slave to multiple-master replication" configuration.
How to repeat:
Not a bug
