Skip to content

MULTI: some commands should not be allowed in multi/exec#5666

Closed
soloestoy wants to merge 2 commits intoredis:unstablefrom
soloestoy:fix-multi-failover
Closed

MULTI: some commands should not be allowed in multi/exec#5666
soloestoy wants to merge 2 commits intoredis:unstablefrom
soloestoy:fix-multi-failover

Conversation

@soloestoy
Copy link
Contributor

@soloestoy soloestoy commented Dec 6, 2018

Hi @antirez , we had a discussion about forbidden some commands in lua script in #4835.

But now I just found some commands are dangerous in multi/exec too... for instance:

We have a master instance listening on port 6379, and an replica listening on 7788, then execute REPLICAOF command in multi/exec on master:

127.0.0.1:6379> multi
OK
127.0.0.1:6379> replicaof 127.0.0.1 1234
QUEUED
127.0.0.1:6379> set a b
QUEUED
127.0.0.1:6379> set c d
QUEUED
127.0.0.1:6379> replicaof no one
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) OK
4) OK
127.0.0.1:6379> keys *
1) "c"
2) "a"

But the replica has nothing:

127.0.0.1:7788> keys *
(empty list or set)
127.0.0.1:7788> quit

It's because in multi/exec after REPLICAOF 127.0.0.1 1234 the master became an replica, then write commands would not be replicated, neither the repl_backlog.

So, I think we should forbid some replication commands like REPLICAOF, SYNC, PSYNC.

I know this is a corner case, but it really can lead to data inconsistency between master and replica.

@soloestoy
Copy link
Contributor Author

And this one @antirez .

@madolson
Copy link
Contributor

I'm not sure this is a good idea since this is strictly a backwards incompatible change. Someone may be using this, it seems like we should just make multi-exec more robust and not-vulnerable to these edge cases. Thoughts?

@yossigo
Copy link
Collaborator

yossigo commented Aug 18, 2020

Arguably, if someone is using it and counting on this behavior (why?!) then even fixing it in a more generic and robust way would still introduce a breaking change.

@soloestoy Did you encounter this in a real world scenario?

@oranagra
Copy link
Member

closing in favor of #10015

@oranagra oranagra closed this Dec 30, 2021
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

Successfully merging this pull request may close these issues.

4 participants