You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using an environment with only dynamic ips. So we have created a kubernetes service that will always resolve to a healthy sentinel: redis.sentinel. When we set the sentinels parameter to this host, all works fine as an ip is resolved and the connection proceeds.
When ioredis connects to the master though, it asks the master for its sentinel list and proceeds to add all those ips to the sentinel list as well: redis.sentinel, ip1, ip2, ip3. This is ok for the moment as those are the valid ips of the current sentinels. But when those pods die, new ips (ip4-ip6) are added but the old ips (ip1-ip3) that will never be reused are still in the list: redis.sentinel, ip1, ip2, ip3, ip4, ip5, ip6.
Connections continue to work as if ip1-3 are tried, they would just fail and the next sentinel in the list is tried until a working one is found. Over time and many updates for long running clients, eventually this list becomes more like: redis.sentinel, ip1, ... ip100 and beyond.
I understand the reasoning behind adding the new ips and not removing the old ones as the old ones might just be sentinels that are having an outage and will eventually come back up so there is no good knowledge of when to remove old ips.
But for some cases like ours or a list of known static ips, we know the only list of sentinel values we want to use and don't want to add any other possible sentinels to that list. Not checking for any other values and not adding them to the list would be a performance improvement for us.
Suggested Change:
An option updateSentinels whose default would be true with the current behavior to update the sentinel list as new sentinels are discovered, but could be set to false where no new values would ever be added to the sentinel list.
The behavior of iterating through the list looking for good values would remain intact, it would just be the list itself that would never get any additional values if updateSentinels were set to false.
This change would mainly be to the lib/connectors/SentinelConnector/index.ts - updateSentinels method, wrapping it with a check for the value of updateSentinels, only running its content if the value if true.
The text was updated successfully, but these errors were encountered:
# [4.7.0](v4.6.3...v4.7.0) (2019-03-12)
### Features
* add updateSentinels option to control new sentinel values being added to the original list ([#814](#814)) ([50a9db7](50a9db7)), closes [#798](#798)
Description:
We're using an environment with only dynamic ips. So we have created a kubernetes service that will always resolve to a healthy sentinel:
redis.sentinel
. When we set thesentinels
parameter to this host, all works fine as an ip is resolved and the connection proceeds.When ioredis connects to the master though, it asks the master for its sentinel list and proceeds to add all those ips to the sentinel list as well:
redis.sentinel, ip1, ip2, ip3
. This is ok for the moment as those are the valid ips of the current sentinels. But when those pods die, new ips (ip4-ip6) are added but the old ips (ip1-ip3) that will never be reused are still in the list:redis.sentinel, ip1, ip2, ip3, ip4, ip5, ip6
.Connections continue to work as if ip1-3 are tried, they would just fail and the next sentinel in the list is tried until a working one is found. Over time and many updates for long running clients, eventually this list becomes more like:
redis.sentinel, ip1, ... ip100
and beyond.I understand the reasoning behind adding the new ips and not removing the old ones as the old ones might just be sentinels that are having an outage and will eventually come back up so there is no good knowledge of when to remove old ips.
But for some cases like ours or a list of known static ips, we know the only list of sentinel values we want to use and don't want to add any other possible sentinels to that list. Not checking for any other values and not adding them to the list would be a performance improvement for us.
Suggested Change:
An option
updateSentinels
whose default would betrue
with the current behavior to update the sentinel list as new sentinels are discovered, but could be set tofalse
where no new values would ever be added to the sentinel list.The behavior of iterating through the list looking for good values would remain intact, it would just be the list itself that would never get any additional values if updateSentinels were set to false.
This change would mainly be to the
lib/connectors/SentinelConnector/index.ts - updateSentinels
method, wrapping it with a check for the value of updateSentinels, only running its content if the value if true.The text was updated successfully, but these errors were encountered: