redis/redis-py · critical · MasterNotFoundError

No master found for {service_name!r}{error_info}

Error message

No master found for {service_name!r}{error_info}

What it means

Raised by Sentinel.discover_master (redis/sentinel.py:384) as redis.exceptions.MasterNotFoundError (a ConnectionError subclass). The method iterates over every configured Sentinel, calls sentinel_masters(), and looks for a matching service_name whose state passes check_master_state. If no Sentinel yields a healthy master, MasterNotFoundError is raised; when some Sentinels were themselves unreachable, error_info lists the per-Sentinel ConnectionError/TimeoutError details.

Source

Thrown at redis/sentinel.py:384

            state = masters.get(service_name)
            if state and self.check_master_state(state, service_name):
                # Put this sentinel at the top of the list
                self.sentinels[0], self.sentinels[sentinel_no] = (
                    sentinel,
                    self.sentinels[0],
                )

                ip = (
                    self._force_master_ip
                    if self._force_master_ip is not None
                    else state["ip"]
                )
                return ip, state["port"]

        error_info = ""
        if len(collected_errors) > 0:
            error_info = f" : {', '.join(collected_errors)}"
        raise MasterNotFoundError(f"No master found for {service_name!r}{error_info}")

    def filter_slaves(self, slaves):
        "Remove slaves that are in an ODOWN or SDOWN state"
        slaves_alive = []
        for slave in slaves:
            if slave["is_odown"] or slave["is_sdown"]:
                continue
            slaves_alive.append((slave["ip"], slave["port"]))
        return slaves_alive

    def filter_replicas(self, replicas):
        """Remove replicas that are in an ODOWN or SDOWN state.

        This is an alias for :py:meth:`filter_slaves`,
        using the preferred Redis 5.0+ terminology.
        """
        return self.filter_slaves(replicas)

View on GitHub (pinned to da03cdc7e8)

Solutions

1. Verify the service_name matches a monitored master: redis-cli -p <sentinel_port> sentinel masters.
2. Check Sentinel reachability and health from the client host (redis-cli -p <sentinel_port> ping).
3. Inspect Sentinel logs for s_down/o_down/failover events and confirm quorum is intact.
4. Confirm Sentinel knows the correct master: redis-cli -p <sentinel_port> sentinel get-master-addr-by-name <service_name>.
5. If a failover is in progress, wait and retry with backoff.

Example fix

# before
master = sentinel.master_for('mymaster')
master.set('k', 'v')
# after (validate name + retry with backoff)
from redis.exceptions import ConnectionError
import time
for attempt in range(10):
    try:
        master = sentinel.master_for('mymaster')
        master.set('k', 'v')
        break
    except ConnectionError:
        time.sleep(0.2 * (2 ** attempt))

def master_discoverable(sentinel, service_name: str) -> bool:
    try:
        return sentinel.discover_master(service_name) is not None
    except Exception:
        return False

import time
from redis.exceptions import ConnectionError as RedisConnectionError

def get_master_with_retry(sentinel, name: str, max_attempts=10):
    last_err = None
    for attempt in range(max_attempts):
        try:
            return sentinel.master_for(name)
        except RedisConnectionError as e:
            last_err = e
            time.sleep(0.2 * (2 ** attempt))
    raise last_err

When it happens

Trigger: Any master_for(...) call or write operation on a Sentinel-managed client, when none of the configured Sentinels reports a valid master for the service_name (state missing, or check_master_state fails flags like master_flag, role, etc.). Also triggered when all Sentinels are unreachable, in which case error_info enumerates each failure.

Common situations: Wrong service_name (typo, or not yet monitored); all Sentinels down or unreachable from the client; master is down and Sentinel has not yet elected a new one; Sentinel lost quorum (s_down/o_down without promotion); network partition between client and Sentinels; Sentinel monitoring not yet bootstrapped for the deployment.

Related errors

• The previous master is now a slave
• No slave found for {self.service_name!r}
• The previous master is now a slave
• No slave found for {self.service_name!r}
• No master found for {service_name!r}{error_info}

AI-assisted analysis of redis/redis-py@da03cdc7e8 (2026-08-04). Data as JSON: /data/errors/3d297feb3a284f64.json. Report an issue: GitHub.