Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent command behavior for keyless read commands #369

Open
madolson opened this issue Apr 24, 2024 · 0 comments
Open

Inconsistent command behavior for keyless read commands #369

madolson opened this issue Apr 24, 2024 · 0 comments

Comments

@madolson
Copy link
Member

There are 3 keyless read commands (randomkey, SCAN, KEYS) that operate a little strangely in Valkey cluster with respect to the READONLY flag. All other commands that access data, will route requests from the replica to to the primary if sent to the replica without the READONLY flag set. However, these three commands don't and allow returning eventually consistent results.

Example test which will pass.

start_cluster 1 1 {tags {external:skip cluster} overrides {cluster-replica-no-failover yes}} {

    test {Validate that keyless readonly commands are routing to primaries} {
        R 0 set foo bar
        R 0 wait 1 1000
        R 0 randomkey
        R 1 randomkey

        R 0 get foo
        assert_error "*MOVED*" {R 1 get foo}

        R 0 SCAN 0
        R 1 SCAN 0
    }
}

I don't think this is a significant issue, it's just a bit weird. There is a bigger issues with some module commands though, ones that don't declare keys but still access data available on the given shard.

Additionally, scripts have an interesting behavior. Even with EVAL_RO sent to a replica, if the script doesn't declare keys it won't be automatically redirected to the primary but instead will just throw an internal error. "ERR Script attempted to access a non local key in a cluster node script".

Suggested action items

I think we should introduce a change to allow modules to support redirection without a SLOT, similar to the proposal indicated here: #325. Either with -MOVED -1 ... or some other similar semantic. I don't think we can fix the other three mentioned items.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant