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.
This commit is contained in:
antirez 2014-02-10 23:54:08 +01:00
parent 218358bbbd
commit 6dc26795aa

View File

@ -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 */