theme: condensed-night-purple
已知条件[以下IP为伪造,大体理解即可]
原有redis哨兵地址
- 10.0.0.120:26379
- 10.0.0.121:26379
- 10.0.0.122:26379
新迁移的redis哨兵地址
- 10.0.1.80:26379
- 10.0.1.81:26379
- 10.0.1.82:26379
redis哨兵的域名地址
- redis01-dns.com:26379
- redis02-dns.com:26379
- redis03-dns.com:26379
客户端Go代码实现
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
if sentinelPool, err := (radix.SentinelConfig{}).New(ctx, "test", []string{"redis01-dns.com:26379","redis02-dns.com:26379","redis03-dns.com:26379"}); err != nil {
fmt.Printf("redis sentinel init err,%s", err.Error())
} else {
fmt.Println(sentinelPool.Clients())
}
问题显示
error creating client for "10.0.0.120:26379": dial tcp 10.0.0.120:26379: connect: connection refused
问题产生操作步骤:
运维迁移完机器后,需要对机器进行重启。重启后发现连接被拒绝。
问题排查思路
- 首先沟通运维得知旧机器并未下线,即此刻是 3台要下线的机器还存在DNS映射下吧(个人理解)。当时未及时查看域名映射地址(一大失误)。
排查域名是否有问题:
- 利用dig
dig redis01-dns.com
- 利用 nslookup
nslookup redis01-dns.com
以上均可以看出域名解析无问题,以百度为例 解析出 220.181.38.149,220.181.38.150 两个地址。
- 利用
nc排查是否为网络问题
正常情况
异常情况
若以上排查下来均无问题，可以考虑是否DNS缓存。因当时未直接ping 域名解析IP，导致无法判断此处是否存在问题。
还有一种可能, 三台旧的redis已下线，而三台旧的哨兵机器未下线，导致哨兵机器因无法发现可用的redis的master主节点从而导致客户端去连接的时候访问被拒绝。