redis/jedis · warning

Can not get master addr, master name

Error message

Can not get master addr, master name: {}. Sentinel: {}.

What it means

MasterListener is a background thread subscribing to Sentinel's +switch-master channel; before subscribing it actively refreshes the master address with sentinelGetMasterAddrByName and calls initMaster. If the response is null or not [host, port], it logs this warning (with a trailing period, distinguishing it from error 295) and skips initMaster — the thread keeps running and relies on the pub/sub for later updates.

Solutions

  1. Check `SENTINEL masters` on the Sentinel in the warning; re-add `sentinel monitor <name>` if it was lost (and persist with `SENTINEL RESET`/config rewrite).
  2. Correct the masterName in the client config if it doesn't match the monitored name.
  3. Confirm the Sentinel can still resolve the master (master up, Sentinel connectivity to it).
  4. Restart the client after fixing Sentinel state so an initial refresh succeeds; pub/sub +switch-master will otherwise only fire on the next switch.

Example fix

// on the Sentinel host, before relying on the client
// before: (master missing)
// after:
// redis-cli -p 26379 SENTINEL MONITOR mymaster 127.0.0.1 6379 2
// redis-cli -p 26379 SENTINEL SET mymaster down-after-milliseconds 5000
Defensive patterns

Strategy: retry

Validate before calling

try (Jedis s = new Jedis(sentinelHost, 26379)) {
  boolean known = s.sentinelMasters().stream().anyMatch(m -> masterName.equals(m.get("name")));
  if (!known) throw new IllegalStateException("Sentinel no longer monitors " + masterName);
}

Try / catch

try { initMaster(addr); } catch (JedisException e) { log.warn("master refresh failed from sentinel {}:{}, waiting for +switch-master", host, port, e); }

Prevention

When it happens

Trigger: Inside MasterListener.run: a live Sentinel returns null or a malformed address list for masterName during the periodic active refresh — same root causes as the initSentinels variant (unknown master name, Sentinel not yet monitoring the master).

Common situations: Long-lived client whose Sentinel lost/re-added the monitored master; master name mismatch noticed only after startup; Sentinel restart wiped monitoring config (no `sentinel monitor` persisted via rewrite).

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


AI-assisted analysis of redis/jedis@6dac31d4c2 (2026-09-08). Data as JSON: /api/errors/613e7e3e972f6736. Report an issue: GitHub.

Appendix: source

Thrown at src/main/java/redis/clients/jedis/JedisSentinelPool.java:387

    public void run() {

      running.set(true);

      while (running.get()) {

        try {
          // double check that it is not being shutdown
          if (!running.get()) {
            break;
          }
          
          final HostAndPort hostPort = new HostAndPort(host, port);
          j = new Jedis(hostPort, sentinelClientConfig);

          // code for active refresh
          List<String> masterAddr = j.sentinelGetMasterAddrByName(masterName);
          if (masterAddr == null || masterAddr.size() != 2) {
            LOG.warn("Can not get master addr, master name: {}. Sentinel: {}.", masterName,
                hostPort);
          } else {
            initMaster(toHostAndPort(masterAddr));
          }

          j.subscribe(new JedisPubSub() {
            @Override
            public void onMessage(String channel, String message) {
              LOG.debug("Sentinel {} published: {}.", hostPort, message);

              String[] switchMasterMsg = message.split(" ");

              if (switchMasterMsg.length > 3) {

                if (masterName.equals(switchMasterMsg[0])) {
                  initMaster(toHostAndPort(Arrays.asList(switchMasterMsg[3], switchMasterMsg[4])));
                } else {
                  LOG.debug(

View on GitHub (pinned to 6dac31d4c2)