- 26 Jun, 2014 8 commits
-
-
antirez authored
-
antirez authored
Technically the problem is due to the client type API that does not return a special value for the master, however fixing it locally in the CLIENT KILL command is better currently because otherwise we would introduce a new output buffer limit class as a side effect.
-
antirez authored
Added for debugging and forgot there.
-
antirez authored
This is supposed to fix issue #1417, but we'll know if this is enough only after a couple of runs of the CI test without false positives.
-
Salvatore Sanfilippo authored
PowerPC compile-time improvements
-
Matt Stancliff authored
From mailing list post https://groups.google.com/forum/#!topic/redis-db/D3k7KmJmYgM In the file “config.h”, the definition HAVE_ATOMIC is used to indicate if an architecture on which redis is implemented supports atomic synchronization primitives. Powerpc supports atomic synchronization primitives, however, it is not listed as one of the architectures supported in config.h. This patch adds the __powerpc__ to the list of architectures supporting these primitives. The improvement of redis due to the atomic synchronization on powerpc is significant, around 30% to 40%, over the default implementation using pthreads. This proposal adds __powerpc__ to the list of architectures designated to support atomic builtins.
-
Matt Stancliff authored
From mailing list post https://groups.google.com/forum/#!topic/redis-db/QLjiQe4D7LA In zmalloc.c the following primitives are currently used to synchronize access to single global variable: __sync_add_and_fetch __sync_sub_and_fetch In some architectures such as powerpc these primitives are overhead intensive. More efficient C11 __atomic builtins are available with newer GCC versions, see http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/_005f_005fatomic-Builtins.html#_005f_005fatomic-Builtins By substituting the following __atomic… builtins: __atomic_add_fetch __atomic_sub_fetch the performance improvement on certain architectures such as powerpc can be significant, around 10% to 15%, over the implementation using __sync builtins while there is only slight uptick on Intel architectures because it was already enforcing Intel Strongly ordered memory semantics. The selection of __atomic built-ins can be predicated on the definition of ATOMIC_RELAXED which Is available on in gcc 4.8.2 and later versions.
-
Matt Stancliff authored
-
- 25 Jun, 2014 5 commits
-
-
antirez authored
-
antirez authored
While we have to output failing masters in order to provide an accurate map (that may be the one of a Redis Cluster in down state because not all slots are served by a working master), to provide slaves in FAIL state is not a good idea since those are not necesarely needed, and the client will likely incur into a latency penalty trying to connect with a slave which is down. Note that this means that CLUSTER SLOTS does not provide a *complete* map of slaves, however this would not be of any help since slaves may be added later, and a client that needs to scale reads and requires to stay updated with the list of slaves, need to do a refresh of the map from time to time, anyway.
-
antirez authored
-
Matt Stancliff authored
CLUSTER SLOTS returns a Redis-formatted mapping from slot ranges to IP/Port pairs serving that slot range. The outer return elements group return values by slot ranges. The first two entires in each result are the min and max slots for the range. The third entry in each result is guaranteed to be either an IP/Port of the master for that slot range - OR - null if that slot range, for some reason, has no master The 4th and higher entries in each result are replica instances for the slot range. Output comparison: 127.0.0.1:7001> cluster nodes f853501ec8ae1618df0e0f0e86fd7abcfca36207 127.0.0.1:7001 myself,master - 0 0 2 connected 4096-8191 5a2caa782042187277647661ffc5da739b3e0805 127.0.0.1:7005 slave f853501ec8ae1618df0e0f0e86fd7abcfca36207 0 1402622415859 6 connected 6c70b49813e2ffc9dd4b8ec1e108276566fcf59f 127.0.0.1:7007 slave 26f4729ca0a5a992822667fc16b5220b13368f32 0 1402622415357 8 connected 2bd5a0e3bb7afb2b56a2120d3fef2f2e4333de1d 127.0.0.1:7006 slave 32adf4b8474fdc938189dba00dc8ed60ce635b0f 0 1402622419373 7 connected 5a9450e8279df36ff8e6bb1c139ce4d5268d1390 127.0.0.1:7000 master - 0 1402622418872 1 connected 0-4095 32adf4b8474fdc938189dba00dc8ed60ce635b0f 127.0.0.1:7002 master - 0 1402622419874 3 connected 8192-12287 5db7d05c245267afdfe48c83e7de899348d2bdb6 127.0.0.1:7004 slave 5a9450e8279df36ff8e6bb1c139ce4d5268d1390 0 1402622417867 5 connected 26f4729ca0a5a992822667fc16b5220b13368f32 127.0.0.1:7003 master - 0 1402622420877 4 connected 12288-16383 127.0.0.1:7001> cluster slots 1) 1) (integer) 0 2) (integer) 4095 3) 1) "127.0.0.1" 2) (integer) 7000 4) 1) "127.0.0.1" 2) (integer) 7004 2) 1) (integer) 12288 2) (integer) 16383 3) 1) "127.0.0.1" 2) (integer) 7003 4) 1) "127.0.0.1" 2) (integer) 7007 3) 1) (integer) 4096 2) (integer) 8191 3) 1) "127.0.0.1" 2) (integer) 7001 4) 1) "127.0.0.1" 2) (integer) 7005 4) 1) (integer) 8192 2) (integer) 12287 3) 1) "127.0.0.1" 2) (integer) 7002 4) 1) "127.0.0.1" 2) (integer) 7006
-
antirez authored
Instead of having an hardcoded IP address in the node configuration, we autodiscover it via MEET messages for automatic update when the node is restarted with a different IP address. This mechanism was discussed in the context of PR #1782.
-
- 24 Jun, 2014 1 commit
-
-
antirez authored
-
- 23 Jun, 2014 12 commits
-
-
antirez authored
In the initialization test for each instance we used to unregister the old master and register it again to clear the config. However there is a race condition doing this: as soon as we unregister and re-register "mymaster", another Sentinel can update the new configuration with the old state because of gossip "hello" messages. So the correct procedure is instead, unregister "mymaster" from all the sentinel instances, and re-register it everywhere again.
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
Matt Stancliff authored
Some deployments need traffic sent from a specific address. This change uses the same policy as Cluster where the first listed bindaddr becomes the source address for outgoing Sentinel communication. Fixes #1667
-
Matt Stancliff authored
We need to access (bindaddr[0] || NULL) in a few places, so centralize access with a nice macro.
-
antirez authored
-
Matt Stancliff authored
This is hiredis f225c276be7fd0646019b51023e3f41566633dfe This update includes all changes that diverged inside of Redis since the last update. This version also allows optional source address binding for connections which we need for some Sentinel deployments.
-
Matt Stancliff authored
Fixes #1826 (and many other reports of the same problem)
-
Salvatore Sanfilippo authored
Cancel SHUTDOWN if initial AOF is being written
-
antirez authored
-
- 21 Jun, 2014 3 commits
-
-
Matt Stancliff authored
Fixes #1826 (and many other reports of the same problem)
-
antirez authored
-
antirez authored
-
- 20 Jun, 2014 3 commits
- 19 Jun, 2014 5 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
Eventual configuration convergence is guaranteed by our periodic hello messages to all the instances, however when there are important notices to share, better make a phone call. With this commit we force an hello message to other Sentinal and Redis instances within the next 100 milliseconds of a config update, which is practically better than waiting a few seconds.
-
antirez authored
-
antirez authored
Lack of check of the SRI_PROMOTED flag caused Sentienl to act with the promoted slave turned into a master during failover like if it was a normal instance. Normally this problem was not apparent because during real failovers the old master is down so the bugged code path was not entered, however with manual failovers via the SENTINEL FAILOVER command, the problem was easily triggered. This commit prevents promoted slaves from getting reconfigured, moreover we now explicitly check that during a failover the slave turning into a master is the one we selected for promotion and not a different one.
-
- 18 Jun, 2014 3 commits