Replication: when possible start RDB saving ASAP.

In a previous commit the replication code was changed in order to
centralize the BGSAVE for replication trigger in replicationCron(),
however after further testings, the 1 second delay imposed by this
change is not acceptable.

So now the BGSAVE is only delayed if the AOF rewriting process is
active. However past comments made sure that replicationCron() is always
able to trigger the BGSAVE when needed, making the code generally more
robust.

The new code is more similar to the initial @oranagra patch where the
BGSAVE was delayed only if an AOF rewrite was in progress.

Trivia: delaying the BGSAVE uncovered a minor Sentinel issue that is now
fixed.
This commit is contained in:
antirez 2016-07-22 17:03:18 +02:00
parent 8b76d55f2e
commit 03f5b508e5

View File

@ -666,12 +666,18 @@ void syncCommand(client *c) {
* replicationCron() since we want to delay its start a * replicationCron() since we want to delay its start a
* few seconds to wait for more slaves to arrive. */ * few seconds to wait for more slaves to arrive. */
if (server.repl_diskless_sync_delay) if (server.repl_diskless_sync_delay)
serverLog(LL_NOTICE,"Delay next BGSAVE for SYNC"); serverLog(LL_NOTICE,"Delay next BGSAVE for diskless SYNC");
} else { } else {
/* Target is disk (or the slave is not capable of supporting /* Target is disk (or the slave is not capable of supporting
* diskless replication) and we don't have a BGSAVE in progress, * diskless replication) and we don't have a BGSAVE in progress,
* let's start one. */ * let's start one. */
serverLog(LL_NOTICE,"No BGSAVE in progress. Starting one ASAP"); if (server.aof_child_pid != -1) {
startBgsaveForReplication(c->slave_capa);
} else {
serverLog(LL_NOTICE,
"No BGSAVE in progress, but an AOF rewrite is active. "
"BGSAVE for replication delayed");
}
} }
} }