This is somewhat peculiar bug (or I think at least it's a bug). Originally I had the following config (after stripping comments and empty lines): ```daemonize no supervised systemd pidfile "/run/redis-sentinel/redis-sentinel.pid" logfile "/var/log/redis/redis-sentinel.log" loglevel verbose bind 127.0.0.1 10.230.238.12 protected-mode no port 26379 sentinel myid 3db200b46abd179e287ca0d5ab8c619324340d1c sentinel monitor cdn 10.230.238.26 6379 2 dir "/var/lib/redis" sentinel announce-ip 10.230.238.12 sentinel announce-port 26379
The above config resulted with sentinels unable to work correctly with following errors (on debug level) in logs:
```779:X 03 Nov 12:41:24.592 . -cmd-link-reconnection master cdn 10.230.238.26 6379 #Invalid argument
779:X 03 Nov 12:41:24.592 . -pubsub-link-reconnection master cdn 10.230.238.26 6379 #Invalid argument
779:X 03 Nov 12:41:25.651 . -cmd-link-reconnection master cdn 10.230.238.26 6379 #Invalid argument
779:X 03 Nov 12:41:25.651 . -pubsub-link-reconnection master cdn 10.230.238.26 6379 #Invalid argument
Some quick googling revealed someone had similar issue - though a lot of time ago: https://groups.google.com/forum/#!topic/redis-db/IIY2gx33t2s - with suggested resolution to swap ip addresses in 'bind' directive:
bind 127.0.0.1 10.230.238.12 -> bind 10.230.238.12 127.0.0.1
So while it workarounds the issue, something is amiss.
The redis servers (not sentinels) were configured similarly - with explicit bind having 127.0.0.1 first followed by the 10.* address and explicit announce-ip/announce-port directives.
Comment From: morungos
OMG. This entirely caught me and I just spent hours figuring this one out. The sentinels were simply not connecting right, and yet all the firewalls and manual connections were fine.
At the very least, this should be documented.
Comment From: itamarhaber
@morungos I'd be more than happy to review any PR you'd make to https://github.com/antirez/redis-doc ;)