From a1d02492971e79dcd05a8d911abce4b75a409ac9 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 8296e1c38..57f502c7d 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 */