-
Notifications
You must be signed in to change notification settings - Fork 717
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
Add multi-database support to cluster mode #1671
base: unstable
Are you sure you want to change the base?
Changes from all commits
b5c933f
4d45a7e
a20c149
1c3ea2f
0cf9b2d
9fff9f1
0e29ea2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -860,10 +860,6 @@ void selectCommand(client *c) { | |
|
||
if (getIntFromObjectOrReply(c, c->argv[1], &id, NULL) != C_OK) return; | ||
|
||
if (server.cluster_enabled && id != 0) { | ||
addReplyError(c, "SELECT is not allowed in cluster mode"); | ||
return; | ||
} | ||
if (selectDb(c, id) == C_ERR) { | ||
addReplyError(c, "DB index is out of range"); | ||
} else { | ||
|
@@ -1429,11 +1425,6 @@ void moveCommand(client *c) { | |
int srcid, dbid; | ||
long long expire; | ||
|
||
if (server.cluster_enabled) { | ||
addReplyError(c, "MOVE is not allowed in cluster mode"); | ||
return; | ||
} | ||
|
||
/* Obtain source and target DB pointers */ | ||
src = c->db; | ||
srcid = c->db->id; | ||
|
@@ -1518,11 +1509,6 @@ void copyCommand(client *c) { | |
} | ||
} | ||
|
||
if ((server.cluster_enabled == 1) && (srcid != 0 || dbid != 0)) { | ||
addReplyError(c, "Copying to another database is not allowed in cluster mode"); | ||
return; | ||
} | ||
|
||
/* If the user select the same DB as | ||
* the source DB and using newkey as the same key | ||
* it is probably an error. */ | ||
|
@@ -1728,12 +1714,6 @@ void swapMainDbWithTempDb(serverDb *tempDb) { | |
void swapdbCommand(client *c) { | ||
int id1, id2; | ||
|
||
/* Not allowed in cluster mode: we have just DB 0 there. */ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would that be enough for swapdb to work in cluster mode? What will happen in setup with 2 shards, each responsible for half of slots in db's? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. With this implementation SWAPDB must be executed in all primary nodes. There are three options:
I think option 2 is the safest bet. @JoBeR007 wdyt? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is SWAPDB replicated as a single command? Then it's atomic. If it's risky, it's risky in standslone mode with replicas too, right? I think we can allow it. Swapping the data can only be done in some non-realtime workloads anyway I think. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think risky because of replication and risky because of the need to execute SWAPDB on all primary nodes are unrelated just because as a user you can't control first, but user is the main risk in the second case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In cluster mode, consistency is per slot. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I don’t think it’s very risky with standalone replicas. The only downside is if SWAPDB propagation to the replica takes time, a client might still access the wrong database. At least the client won’t be able to modify the wrong database, as they can only read. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, FLUSHDB is very similar in this regard. If a failover happens just before this command has been propagated to replicas, it's a big thing, but it's no surprise I think. The client can use WAIT or check replication offset to make sure the FLUSHDB or SWAPDB was successful on the replicas. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Regarding this, I think it is not just an issue of Multi-database but is more related to atomic slot migration. If a shard is in a stable state (not undergoing slot migration), then I think this needs to be considered alongside atomic-slot-migration:
@PingXie @enjoy-binbin , please also take note of this. |
||
if (server.cluster_enabled) { | ||
addReplyError(c, "SWAPDB is not allowed in cluster mode"); | ||
return; | ||
} | ||
|
||
/* Get the two DBs indexes. */ | ||
if (getIntFromObjectOrReply(c, c->argv[1], &id1, "invalid first DB index") != C_OK) return; | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, I modified it to use
c->db
, so for most commands, the key it wants to access can be correctly located. However, some cross-DB commands, such asCOPY
, still require additional checks. The ultimate solution is atomic-slot-migration I believe. Once ATM is implemented, theTRYAGAIN
issue will no longer occur.