diff options
| author | antirez <antirez@gmail.com> | 2012-10-04 11:49:17 +0200 |
|---|---|---|
| committer | antirez <antirez@gmail.com> | 2012-10-04 11:49:17 +0200 |
| commit | 0c19880ce61bb4516346288a33797ec650e13842 (patch) | |
| tree | da80dedb595fdedf54dce78a8770665b64d619d4 | |
| parent | 2ba962714aaba78921ce18a65628f71f350be460 (diff) | |
| download | redis-0c19880ce61bb4516346288a33797ec650e13842.tar.gz | |
"Timeout receiving bulk data" error message modified.
The new message now contains an hint about modifying the repl-timeout
configuration directive if the problem persists.
This should normally not be needed, because while the master generates
the RDB file it makes sure to send newlines to the replication channel
to prevent timeouts. However there are times when masters running on
very slow systems can completely stop for seconds during the RDB saving
process. In such a case enlarging the timeout value can fix the problem.
See issue #695 for an example of this problem in an EC2 deployment.
| -rw-r--r-- | src/replication.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/replication.c b/src/replication.c index 871ce95ae..c1e461916 100644 --- a/src/replication.c +++ b/src/replication.c @@ -721,7 +721,7 @@ void replicationCron(void) { if (server.masterhost && server.repl_state == REDIS_REPL_TRANSFER && (time(NULL)-server.repl_transfer_lastio) > server.repl_timeout) { - redisLog(REDIS_WARNING,"Timeout receiving bulk data from MASTER..."); + redisLog(REDIS_WARNING,"Timeout receiving bulk data from MASTER... If the problem persists try to set the 'repl-timeout' parameter in redis.conf to a larger value."); replicationAbortSyncTransfer(); } |