Hi there,

I was hoping for some clarification around how sentinel handles known sentinel instances. (Version 6.2.1)

The documentation for sentinel (https://redis.io/topics/sentinel#sentinels-and-replicas-auto-discovery) states the following.

Before adding a new sentinel to a master a Sentinel always checks if there is already a sentinel with the same runid or the same address (ip and port pair). In that case all the matching sentinels are removed, and the new added.

I have a deployment setup wherein I overwrite the sentinel.conf and therefore a new runid is created. The documentation would lead me to believe that the new sentinel (due to having the same ip/port) would replace the old in the other sentinels config.

However I was noticing that my sentinel count via INFO SENTINEL (from the view of the other sentinel) was 1 greater than expected and if I called SENTINEL SENTINEL my-leader I would see an entry for both the new and old run id.

Following the +sentinel-invalid-addr in the logs, I came across this bit of source code and commit (751b566) which states that if the port/ip of sentinel matches an existing one the old ones port is set to 0 (meaning its invalid).

Its not entirely clear to me what the state of this old sentinel (identified by a run id) is, for example is it considered/counted in the total number of sentinels when trying to decide if you have a majority for failover.

Either way there would seem to be a bug/inconsistency around how the documentation states new sentinels with matching addresses are handled and how they are actually handled (they do not replace the old entry).

Apologies for not following the standard format for bugs, I had originally intended to send this to the google group, but decided there might be a bug, or at least a lack of clarity in the documentation. Happy to move this to the google group if I'm mistaken in my belief.

I can also try to provide a minimal example if that's helpful, although I hope my description is enough to reproduce.

Thanks,

Matt