Commit 6dc26795 authored by antirez's avatar antirez
Browse files

Cluster: fsync at every SETSLOT command puts too pressure on disks.

During slots migration redis-trib can send a number of SETSLOT commands.
Fsyncing every time is a bit too much in production as verified
empirically.

To make sure configs are fsynced on all nodes after a resharding
redis-trib may send something like CLUSTER CONFSYNC.

In this case fsyncs were not providing too much value since anyway
processes can crash in the middle of the resharding of an hash slot, and
redis-trib should be able to recover from this condition anyway.
parent 218358bb
......@@ -3172,8 +3172,10 @@ void clusterCommand(redisClient *c) {
* 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. */
if (old_owner->configEpoch > myself->configEpoch)
if (old_owner->configEpoch > myself->configEpoch) {
myself->configEpoch = old_owner->configEpoch;
clusterDoBeforeSleep(CLUSTER_TODO_FSYNC_CONFIG);
}
server.cluster->importing_slots_from[slot] = NULL;
}
clusterDelSlot(slot);
......@@ -3182,9 +3184,7 @@ void clusterCommand(redisClient *c) {
addReplyError(c,"Invalid CLUSTER SETSLOT action or number of arguments");
return;
}
clusterDoBeforeSleep(CLUSTER_TODO_SAVE_CONFIG|
CLUSTER_TODO_UPDATE_STATE|
CLUSTER_TODO_FSYNC_CONFIG);
clusterDoBeforeSleep(CLUSTER_TODO_SAVE_CONFIG|CLUSTER_TODO_UPDATE_STATE);
addReply(c,shared.ok);
} else if (!strcasecmp(c->argv[1]->ptr,"info") && c->argc == 2) {
/* CLUSTER INFO */
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment