Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

two slaves which are replicated to one master may have the same IP when use v5.0.3 to build redis cluster service #5849

Open
clareying100 opened this issue Feb 19, 2019 · 3 comments

Comments

@clareying100
Copy link

clareying100 commented Feb 19, 2019

We do Redis upgrade work from v4.0.11 to v5.0.3.
Use command “redis-cli --cluster create host1:port1 ... hostN:portN --cluster-replicas 2” to build Redis cluster service.

  • Our usage scenario:

We build a Redis cluster containing 3 masters and 6 slaves.
In our usage scenario, there are 3 VMs with different IPs and each VM has 3 Redis instances.
So, the redis cluster will have 3 masters, and each master has two slaves. If mark one master and it’s two slaves as one group, then will have 3 groups.
After cluster build successful,
we expect one master and it’s two slaves all with different IP in each group. Also expect when two of the three VMs down, the Redis cluster still can provide service.

  • Test result:

Actual test results are show, there’s high probability that two slaves which are replicated to one master will have the same IP. But this has not appeared in version Redis 4.0.11.
Result show as below:
192.168.1.13:6380> cluster nodes
8a973e82efbda4afcb664539b3a2b827700e1b73 192.168.1.13:6380@16380 myself,master - 0 1550212750000 1 connected 0-5460
180091e5775db8bfc215eea311a7bfaa821c4b54 192.168.1.20:6381@16381 slave 8a973e82efbda4afcb664539b3a2b827700e1b73 0 1550212750915 8 connected
5202b88ace54fc9eada6df32b8c64d7268700eb2 192.168.1.20:6382@16382 slave 8a973e82efbda4afcb664539b3a2b827700e1b73 0 1550212750915 9 connected
da48b6e77d9afb4ad0e906389befc9428358c8db 192.168.1.18:6380@16380 master - 0 1550212750915 4 connected 5461-10922
b6fb8391eaff9ec39b50243adce4671393a4e884 192.168.1.13:6381@16381 slave da48b6e77d9afb4ad0e906389befc9428358c8db 0 1550212750915 4 connected
8be87c36872a73eccfe1de644a909f71cc843734 192.168.1.13:6382@16382 slave da48b6e77d9afb4ad0e906389befc9428358c8db 0 1550212750915 4 connected
f8ae2618b3aa9a5714cdee9544f7f6e01c1de838 192.168.1.20:6380@16380 master - 0 1550212750915 7 connected 10923-16383
2e935a58e4522c3e581e9116c47e00685a7fcab8 192.168.1.18:6381@16381 slave f8ae2618b3aa9a5714cdee9544f7f6e01c1de838 0 1550212750915 7 connected
b6d1ff664367fa815647e0f0ff65a08c9e75b202 192.168.1.18:6382@16382 slave f8ae2618b3aa9a5714cdee9544f7f6e01c1de838 0 1550212750915 7 connected

Each master have his two slave, but these two slaves have the same IP.
If this happens, then the algorithm used in function clusterManagerOptimizeAntiAffinity will not work, no matter how many times you loop.
If this happens, when two of the three VMs down, the Redis cluster will failed and can’t provide service.

  • Summary:

There is no problem when use “redis-trib” command to create Redis cluster service in version 4.0.11, but have this issue when use “redis-cli --cluster” command in v5.0.3.

So I post this ticket to raise this issues. And have a patch to fix it. If you had noticed this issue and have better solution you can ignore it. Thanks.

@artix75
Copy link
Contributor

artix75 commented Feb 20, 2019

@clareying100 I'm going to check it

@artix75
Copy link
Contributor

artix75 commented Feb 20, 2019

@clareying100 Ok, it has been fixed in the PR above.
@antirez Could you merge it? It's quite important, thanks.

@clareying100
Copy link
Author

@antirez @artix75 thank you very much, and when will this can be merged?

JackieXie168 pushed a commit to JackieXie168/redis that referenced this issue Apr 10, 2019
pulllock pushed a commit to pulllock/redis that referenced this issue Jun 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants