Here is something interesting about MySQL Replication:
When it comes to Master/Slave Replication
- Master DB Server must have server-id defined in my.cnf
- Master DB must have binary logging enabled (define log-bin)
- Slave DB Server is not required to defined server-id in my.cnf
If, all of a sudden, you find yourself having to reverse the DB Server's roles (making the old Slave the new Master, and making the old Master the Slave), the requirement to define server-id and log-bin must also hold true.
BTW a DB Server without server-id being set has a default value of 1. If server-id was define as 1 on the Master and the Slave did not have server-id defined, the Slave would also have had server-id being equal to 1. Activating the Slave as the new Master with any trace remnants of the old replication setup wmay have attempted to complete the processing of any remaining SQL entries in the relay logs. Those entries carried the server-id of 1. Bringing those entries over to a new machine without server-id define would have caused mysqld to complain about processing relay logs entries with the same server-id.
Perhaps, someone forgot to define the server-id on the Slave before making it the new Master and trying to engage Replication afterwards. Adding server-id to my.cnf and a quick restart of mysqld would have eliminated this weird situation without giving it a second thought.
