27381 Commits

Author SHA1 Message Date
antirez
0faed417e5 Cluster: improve anti-affinity algo in redis-trib.rb.
See #3462 and related PRs.

We use a simple algorithm to calculate the level of affinity violation,
and then an optimizer that performs random swaps until things improve.
2018-01-18 11:44:19 +01:00
antirez
37d26d689f Remove useless comment from serverCron().
The behavior is well specified by the code itself.
2018-01-17 11:23:41 +01:00
antirez
e1e0bbe04d Remove useless comment from serverCron().
The behavior is well specified by the code itself.
2018-01-17 11:23:41 +01:00
antirez
dbc3625a80 Remove useless comment from serverCron().
The behavior is well specified by the code itself.
2018-01-17 11:23:41 +01:00
Salvatore Sanfilippo
6c925586dc Merge pull request #4546 from hqin6/unstable
fixbug for #4545 dead loop aof rewrite
2018-01-17 11:21:55 +01:00
Salvatore Sanfilippo
a18e4c964e
Merge pull request #4546 from hqin6/unstable
fixbug for #4545 dead loop aof rewrite
2018-01-17 11:21:55 +01:00
Salvatore Sanfilippo
a28f3fc568 Merge pull request #4546 from hqin6/unstable
fixbug for #4545 dead loop aof rewrite
2018-01-17 11:21:55 +01:00
heqin
a5a5fc6927 fixbug for #4545 dead loop aof rewrite 2018-01-17 18:08:30 +08:00
heqin
3d3faa0a19 fixbug for #4545 dead loop aof rewrite 2018-01-17 18:08:30 +08:00
heqin
28405f1f75 fixbug for #4545 dead loop aof rewrite 2018-01-17 18:08:30 +08:00
Salvatore Sanfilippo
e1ac223e27 Merge pull request #4609 from Qinch/unstable
fix assert problem in ZIP_DECODE_PREVLENSIZE macro
2018-01-17 10:45:11 +01:00
Salvatore Sanfilippo
81401878de
Merge pull request #4609 from Qinch/unstable
fix assert problem in ZIP_DECODE_PREVLENSIZE macro
2018-01-17 10:45:11 +01:00
Salvatore Sanfilippo
d19edaf43f Merge pull request #4609 from Qinch/unstable
fix assert problem in ZIP_DECODE_PREVLENSIZE macro
2018-01-17 10:45:11 +01:00
antirez
3d176c3833 Hopefully more clear comment to explain the change in #4607. 2018-01-16 15:52:13 +01:00
antirez
b23927b240 Hopefully more clear comment to explain the change in #4607. 2018-01-16 15:52:13 +01:00
antirez
299e560a2e Hopefully more clear comment to explain the change in #4607. 2018-01-16 15:52:13 +01:00
qinchao
1fdfc1a837 fix assert problem in ZIP_DECODE_PREVLENSIZE
, see issue: https://github.com/antirez/redis/issues/4587
2018-01-16 22:43:06 +08:00
qinchao
1e0e168570 fix assert problem in ZIP_DECODE_PREVLENSIZE
, see issue: https://github.com/antirez/redis/issues/4587
2018-01-16 22:43:06 +08:00
qinchao
f2db112964 fix assert problem in ZIP_DECODE_PREVLENSIZE
, see issue: https://github.com/antirez/redis/issues/4587
2018-01-16 22:43:06 +08:00
Salvatore Sanfilippo
40166ec44b Merge pull request #4607 from oranagra/psync2_backlog
PSYNC2 fix - promoted slave should hold on to it's backlog
2018-01-16 15:32:58 +01:00
Salvatore Sanfilippo
0cc43760d7
Merge pull request #4607 from oranagra/psync2_backlog
PSYNC2 fix - promoted slave should hold on to it's backlog
2018-01-16 15:32:58 +01:00
Salvatore Sanfilippo
887e242cea Merge pull request #4607 from oranagra/psync2_backlog
PSYNC2 fix - promoted slave should hold on to it's backlog
2018-01-16 15:32:58 +01:00
Oran Agra
12f7ed3bb5 PSYNC2 fix - promoted slave should hold on to it's backlog
after a slave is promoted (assuming it has no slaves
and it booted over an hour ago), it will lose it's replication
backlog at the next replication cron, rather than waiting for slaves
to connect to it.
so on a simple master/slave faiover, if the new slave doesn't connect
immediately, it may be too later and PSYNC2 will fail.
2018-01-16 10:10:42 +02:00
Oran Agra
689b64c3ad PSYNC2 fix - promoted slave should hold on to it's backlog
after a slave is promoted (assuming it has no slaves
and it booted over an hour ago), it will lose it's replication
backlog at the next replication cron, rather than waiting for slaves
to connect to it.
so on a simple master/slave faiover, if the new slave doesn't connect
immediately, it may be too later and PSYNC2 will fail.
2018-01-16 10:10:42 +02:00
Oran Agra
09680b7c6f PSYNC2 fix - promoted slave should hold on to it's backlog
after a slave is promoted (assuming it has no slaves
and it booted over an hour ago), it will lose it's replication
backlog at the next replication cron, rather than waiting for slaves
to connect to it.
so on a simple master/slave faiover, if the new slave doesn't connect
immediately, it may be too later and PSYNC2 will fail.
2018-01-16 10:10:42 +02:00
zhaozhao.zz
410a7d4413 aof: format code and comment 2018-01-15 13:01:03 +01:00
zhaozhao.zz
1b8eec3e53 aof: format code and comment 2018-01-15 13:01:03 +01:00
zhaozhao.zz
1ebec13091 aof: format code and comment 2018-01-15 13:01:03 +01:00
antirez
4b49dbfab3 Put more details in the comment introduced by #4601. 2018-01-15 12:50:08 +01:00
antirez
c45366be0a Put more details in the comment introduced by #4601. 2018-01-15 12:50:08 +01:00
antirez
402053e9fe Put more details in the comment introduced by #4601. 2018-01-15 12:50:08 +01:00
Salvatore Sanfilippo
e448ff1dc2 Merge pull request #4601 from soloestoy/fix-memoryleak-for-lazy-server-del
lazyfree: fix memory leak for lazyfree-lazy-server-del
2018-01-15 12:43:55 +01:00
Salvatore Sanfilippo
1ed5ac7ce5
Merge pull request #4601 from soloestoy/fix-memoryleak-for-lazy-server-del
lazyfree: fix memory leak for lazyfree-lazy-server-del
2018-01-15 12:43:55 +01:00
Salvatore Sanfilippo
bcb5bc6742 Merge pull request #4601 from soloestoy/fix-memoryleak-for-lazy-server-del
lazyfree: fix memory leak for lazyfree-lazy-server-del
2018-01-15 12:43:55 +01:00
zhaozhao.zz
bc09b1a969 lazyfree: fix memory leak for lazyfree-lazy-server-del 2018-01-15 00:45:37 +08:00
zhaozhao.zz
0517ab8397 lazyfree: fix memory leak for lazyfree-lazy-server-del 2018-01-15 00:45:37 +08:00
zhaozhao.zz
3f7e0f708f lazyfree: fix memory leak for lazyfree-lazy-server-del 2018-01-15 00:45:37 +08:00
Salvatore Sanfilippo
f0d3240328 Merge pull request #4575 from soloestoy/bugfix-benchmark
redis-benchmark: bugfix - handle zero liveclients in right way
2018-01-12 17:43:01 +01:00
Salvatore Sanfilippo
aeeb747796
Merge pull request #4575 from soloestoy/bugfix-benchmark
redis-benchmark: bugfix - handle zero liveclients in right way
2018-01-12 17:43:01 +01:00
Salvatore Sanfilippo
9e2a305918 Merge pull request #4575 from soloestoy/bugfix-benchmark
redis-benchmark: bugfix - handle zero liveclients in right way
2018-01-12 17:43:01 +01:00
Salvatore Sanfilippo
2e51347925 Merge pull request #4581 from dvirsky/module_unlink
Added RM_UnlinkKey - a low level analog to UNLINK command
2018-01-12 17:41:09 +01:00
Salvatore Sanfilippo
72187fa8a5
Merge pull request #4581 from dvirsky/module_unlink
Added RM_UnlinkKey - a low level analog to UNLINK command
2018-01-12 17:41:09 +01:00
Salvatore Sanfilippo
86fce15f71 Merge pull request #4581 from dvirsky/module_unlink
Added RM_UnlinkKey - a low level analog to UNLINK command
2018-01-12 17:41:09 +01:00
antirez
bcfdd6b138 Merge branch 'unstable' of github.com:/antirez/redis into unstable 2018-01-12 17:16:38 +01:00
antirez
a5b6bc2bd7 Merge branch 'unstable' of github.com:/antirez/redis into unstable 2018-01-12 17:16:38 +01:00
antirez
cb00284d6e Merge branch 'unstable' of github.com:/antirez/redis into unstable 2018-01-12 17:16:38 +01:00
Salvatore Sanfilippo
437bccb8ac Merge pull request #4586 from gnuhpc/fix-crashlog-typo
Fix a typo(maybe instruction?) in crash log
2018-01-12 17:16:12 +01:00
Salvatore Sanfilippo
71914387ba
Merge pull request #4586 from gnuhpc/fix-crashlog-typo
Fix a typo(maybe instruction?) in crash log
2018-01-12 17:16:12 +01:00
Salvatore Sanfilippo
ccb1d5c533 Merge pull request #4586 from gnuhpc/fix-crashlog-typo
Fix a typo(maybe instruction?) in crash log
2018-01-12 17:16:12 +01:00
antirez
b686b085ed Fix getKeysUsingCommandTable() in the case of nagative arity.
This fixes a crash with Redis Cluster when OBJECT is mis-used, because
getKeysUsingCommandTable() will call serverPanic() detecting we are
accessing an invalid argument in the case "OBJECT foo" is called.

This bug was introduced when OBJECT HELP was introduced, because the key
argument is set fixed at index 2 in the command table, however now
OBJECT may be called with an insufficient number of arguments to extract
the key.

The "Right Thing" would be to have a specific function to extract keys
from the OBJECT command, however this is kinda of an overkill, so I
preferred to make getKeysUsingCommandTable() more robust and just return
no keys when it's not possible to honor the command table, because new
commands are often added and also there are a number with an HELP
subcommand violating the normal form, and crashing for this trivial
reason or having many command-specific key extraction functions is not
great.
2018-01-12 11:26:29 +01:00