Skip to content

Fixed - offline slaves and sentinels shouldn't be connected during Sentinel startup. #7286 - #7289

Open
junsj119 wants to merge 1 commit into
redisson:masterfrom
junsj119:fix/sentinel-startup-offline-nodes
Open

Fixed - offline slaves and sentinels shouldn't be connected during Sentinel startup. #7286#7289
junsj119 wants to merge 1 commit into
redisson:masterfrom
junsj119:fix/sentinel-startup-offline-nodes

Conversation

@junsj119

@junsj119 junsj119 commented Aug 8, 2026

Copy link
Copy Markdown

Fixes #7286.

The Sentinel startup path in SentinelConnectionManager still used the pre-#7004 ordering, unlike the periodic checks that were corrected in #7004:

  • Slaves: resolveIP(host, port).join() ran before the isDown(...) check, so an offline replica whose hostname no longer resolves (e.g. a scaled-down k8s pod) threw during startup.
  • Sentinels: every entry returned by SENTINEL SENTINELS was resolved and connected unconditionally, so stale entries pointing at dead addresses each cost a full connect timeout.

Mirror the periodic-check behavior (checkSlavesChange / checkSentinelsChange) in the startup loops: check isDown(...) first and skip offline slaves and sentinels before resolving and connecting.

…laves and sentinels during Sentinel startup. redisson#7286

Signed-off-by: junsj119 <wjstjddud119@naver.com>
@junsj119
junsj119 force-pushed the fix/sentinel-startup-offline-nodes branch from bf3d1bf to 8de3dfd Compare August 8, 2026 10:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

Redisson SentinelConnectionManager is too aggresive on startup

1 participant