红葡萄酒主人在码头环境中成为另一位主人的奴隶

Question

我已经配置了一个主人和两个奴隶的红卫兵。

让我们将这三台机器的设置称为集群。

我在很多码头集装箱上运行了很多集群。在运行时，我管理redis.conf文件和sentinal.conf文件中的IP。

我的问题是:集群-1上的主节点以某种方式变成了集群-2的主节点的奴隶。在集群-1主节点上，我杀死了redis和哨兵服务，删除了slaveof <cluster-2 master ip> 6379，然后用已编辑的conf文件重新启动了redis服务。

我一开始红宝石服务，它就又成了集群2主红宝石的奴隶.

我试着不让任何人从redis-cli内部奴隶，但在几秒钟内，节点再次变成奴隶。

所有这些都是在没有开始哨兵服务的情况下发生的。

这里发生了什么事？还有其他我必须删除的条目吗？

redis.conf

bind 0.0.0.0


protected-mode no

port 6379

tcp-backlog 511


timeout 0

tcp-keepalive 300


daemonize no

supervised no

pidfile "/var/run/redis_6379.pid"

loglevel notice

logfile "/var/log/redis.log"
databases 16


save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes

rdbcompression yes

rdbchecksum yes

dbfilename "dump.rdb"

dir "/"



slave-serve-stale-data yes

slave-read-only yes

repl-diskless-sync no

repl-diskless-sync-delay 5



repl-disable-tcp-nodelay no
slave-priority 100                                                                                                    

appendonly no


appendfilename "appendonly.aof"


appendfsync everysec


no-appendfsync-on-rewrite no


auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

aof-load-truncated yes


lua-time-limit 5000
slowlog-log-slower-than 10000

slowlog-max-len 128


latency-monitor-threshold 0


notify-keyspace-events ""


hash-max-ziplist-entries 512
hash-max-ziplist-value 64

list-max-ziplist-size -2

list-compress-depth 0

set-max-intset-entries 512

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

hll-sparse-max-bytes 3000

activerehashing yes

client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10

aof-rewrite-incremental-fsync yes
slaveof 192.168.60.38 6379 #this comes back again and again

Answer 1

对于任何面临同样问题的人来说。

哨兵的设计是为了自动检测同一网络中的另一个哨兵。

因此，簇-1和簇-2哨兵都能够到达对方。

星系团-1的哨兵变得不忠(双关意)，并重写了第一群红系的红系结构，使其成为群集-2主红系的奴隶。

可能的解决办法；

1. 在每个redis设置之间使用唯一的密码。将使用redis配置中的requirepass。
2. 阻塞不同红系集群之间的通信量。
3. 不要在一起使用哨兵。