diff options
author | therealbill <therealbill@me.com> | 2015-04-23 11:56:15 -0500 |
---|---|---|
committer | antirez <antirez@gmail.com> | 2015-05-04 12:55:30 +0200 |
commit | f0ab4fd6fd1b736c6a5803368cfcd9474eaf0b05 (patch) | |
tree | 5ae546f5fa3230d992e52a50acc6f12b947046de | |
parent | e4c54498db482689b81e38886f142edd57de43d4 (diff) | |
download | redis-f0ab4fd6fd1b736c6a5803368cfcd9474eaf0b05.tar.gz |
Making sentinel flush config on +slave
Originally, only the +slave event which occurs when a slave is
reconfigured during sentinelResetMasterAndChangeAddress triggers a flush
of the config to disk. However, newly discovered slaves don't
apparently trigger this flush but do trigger the +slave event issuance.
So if you start up a sentinel, add a master, then add a slave to the
master (as a way to reproduce it) you'll see the +slave event issued,
but the sentinel config won't be updated with the known-slave entry.
This change makes sentinel do the flush of the config if a new slave is
deteted in sentinelRefreshInstanceInfo.
-rw-r--r-- | src/sentinel.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/src/sentinel.c b/src/sentinel.c index 17b273ab0..dafe02bef 100644 --- a/src/sentinel.c +++ b/src/sentinel.c @@ -1841,6 +1841,7 @@ void sentinelRefreshInstanceInfo(sentinelRedisInstance *ri, const char *info) { atoi(port), ri->quorum, ri)) != NULL) { sentinelEvent(REDIS_NOTICE,"+slave",slave,"%@"); + sentinelFlushConfig(); } } } |