Can master-slave become master-master?

[Sanjay Singh]

Hi,

Has anyone experienced Master-Slave becoming Master-Master (open source version)? If yes, how do we avoid this issue?

-Sanjay

[Greg Andrews]

(Disclosure:  I'm not a Redis Labs employee or Redis developer.  I'm just a Redis user who's been reading and posting to this forum for a number of years)

Replication of data is performed through a TCP connection between the master and the replica (slave).  The things that can interrupt TCP connectivity between the master and the replica can interfere with the data replication.  As the documentation at redis.io mentions, when connectivity is broken, a replica will keep trying to re-establish replication with its master.

So how would a replica turn into a master (i.e. a stand-alone instance accepting write commands and not trying to re-establish replication with its master)?  I can see a couple of ways:

1. The replica process was re-started and the replication config was not part of the redis.conf file configuration.  The restart causes the Redis program to forget it was a replica, and it's not reminded by the redis.conf file.
2. The replica is being managed by Redis Sentinel, and the Sentinel agents decided the original master is down, so the replica must take over the role of master.  You can end up with more than one Redis configured to be master when a "network partition" incident occurs.  This is when parts of the network are unable to communicate with other parts.  If each part has Sentinel agents and one of the Redis instances, the Sentinels in each isolated part of the network believe the other part is gone and the local Redis must fulfill the role of master.  After the partition is removed (connectivity between the parts of the network is re-established), the Sentinel agents may be able to re-select the master and demote the other machine back to replica/slave. (but under some circumstances they may be unable)

My own guess, based on the simplicity of your problem description, is that #1 was probably the cause of the change you experienced.  The ways to avoid the issue depend on the causes.  The only generic advice I can give is to perform testing of the different ways in which network connectivity between two Redis processes can be interrupted (which includes servers crashing, restarting, etc.).  The tests will reveal the Redis behavior and symptoms and you can build configuration to avoid some of the causes, perhaps employ management (like Sentinel) to avoid other causes, and then handle the rest with early trouble warnings from monitoring.