redis多哨兵模式部署 redis哨兵模式需要几个节点

转载

mob64ca1415bcee 2023-08-23 10:48:27

文章标签 redis多哨兵模式部署分布式 redis docker 容器 文章分类 Redis 数据库

文章目录

redis集群总结及哨兵详解

为什么需要集群
redis主从复制
Sentinel哨兵模式

为什么需要哨兵
哨兵的基础知识
怎么确认宕机呢
为什么哨兵至少3个节点
哨兵工作流程
故障切换日志分析
哨兵常用配置
哨兵日志简介

redis集群总结及哨兵详解

为什么需要集群

1、单个redis存在不稳定性。当redis服务宕机了，就没有可用的服务了。

2、单个redis的读写能力是有限的

redis主从复制

主节点Master有且仅有一个，从节点Slave可以有多个

只要网络连接正常，Master会一直将自己的数据更新同步给Slaves，保持主从同步。

redis多哨兵模式部署 redis哨兵模式需要几个节点_redis多哨兵模式部署

主节点Master可读、可写
从节点Slave只读。（read-only）

因此，主从模型可以提高读的能力，在一定程度上缓解了写的能力。因为能写仍然只有Master节点一个，可以将读的操作全部移交到从节点上，变相提高了写能力。

Sentinel哨兵模式

为什么需要哨兵

主从模式的缺陷：
当主节点宕机了，整个集群就没有可写的节点了。

由于从节点上备份了主节点的所有数据，那在主节点宕机的情况下，如果能够将从节点变成一个主节点，是不是就可以解决这个问题了呢？

是的，这个就是Sentinel哨兵的作用

哨兵的基础知识

故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
哨兵至少需要3个实例，来保证自己的健壮性
哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性

怎么确认宕机呢

sdown和odown两种失败状态

sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机
odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机
sdown达成的条件：如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机
odown达成的条件：如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

quorum 是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效

为什么哨兵至少3个节点

哨兵集群必须部署2个以上节点。如果哨兵集群仅仅部署了个2个哨兵实例，那么它的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），如果其中一个哨兵宕机了，就无法满足majority>=2这个条件，那么在master发生故障的时候也就无法进行主从切换。

哨兵工作流程

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QuHjCOyU-1593674842218)(https://i.bmp.ovh/imgs/2020/07/5fdbd58226de96e6.png)]

1 Sentinel集群包括三个sentinel节点sentinel1、sentinel2、seninel3，sentinel集群各节点之间互相监控哨兵运行状态。
2 Sentinel集群各节点分别与Redis主节点进行ping命令，以检查Redis主节点的运行状态。
3 假设Sentinel集群检测到Redis主节点Master宕机，在指定时间内未恢复，则Sentinel集群就会对Redis做故障转移操作。
3.1 首先，Sentinel集群从各slave节点中挑选一台优先级最高的slave节点提升为Master节点。
3.2 其次，新的Master节点向原Master的所有从节点发送slaveof命令，让它们作为新Master的slave节点，并将新的Master节点数据复制数据各个slave节点上，故障转移完成。
3.3 最后，Sentinel集群会继续监视老的Master节点，老的Master恢复上线后，Sentinel会将它设置为新Master的slave节点。
3.4 故障转移后的拓扑图如下所示，在图中，slave节点slave-1被选举成为新的Master的节点。

redis多哨兵模式部署 redis哨兵模式需要几个节点_docker_02

故障切换日志分析

master为140，从节点slave分别为75，236，141
我现在手动删除140节点，模拟master宕机

# 一个新 Sentinel（哨兵） 已经被识别并添加
1:X 01 Jul 2020 07:41:54.867 * +sentinel sentinel c757c2a6d7e488bb4b421e6875c8032442efdb27 10.42.1.142 26379 @ mymaster 10.42.1.140 6379

# 开始新的纪元（每次故障切换的版本号），详解见下文
1:X 01 Jul 2020 07:41:56.949 # +new-epoch 13

# 开始选举领袖
1:X 01 Jul 2020 07:41:56.951 # +vote-for-leader 0fdb8118769d9d4ff83d4576ec327290fd00146c 13

# master和sentinel 都处于主观下线状态
1:X 01 Jul 2020 07:41:57.706 # +sdown master mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:41:57.706 # +sdown sentinel ddb8223728d2f1f9bbb8d30bb3630463a83378a5 10.42.1.140 26379 @ mymaster 10.42.1.140 6379

# 投票投票，判定140客观宕机
1:X 01 Jul 2020 07:41:57.772 # +odown master mymaster 10.42.1.140 6379 #quorum 3/2

# 有情况，延迟failover(故障转移)时间
1:X 01 Jul 2020 07:41:57.772 # Next failover delay: I will not start a failover before Wed Jul 1 07:42:33 2020

# 开始新的纪元
1:X 01 Jul 2020 07:42:33.363 # +new-epoch 14

# 尝试故障转移master
1:X 01 Jul 2020 07:42:33.363 # +try-failover master mymaster 10.42.1.140 6379

# 新一轮选举，开始投票
1:X 01 Jul 2020 07:42:33.365 # +vote-for-leader 58a6c1ddde9afd2ed0e2881c59ce9349759e5d3a 14
1:X 01 Jul 2020 07:42:33.369 # c757c2a6d7e488bb4b421e6875c8032442efdb27 voted for 58a6c1ddde9afd2ed0e2881c59ce9349759e5d3a 14
1:X 01 Jul 2020 07:42:33.369 # 0fdb8118769d9d4ff83d4576ec327290fd00146c voted for 58a6c1ddde9afd2ed0e2881c59ce9349759e5d3a 14
1:X 01 Jul 2020 07:42:33.369 # 04386a502ecfe29d1769ea18eb3d6018b3c10159 voted for 58a6c1ddde9afd2ed0e2881c59ce9349759e5d3a 14

# 赢得指定纪元的选举，可以进行故障迁移操作了
1:X 01 Jul 2020 07:42:33.466 # +elected-leader master mymaster 10.42.1.140 6379

# 故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器
1:X 01 Jul 2020 07:42:33.466 # +failover-state-select-slave master mymaster 10.42.1.140 6379

# 顺利找到适合进行升级的从服务器，选择了141为新的master
1:X 01 Jul 2020 07:42:33.521 # +selected-slave slave 10.42.1.141:6379 10.42.1.141 6379 @ mymaster 10.42.1.140 6379

# 在将指定的从服务器（141）升级为主服务器，等待升级功能完成
1:X 01 Jul 2020 07:42:33.521 * +failover-state-send-slaveof-noone slave 10.42.1.141:6379 10.42.1.141 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:33.587 * +failover-state-wait-promotion slave 10.42.1.141:6379 10.42.1.141 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:34.105 # +promoted-slave slave 10.42.1.141:6379 10.42.1.141 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:34.105 # +failover-state-reconf-slaves master mymaster 10.42.1.140 6379

# 领头（leader）的 Sentinel 向实例发送了 SLAVEOF 命令，为实例设置新的主服务器
1:X 01 Jul 2020 07:42:34.161 * +slave-reconf-sent slave 10.42.0.236:6379 10.42.0.236 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:34.471 # -odown master mymaster 10.42.1.140 6379

# 修改从服务器的复制目标
1:X 01 Jul 2020 07:42:35.107 * +slave-reconf-inprog slave 10.42.0.236:6379 10.42.0.236 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:35.107 * +slave-reconf-done slave 10.42.0.236:6379 10.42.0.236 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:35.173 * +slave-reconf-sent slave 10.42.2.75:6379 10.42.2.75 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:36.160 * +slave-reconf-inprog slave 10.42.2.75:6379 10.42.2.75 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:36.160 * +slave-reconf-done slave 10.42.2.75:6379 10.42.2.75 6379 @ mymaster 10.42.1.140 6379
1:X 01 Jul 2020 07:42:36.218 * +slave-reconf-sent slave 10.42.1.139:6379 10.42.1.139 6379 @ mymaster 10.42.1.140 6379

# 结束故障转移
1:X 01 Jul 2020 07:42:36.218 # +failover-end master mymaster 10.42.1.140 6379

# IP 和地址已经改变
1:X 01 Jul 2020 07:42:36.218 # +switch-master mymaster 10.42.1.140 6379 10.42.1.141 6379

# 所有slaves被重新配置为新master的从节点
1:X 01 Jul 2020 07:42:36.218 * +slave slave 10.42.0.236:6379 10.42.0.236 6379 @ mymaster 10.42.1.141 6379
1:X 01 Jul 2020 07:42:36.218 * +slave slave 10.42.2.75:6379 10.42.2.75 6379 @ mymaster 10.42.1.141 6379
1:X 01 Jul 2020 07:42:36.218 * +slave slave 10.42.1.139:6379 10.42.1.139 6379 @ mymaster 10.42.1.141 6379
1:X 01 Jul 2020 07:42:36.218 * +slave slave 10.42.1.140:6379 10.42.1.140 6379 @ mymaster 10.42.1.141 6379

epoch 的详解

执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的。
如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration

哨兵常用配置

sentinel down-after-milliseconds 该配置设定一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。
sentinel failover-timeout mymaster 若哨兵在配置值内未能完成故障转移操作，则任务本次故障转移失败。
sentinel auth-pass mymaster redispass 如果redis配置了密码，那这里必须配置认证，否则不能自动切换
protected-mode no 解除保护模式，使哨兵可以监控到master和slave

哨兵日志简介

- +reset-master <instance details>：主服务器已被重置。

· +slave <instance details>：一个新的从服务器已经被 Sentinel 识别并关联。

· +failover-state-reconf-slaves <instance details>：故障转移状态切换到了 reconf-slaves 状态。

· +failover-detected <instance details>：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。

· +slave-reconf-sent <instance details>：领头（leader）的 Sentinel 向实例发送了 SLAVEOF 命令，为实例设置新的主服务器。

· +slave-reconf-inprog <instance details>：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。

· +slave-reconf-done <instance details>：从服务器已经成功完成对新主服务器的同步。

· -dup-sentinel <instance details>：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。

· +sentinel <instance details>：一个监视给定主服务器的新 Sentinel 已经被识别并添加。

· +sdown <instance details>：给定的实例现在处于主观下线状态。

· -sdown <instance details>：给定的实例已经不再处于主观下线状态。

· +odown <instance details>：给定的实例现在处于客观下线状态。

· -odown <instance details>：给定的实例已经不再处于客观下线状态。

· +new-epoch <instance details>：当前的纪元（epoch）已经被更新。

· +try-failover <instance details>：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。

· +elected-leader <instance details>：赢得指定纪元的选举，可以进行故障迁移操作了。

· +failover-state-select-slave <instance details>：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。

· no-good-slave <instance details>：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。

· selected-slave <instance details>：Sentinel 顺利找到适合进行升级的从服务器。

· failover-state-send-slaveof-noone <instance details>：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。

· failover-end-for-timeout <instance details>：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。

· failover-end <instance details>：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。

· +switch-master <master name> <oldip> <oldport> <newip> <newport>：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。

· +tilt：进入 tilt 模式。

. -tilt：退出 tilt 模式。

参考资料

redis集群部署

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。