caleb-brown/redict
1
0
Fork 0
mirror of https://codeberg.org/redict/redict.git synced 2025-01-23 00:28:26 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Cluster: on resharding upgrade version of receiving node.

Browse Source 
The node receiving the hash slot needs to have a version that wins over
the other versions in order to force the ownership of the slot.

However the current code is far from perfect since a failover can happen
during the manual resharding. The fix is a work in progress but the
bottom line is that the new version must either be voted as usually,
set by redis-trib manually after it makes sure can't be used by other
nodes, or reserved configEpochs could be used for manual operations (for
example odd versions could be never used by slaves and are always used
by CLUSTER SETSLOT NODE).
This commit is contained in:
antirez 2014-02-11 00:32:39 +01:00
parent 6dc26795aa
commit a1349728ea
1 changed files with 8 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
src/cluster.c
View File

@ -3169,11 +3169,15 @@ void clusterCommand(redisClient *c) {
clusterNode *old_owner =
server.cluster->importing_slots_from[slot];
/* This slot was manually migrated, set this node configEpoch
* at least to the value of the configEpoch of the old owner
* so that its old replicas, or some of its old message pending
* on the cluster bus, can't claim our slot. */
* to a new epoch so that the new version can be propagated
* by the cluster.
*
* FIXME: the new version should be agreed otherwise a race
* is possible if while a manual resharding is in progress
* the master is failed over by a slave. */
if (old_owner->configEpoch > myself->configEpoch) {
myself->configEpoch = old_owner->configEpoch;
server.cluster->currentEpoch++;
myself->configEpoch = server.cluster->currentEpoch;
clusterDoBeforeSleep(CLUSTER_TODO_FSYNC_CONFIG);
}
server.cluster->importing_slots_from[slot] = NULL;