The ScenarioYou’re troubleshooting a Redis High Availability (HA) setup and everything looks stable on the surface. However, the moment you query a Sentinel node for the master's address, the system pushes back. Instead of returning an IP, the CLI throws a surprisingly blunt error:
127.0.0.1:26379> SENTINEL get-master-addr-by-name production-cluster
(error) IDONTKNOW No such master with that name
Sentinel is being literal here. This error triggers when the master name in your command doesn't match what the Sentinel process currently holds in its active memory.
Finding the DisconnectThe IDONTKNOW response means your string is a ghost to the system. Here is how to track down where the configuration diverged.
1. Audit monitored mastersStart by asking Sentinel what it is actually watching. The SENTINEL masters command is your source of truth. It lists every master group currently tracked by that specific node.
127.0.0.1:26379> SENTINEL masters
Check the name field in the output. It is common to find the master still named mymaster (the Redis default) while your app expects production-cluster. Even a tiny typo—like prod_cluster versus prod-cluster—will break the connection.
2. Inspect the sentinel.conf fileIf the masters command returns an empty list, the configuration hasn't loaded properly. Open your config file (typically at /etc/redis/sentinel.conf) and look for the monitor line:
# Format: sentinel monitor <master-name> <ip> <port> <quorum>
sentinel monitor redis-main 10.0.0.15 6379 2
If this line is missing or prefixed with a #, Sentinel ignores the master entirely. This results in the IDONTKNOW error every time.
3. Case SensitivityNames in Redis Sentinel are case-sensitive. Querying PROD_DB when the config defines prod_db will fail. Also, watch out for invisible trailing spaces if you've been editing the config manually. Some older Redis versions may treat a space at the end of a name as part of the string itself.
How to Fix the ErrorOnce you identify the mismatch, use one of these three approaches to resolve it.
Option A: Update the QueryIf SENTINEL masters shows that the master is named mymaster, the fastest fix is updating your application's environment variables. Match your code to the existing configuration.
# This fails
SENTINEL get-master-addr-by-name redis-prod
# This works (matching the actual config)
SENTINEL get-master-addr-by-name mymaster
Option B: Register the Master DynamicallyYou don't need to restart the service to fix a missing master. You can tell Sentinel to start monitoring a new master group live using the CLI. This is useful for adding nodes without downtime.
127.0.0.1:26379> SENTINEL MONITOR production-db 10.0.0.20 6379 2
Sentinel usually rewrites its own config file automatically when you run this. However, it is a good habit to manually verify sentinel.conf afterward to ensure the change persists after a reboot.
Option C: Correct the Configuration FileIf the name in the config file is objectively wrong, fix it and restart the service. This is the cleanest way to ensure all nodes in a cluster stay in sync.
# Edit the configuration
sudo nano /etc/redis/sentinel.conf
# Update the line:
sentinel monitor production-db 10.0.0.20 6379 2
# Restart the service
sudo systemctl restart redis-sentinel
VerificationConfirm the fix by requesting details for the specific master name. You should see a detailed key-value list rather than an error.
127.0.0.1:26379> SENTINEL master production-db
If the flags field shows master, the node is healthy. Finally, run the address resolution command to ensure your application can find the IP:
127.0.0.1:26379> SENTINEL get-master-addr-by-name production-db
1) "10.0.0.20"
2) "6379"