This new command triggers a config flush to save the in-memory config to
disk. This is useful for cases of a configuration management system or a
package manager wiping out your sentinel config while the process is
still running - and has not yet been restarted. It can also be useful
for scripting a backup and migrate or clone of a running sentinel.
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.
To rewrite the config in the loop that adds slaves back after a master
reset, in order to handle switching to another master, is useless: it
just adds latency since there is an fsync call in the inner loop,
without providing any additional guarantee, but the contrary, since if
after the first loop iteration the server crashes we end with just a
single slave entry losing all the other informations.
It is wiser to rewrite the config at the end when the full new
state is configured.
Correclty check for Windows 8 version (6.2), in case this code
path gets re-enabled again.
Note that Windows 10 has version number 10.0, so it would finally
take the code path originally intended for Windows 8 and higher.
VirtualProtect is failing with ERROR_INVALID_PARAMETER.
It's possible that this code path never worked because it is
checking for Windows version 8.0. Windows 8's version number is 6.2,
not 8.0.
Conflicts:
src/Win32_Interop/Win32_QFork.cpp
Fix for https://github.com/MSOpenTech/redis/issues/167
RejoinCOWPages used to call QueryWorkingSetEx to figure out
which pages had been dirtied since the memory map was protected
with PAGE_WRITECOPY. But dirty pages that had been swapped out to
the system page file would be reported as not valid
(VirtualAttributes.Valid == 0) and so we wouldn't restore them into
the file map.
QueryWorkingSetEx only gives information about pages that are in the
working set at the time it is called. Pages can be forced into the
working set using VirtualLock, but that seems like a potentially
risky / expensive solution.
I implemented a solution that uses VirtualQuery to find out which
regions have changed protection from PAGE_WRITECOPY.
This fixes issue #2535, that was actually an hiredis library bug (I
submitted an issue and fix to the redis/hiredis repo as well).
When an asynchronous hiredis connection subscribes to a Pub/Sub channel
and gets an error, and in other related conditions, the function
redisProcessCallbacks() enters a code path where the link is
disconnected, however the function returns before freeing the allocated
reply object. This causes a memory leak. The memory leak was trivial to
trigger in Redis Sentinel, which uses hiredis, every time we tried to
subscribe to an instance that required a password, in case the Sentinel
was configured either with the wrong password or without password at
all. In this case, the -AUTH error caused the leaking code path to be
executed.
It was verified with Valgrind that after this change the leak no longer
happens in Sentinel with a misconfigured authentication password.
Alexis Campailla