- 24 Apr, 2013 4 commits
-
-
antirez authored
Sentinel redirected to the master if the instance changed runid or it was the first time we got INFO, and a role change was detected from master to slave. While this is a good idea in case of slave->master, since otherwise we could detect a failover without good reasons just after a reboot with a slave with a wrong configuration, in the case of master->slave transition is much better to always perform the redirection for the following reasons: 1) A Sentinel may go down for some time. When it is back online there is no other way to understand there was a failover. 2) Pointing clients to a slave seems to be always the wrong thing to do. 3) There is no good rationale about handling things differently once an instance is rebooted (runid change) in that case.
-
antirez authored
-
antirez authored
This prevents the kernel from putting too much stuff in the output buffers, doing too heavy I/O all at once. So the goal of this commit is to split the disk pressure due to the AOF rewrite process into smaller spikes. Please see issue #1019 for more information.
-
antirez authored
-
- 23 Apr, 2013 1 commit
-
-
antirez authored
When the test is executed using the root account, setting the permission to 222 does not work as expected, as root can read files with 222 permission. Now we skip the test if root is detected. This fixes issue #1034 and the duplicated #1040 issue. Thanks to Jan-Erik Rediger (@badboy on Github) for finding a way to reproduce the issue.
-
- 22 Apr, 2013 1 commit
-
-
antirez authored
-
- 19 Apr, 2013 3 commits
- 18 Apr, 2013 1 commit
-
-
antirez authored
Redis gitignore was too aggressive since simply broken. Jemalloc gitignore was too agressive because it is conceived to just keep the files that allow to generate all the rest in development environments (so for instance the "configure" file is excluded).
-
- 11 Apr, 2013 2 commits
-
-
antirez authored
Previously redis-cli never tried to raise an error when an unrecognized switch was encountered, as everything after the initial options is to be transmitted to the server. However this is too liberal, as there are no commands starting with "-". So the new behavior is to produce an error if there is an unrecognized switch starting with "-". This should not break past redis-cli usages but should prevent broken options to be silently discarded. As far the first token not starting with "-" is encountered, all the rest is considered to be part of the command, so you cna still use strings starting with "-" as values, like in: redis-cli --port 6380 set foo --my-value
-
antirez authored
-
- 09 Apr, 2013 4 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
We used to copy this value into the server.cluster structure, however this was not necessary. The reason why we don't directly use server.cluster->node_timeout is that things that can be configured via redis.conf need to be directly available in the server structure as server.cluster is allocated later only if needed in order to reduce the memory footprint of non-cluster instances.
-
antirez authored
-
- 08 Apr, 2013 1 commit
-
-
antirez authored
In commit d728ec6d it was introduced the concept of sending a ping to every node not receiving a ping since node_timeout/2 seconds. However the code was located in a place that was not executed because of a previous conditional causing the loop to re-iterate. This caused false positives in nodes availability detection. The current code is still not perfect as a node may be detected to be in PFAIL state even if it does not reply for just node_timeout/2 seconds that is not correct. There is a plan to improve this code ASAP.
-
- 04 Apr, 2013 5 commits
- 03 Apr, 2013 1 commit
-
-
antirez authored
-
- 02 Apr, 2013 3 commits
-
-
antirez authored
When a BGSAVE fails, Redis used to flood itself trying to BGSAVE at every next cron call, that is either 10 or 100 times per second depending on configuration and server version. This commit does not allow a new automatic BGSAVE attempt to be performed before a few seconds delay (currently 5). This avoids both the auto-flood problem and filling the disk with logs at a serious rate. The five seconds limit, considering a log entry of 200 bytes, will use less than 4 MB of disk space per day that is reasonable, the sysadmin should notice before of catastrofic events especially since by default Redis will stop serving write queries after the first failed BGSAVE. This fixes issue #849
-
antirez authored
-
Salvatore Sanfilippo authored
Build improvements
-
- 29 Mar, 2013 1 commit
-
-
charsyam authored
-
- 28 Mar, 2013 6 commits
- 27 Mar, 2013 4 commits
- 26 Mar, 2013 3 commits
-
-
antirez authored
The hope is that the new one is more readable.
-
antirez authored
Fixes issue #1024.
-
antirez authored
This commit fixes two corner cases for the TTL command. 1) When the key was already logically expired (expire time older than current time) the command returned -1 instead of -2. 2) When the key was existing and the expire was found to be exactly 0 (the key was just about to expire), the command reported -1 (that is, no expire) instead of a TTL of zero (that is, about to expire).
-