Lachim / redis

Automatically exported from code.google.com/p/redis
2 stars 0 forks source link

Slave very slow if set as SLAVEOF an unreachable master #550

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Tested on Redis 2.2.6 and 2.2.7 on Linux.

Oses: Ubuntu and Debian 64 bit

What is the problem you are experiencing?

Say you have a slave and you want to redirect it to a master, either when 
booting from config file or with a SLAVEOF command.  It's okay for this slave 
to serve stale data.
Now for some reason that master is not available.
Redis will become VERY VERY VERY slow, although slightly responsive.
example:
fire up a fresh instance.
redis> INFO
<.... snip snip>
role:master
<.... snip snip>

redis> SLAVEOF 10.0.0.99 6379
OK
(3.01s)
redis> set foo bar
OK
(1.91s)
redis> get foo
"bar"
(1.65s)

and the server log:
[27121] 18 May 22:27:10 - 1 clients connected (0 slaves), 798848 bytes in use
[27121] 18 May 22:27:10 * Connecting to MASTER...
[27121] 18 May 22:27:13 # Unable to connect to MASTER: No route to host
[27121] 18 May 22:27:14 * Connecting to MASTER...
[27121] 18 May 22:27:16 # Unable to connect to MASTER: No route to host
[27121] 18 May 22:27:17 * Connecting to MASTER...
[27121] 18 May 22:27:20 # Unable to connect to MASTER: No route to host
[27121] 18 May 22:27:21 * Connecting to MASTER...

It gets even worse if you specify an IP outside your immediate netmask.
I think redis should attempt this in a non blocking manner, and/or pad the 
retries.

Original issue reported on code.google.com by dvir...@gmail.com on 18 May 2011 at 7:29

GoogleCodeExporter commented 8 years ago
I add my vote to this issue.

This issue can potentially bring down a site as the response time for each 
request jumps from 500ms to anywhere between 20-60 seconds. Each redis call to 
the slave takes around 20 seconds when the master is not reachable. It beats 
the whole purpose of using slaves.

Original comment by naren.ch...@gmail.com on 16 Nov 2011 at 2:12

GoogleCodeExporter commented 8 years ago
Hi, this is fixed in 2.4, and this bug tracking system is no longer in use ;) 
We moved to github.

Original comment by anti...@gmail.com on 16 Nov 2011 at 11:44