The CONFIG SET command for slaveof is failing because the target Redis instance is already configured as a replica, and you’re trying to set it to a different master.

Here’s what’s actually breaking: When you try to reconfigure a replica to point to a new master using CONFIG SET slaveof <new_master_ip> <new_master_port>, Redis checks if it’s already actively replicating. If it is, and the new master is different from the current one, it refuses to change the configuration on the fly to prevent data corruption or inconsistent states. The system level failure is that the replica’s internal state machine, which manages its connection and synchronization with the current master, is locked into its existing replication relationship and won’t allow a direct switch to a new one without a restart or a specific sequence of commands.

Common Causes and Fixes

  1. Attempting to reconfigure an already replicating slave:

    • Diagnosis: Run redis-cli -p <replica_port> INFO replication. Look for master_host and master_port. If they are populated, the instance is a replica. Then, check if the slaveof command you are trying to run points to a different master than what’s shown in INFO replication.
    • Fix: The safest way to change the master of a replicating slave is to first tell it to stop replicating, then tell it to replicate to the new master.
      redis-cli -p <replica_port> CONFIG SET slaveof "" ""
      redis-cli -p <replica_port> CONFIG SET slaveof <new_master_ip> <new_master_port>
      
    • Why it works: The first CONFIG SET slaveof "" "" command explicitly breaks the existing replication link. Once the replica is no longer connected to its old master, it’s free to establish a new connection to the specified new master.
  2. Network Connectivity Issues to the New Master:

    • Diagnosis: From the machine running the Redis replica, try to ping <new_master_ip>. If that works, try telnet <new_master_ip> <new_master_port>. If telnet fails or times out, there’s a network block.
    • Fix: Ensure that firewalls (on the replica, the master, or in between) are open for TCP traffic on <new_master_port> from the replica’s IP address. If using cloud providers, check security groups or network ACLs.
      # Example: Allow traffic on port 6379 from replica_ip
      ufw allow from <replica_ip> to any port 6379
      
    • Why it works: Redis replication relies on a persistent TCP connection. If the replica cannot reach the new master on the specified port, it cannot initiate or maintain replication.
  3. Incorrect Master IP or Port:

    • Diagnosis: Double-check the IP address and port number you are providing in the CONFIG SET slaveof command against the actual IP and port of the intended master Redis instance. Use redis-cli -p <master_port> INFO server on the master to confirm its port.
    • Fix: Correct the slaveof command with the accurate master IP and port.
      redis-cli -p <replica_port> CONFIG SET slaveof <correct_master_ip> <correct_master_port>
      
    • Why it works: The slaveof directive is a direct instruction pointing to a specific network endpoint. Any deviation from the actual master’s address will prevent connection.
  4. Master Redis Instance Not Running or Not Listening on the Correct Interface:

    • Diagnosis: On the master machine, run ps aux | grep redis-server to confirm the process is running. Then, check its configuration (redis.conf). The port directive should match <new_master_port>, and bind directive should either be 0.0.0.0 or the specific IP address the replica is trying to connect to. If bind is set to 127.0.0.1, it will only accept local connections.
    • Fix: Start the master Redis server if it’s not running, or update its redis.conf to listen on the correct port and bind to an IP address accessible by the replica. Restart the master Redis server after configuration changes.
      port 6379
      bind 0.0.0.0
      
    • Why it works: The replica needs a running Redis server on the target IP and port that is configured to accept incoming connections from its network location.
  5. Authentication Mismatch (if requirepass is set on the master):

    • Diagnosis: If the master Redis server has requirepass configured in its redis.conf, the replica needs to provide the correct password. The CONFIG SET slaveof command itself doesn’t pass credentials. The replica will attempt to connect and then fail authentication. Check the replica’s log files for "Authentication required" or similar errors.
    • Fix: Configure the replica to use the master’s password. This is done after setting slaveof by using redis-cli -p <replica_port> CONFIG SET masterauth <master_password>.
      redis-cli -p <replica_port> CONFIG SET slaveof <master_ip> <master_port>
      redis-cli -p <replica_port> CONFIG SET masterauth <master_password>
      
    • Why it works: Redis replication requires authentication if the master is protected by a password. The masterauth configuration directive on the replica provides the necessary credentials for it to authenticate with the master upon connection.
  6. Redis Version Incompatibility or Bug:

    • Diagnosis: Check the Redis versions on both the master and replica. While replication is generally backward and forward compatible within major versions, very old versions might have issues, or specific bugs could exist in certain minor releases.
    • Fix: Upgrade both master and replica to a recent, stable Redis version. Consult the Redis release notes for any known replication-related issues in your current versions.
    • Why it works: Newer versions often contain bug fixes and performance improvements that resolve underlying issues preventing proper replication.

After successfully reconfiguring the slave, you might encounter a MASTERDOWN error if the replica previously failed to connect to its old master and the system is expecting that old master to be available.

Want structured learning?

Take the full Redis course →