Very large Sentinel deployments require a crazy amount of connections.

[antirez]

From redis-db ML discussion, an user explained the issue another user was having:

---

陈李军 lijunli2598@gmail.com via googlegroups.com
Jan 5 (1 day ago)
Reply
to redis-db
en, i have the same issue。
it had more than 36 * 36 and 36 * 324 connetions in the setup。

my setup:
15 sentinels
300 redis (150 masters + 150 slaves)

per sentinel setup two connection(one cmd, one pubsub) to every redis. so, every redis has 15 * 2 connnetions, every sentinels have 300 *2 connections.

also in sentinel, for every master struct sentinelRedisInstance, there is a sentinels refer to other sentinels in every master, and each one of them have a cmd connection from this sentinel。
so the connections should plus 150 * 14 connections per sentinel。@antirez i think this is the problem, it should be just 14 connections instead of num_other_sentinels * num_masters。

so in my setup，there is at least 300 * 15 * 2 + (300 * 2 + 150 * 14) * 15 connetions, this is too much to handle.

[MOON-CLJ]

hi,@antirez, i'm glad to see the Sentinel-32 branch backport to 2.8 unstable. it's the feature that we really look forward to, we will test it in our Integration test, just give us some time, we will give you feedback.

[antirez]

Thanks @MOON-CLJ, unfortunately it will not be possible to port connection sharing to Redis 2.8 or 3.0, it is too much new code, but the good thing is that you'll be able to use the unstable branch of Sentinel if it works well for you in order to monitor 2.8 Redis instances. In the next days I'll continue the work on unstable as we discussed in the past: changes to the algorithm, better desync to avoid split brain conditions, and so forth. If there are little changes which are mostly harmless that improve things a lot, I may back port selected commits into 2.8 / 3.0. Thanks!

p.s. closing this issue since should be now resolved into unstable (Sentinel-32 branch no longer exists, I merged into unstable).

[MOON-CLJ]

@antirez great!