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
Browse filesBrowse the repository at this point in the historyBrowse files
authored
fix(sentinel): preserve seed nodes as reconnection candidates (redis#3237) (redis#3306)
transform() replaced sentinelRootNodes with the discovered peer list,
so once the connected sentinel was a discovered IP the configured
hostname seeds were evicted. After a full outage with new IPs the
client then had no resolvable address left to reconnect to.
Add mergeSentinelNodes(seeds, discovered): seeds are always kept as
reconnection candidates (first), discovered nodes appended, deduped by
host:port. transform() rebuilds sentinelRootNodes from this merge each
cycle. Hostname seeds re-resolve via DNS and recover from full-IP-change
outages; IP-literal seeds recover when sentinels return at the same
address.
Fixesredis#3237
Co-authored-by: Nikolay Karadzhov <nkaradzhov89@gmail.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
| name || The sentinel identifier for a particular database cluster |
77
-
| sentinelRootNodes || An array of root nodes that are part of the sentinel cluster, which will be used to get the topology. Each element in the array is a client configuration object. There is no need to specify every node in the cluster: 3 should be enough to reliably connect and obtain the sentinel configuration from the server |
77
+
| sentinelRootNodes || An array of root nodes that are part of the sentinel cluster, which will be used to get the topology. Each element in the array is a client configuration object. There is no need to specify every node in the cluster: 3 should be enough to reliably connect and obtain the sentinel configuration from the server. These nodes are treated as seeds and are always kept as reconnection candidates — see [Reconnecting after an outage](#reconnecting-after-an-outage).|
78
78
| maxCommandRediscovers |`16`| The maximum number of times a command will retry due to topology changes. |
79
79
| nodeClientOptions || The configuration values for every node in the cluster. Use this for example when specifying an ACL user to connect with |
80
80
| sentinelClientOptions || The configuration values for every sentinel in the cluster. Use this for example when specifying an ACL user to connect with |
| passthroughClientErrorEvents |`false`| When `true`, error events from client instances inside the sentinel will be propagated to the sentinel instance. This allows handling all client errors through a single error handler on the sentinel instance. |
86
86
| reserveClient |`false`| When `true`, one client will be reserved for the sentinel object. When `false`, the sentinel object will wait for the first available client from the pool. |
87
87
88
+
## Reconnecting after an outage
89
+
90
+
As the client learns the sentinel topology it discovers additional sentinel nodes (reported by the sentinels as IP addresses). The nodes you pass in `sentinelRootNodes` are kept as **seeds**: they are always retained as reconnection candidates and are tried first, alongside the discovered nodes. This matters after an outage where the whole sentinel set restarts.
91
+
92
+
Whether the client can recover depends on what the seeds resolve to:
93
+
94
+
-**Hostname seeds** (e.g. a DNS name or a Kubernetes service) re-resolve on every reconnect attempt, so the client follows the sentinels to their new addresses even if every IP changed. This is the most robust configuration and is recommended for environments with ephemeral addressing (Kubernetes, cloud autoscaling, DHCP).
95
+
-**IP-literal seeds** recover only if the sentinels come back at the same addresses (static IP / bare-metal / fixed-IP container setups). If every sentinel restarts on a new IP and the seeds are IP literals, the client has no resolvable address left to reconnect to — there is no information from which to discover the new addresses. Use hostnames to avoid this.
96
+
97
+
A stale seed that never comes back is harmless: the client fails to connect to it and moves on to the next candidate.
98
+
88
99
## PubSub
89
100
90
101
It supports PubSub via the normal mechanisms, including migrating the listeners if the node they are connected to goes down.
0 commit comments