Add a new failover option prioritising nodes #1896
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is for issue #1194. |
|
I just noticed you get a segfault if you have distribute mode set but have no preferred nodes set when you go to run a command... (fixed in subsequent commits) |
aolley
force-pushed
the
feature/failover_preferred
branch
3 times, most recently
from
5f8117f
to
84f44c6
Compare
This makes it possible to define a list of nodes you'd prefer to communicate with in cluster mode. This behaves similarly to FAILOVER_DISTRIBUTE, where it randomises the list of nodes before trying them in sequence - however it takes that random list and sorts any preferred nodes to the top first. All candidate nodes are still in the list, but the preferred ones get tried first. This is extremely helpful for setups where you know which nodes are closer (i.e. not crossing an AZ boundary).
Redis can be in a state where a replica will respond MOVED to a slot even if that replica should be able to serve that slot. The why is immaterial - redis spec says you must perform your command on the host:port the MOVED response specifies. If we always sort our preferred nodes higher than the host:port it says we should read from - we end up never reading from it. This shortcuts that by disabling the FAILOVER mode entirely when this situation is encounted - ensuring the command then goes to the primary. This has a slight benefit over FAILOVER_DISTRIBUTE_SLAVES mode - as that will work, but randomly picks a node out of the list (primary+replicas) each time - you just happen to eventually get the primary and have it continue. By switching to NONE - we immediately just talk to the primary.
aolley
force-pushed
the
feature/failover_preferred
branch
from
84f44c6
to
c004a75
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This makes it possible to define a list of nodes you'd prefer to communicate
with in cluster mode.
This behaves similarly to FAILOVER_DISTRIBUTE, where it randomises the list of
nodes before trying them in sequence - however it takes that random list and
sorts any preferred nodes to the top first. All candidate nodes are still in
the list, but the preferred ones get tried first.
This is extremely helpful for setups where you know which nodes are closer
(i.e. not crossing an AZ boundary).