diff options
| author | antirez <antirez@gmail.com> | 2014-06-07 14:25:47 +0200 |
|---|---|---|
| committer | antirez <antirez@gmail.com> | 2014-06-07 14:25:47 +0200 |
| commit | a2c2ef7de593ca9ae80b09c3b243965a746a106c (patch) | |
| tree | 80acfdafb0e5b05c13ebafa0ab1ec6e6d1dbc7a1 | |
| parent | a2403227c7b164e546e53bf329c70caaadef2c14 (diff) | |
| download | redis-a2c2ef7de593ca9ae80b09c3b243965a746a106c.tar.gz | |
Cluster: SET-CONFIG-EPOCH should update currentEpoch.
SET-CONFIG-EPOCH, used by redis-trib at cluster creation time, failed to
update the currentEpoch, making it possible after a failover for a
server to set its configEpoch to a value smaller than the current one
(since configEpochs are obtained using currentEpoch).
The bug totally break the Redis Cluster algorithms and protocols
allowing for permanent split brain conditions about the slots
configuration as shown in issue #1799.
| -rw-r--r-- | src/cluster.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/cluster.c b/src/cluster.c index 948cc9140..bdaf36fbd 100644 --- a/src/cluster.c +++ b/src/cluster.c @@ -3790,6 +3790,8 @@ void clusterCommand(redisClient *c) { addReplyError(c,"Node config epoch is already non-zero"); } else { myself->configEpoch = epoch; + if (server.cluster->currentEpoch < epoch) + server.cluster->currentEpoch = epoch; /* No need to fsync the config here since in the unlucky event * of a failure to persist the config, the conflict resolution code * will assign an unique config to this node. */ |