From 6dc26795aa949d6cacad4f7c6ab2df0f18f670e4 Mon Sep 17 00:00:00 2001 From: antirez Date: Mon, 10 Feb 2014 23:54:08 +0100 Subject: [PATCH] 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. --- src/cluster.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/cluster.c b/src/cluster.c index 8296e1c3..57f502c7 100644 --- a/src/cluster.c +++ b/src/cluster.c @@ -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 */