[Redis&MongoDB] 如果手动触发 Redis&MongoDB 主从切换?
如何手动触发 redis 主从切换?
要手动触发Redis主从切换,需要在哨兵节点上执行命令。以下是触发主从切换的步骤:
进入哨兵节点服务器的命令行界面。
使用命令
redis-cli -h <sentinel-ip> -p <sentinel-port>
连接到哨兵节点。将<sentinel-ip>
和<sentinel-port>
替换为实际的哨兵节点的IP地址和端口号。执行命令
SENTINEL failover <master-name>
,其中<master-name>
是Redis主节点的名字。哨兵节点会自动进行主从切换过程,并将从节点升级为新的主节点,同时将之前的主节点切换为从节点。
// 哨兵不需要密码认证
$ redis-cli -h <sentinel-ip> -p <sentinel-port> SENTINEL failover <master-name>
使用SLAVEOF命令无法直接实现主从切换,主从切换通常是由Redis的哨兵模式来管理和触发的。
正常情况下,Sentinel 只会在主节点被判定为不可用时才触发故障转移。
然而,SENTINEL failover-force <master-name> 命令绕过了主节点的状态检查,强制触发故障转移操作。无论主节点是否正常,Sentinel 都会选择一个健康的从节点进行升级。
这样做的目的是为了提供一种手动干预的方式,允许管理员在必要时强制进行主从切换。然而,需要注意的是,强制触发主从切换可能会导致数据一致性问题,因为在切换过程中,主节点可能会丢失一些尚未同步到从节点的数据。
强制触发redis主从切换:
$ redis-cli -h <sentinel-ip> -p <sentinel-port> SENTINEL failover-force <master-name>
为什么可以强制触发redis主从切换,背后的原理是什么?
SENTINEL failover-force <master-name> 命令的原理是通过 Redis 哨兵的管理机制来实现强制触发 Redis 主从切换。
Redis Sentinel 是一个分布式系统,由多个 Sentinel 进程组成,它们共同监控和管理 Redis 主从复制集群。Sentinel 进程之间通过消息传递进行通信,并使用选举算法来决定哪个 Sentinel 进程负责监控和管理 Redis 主节点。
当 Sentinel 进程检测到 Redis 主节点故障时,它会选择一个健康的从节点,并将其升级为新的主节点。这个过程称为故障转移(failover)。正常情况下,Sentinel 只会在主节点被判定为不可用时才触发故障转移。
然而,SENTINEL failover-force <master-name> 命令绕过了主节点的状态检查,强制触发故障转移操作。无论主节点是否正常,Sentinel 都会选择一个健康的从节点进行升级。
这样做的目的是为了提供一种手动干预的方式,允许管理员在必要时强制进行主从切换。然而,需要注意的是,强制触发主从切换可能会导致数据一致性问题,因为在切换过程中,主节点可能会丢失一些尚未同步到从节点的数据。
redis 主从哨兵架构, 这个 master-name 在哪里定义的?
在 Redis 主从哨兵架构中,master-name
是在哨兵配置文件中定义的。
在配置文件中,可以使用 sentinel monitor
命令来定义主节点的名称。
这个名称可以随意指定,但需要保证在整个架构中唯一。当哨兵启动时,它会根据这个名称来监视主节点的状态,并根据需要进行故障转移。
在配置文件中,可以以以下方式定义主节点的名称:
sentinel monitor <master-name> <ip> <port> <quorum>
其中:
-
<master-name>
是主节点的名称; -
<ip>
是主节点的 IP 地址; -
<port>
是主节点的端口号; -
<quorum>
是哨兵的投票数量,表示在进行故障转移时,需要多少个哨兵节点同意才能执行转移。
请注意,所有的哨兵节点的配置文件中,master-name
需要保持一致,以确保它们监视的是同一个主节点。
如何手动触发 MongoDB 主从切换?
rs.stepDown()
是 MongoDB 中用于手动触发主节点放弃主节点角色的命令。
当执行这个命令后,当前的主节点会主动放弃主节点的角色,触发主从切换过程。
要手动触发 MongoDB 的主从切换,可以按照以下步骤进行操作:
- 登录到 MongoDB 主节点上的命令行界面或 MongoDB 的管理界面。
- 确认当前主节点的状态,可以使用
rs.status()
命令查看当前的复制集状态。 - 确认当前主节点的状态正常,如健康状态为1,状态为PRIMARY。
- 在备份节点上执行
rs.stepDown()
命令,该命令会导致当前主节点主动放弃主节点的角色,触发主从切换。 - 在切换完成后,使用
rs.status()
命令检查新的主节点是否已经切换成功。
$ mongo --host xx.xx.xx.xx -u xxx -p 'XXX' --port 27017 --authenticationDatabase admin
> rs.status()
> rs.stepDown()
以下是对 rs.stepDown()
使用方法的详细解读:
- 登录到 MongoDB 主节点上的命令行界面或 MongoDB 的管理界面。
- 确保当前登录用户具有管理员权限或复制集的管理权限。
- 在命令行界面中输入
rs.stepDown()
命令,并按回车键执行。 - 当执行
rs.stepDown()
命令后,主节点会发出一个信号,通知其他节点进行选举新的主节点。 - 在主节点放弃主节点角色后,其他节点会开始进行选举,选择一个新的主节点。
- 选举过程可能需要一些时间,取决于复制集中的节点数量和网络状况。
- 最终,新的主节点会被选出,并开始接受客户端的读写请求。
rs.stepDown()
方法在 MongoDB 中可以接受以下可选参数:
-
secondaryCatchUpPeriodSecs
: 指定一个时间段(以秒为单位),在此期间新的主节点等待从节点追赶上来。默认值为0,表示不等待从节点追赶。 -
force
: 如果设置为 true,则强制当前节点放弃主节点角色,即使当前节点的健康状态较差。默认值为 false,表示只有在当前节点健康状态正常时才会放弃主节点角色。
示例用法:rs.stepDown({ secondaryCatchUpPeriodSecs: 60, force: false })
请注意,在大多数情况下,不需要指定参数来执行 rs.stepDown()
命令,使用默认参数即可。
仅在特定情况下,如希望等待从节点追赶上来或强制放弃主节点角色时,才需要使用这些参数。
当使用 rs.stepDown()
方法时,你可以根据需要提供不同的参数。下面是两个示例:
- 例子一:使用默认参数执行
rs.stepDown()
rs.stepDown()
这会导致当前主节点放弃主节点角色,并触发主从切换过程。在这种情况下,不需要提供任何参数。
- 例子二:指定
secondaryCatchUpPeriodSecs
和force
参数
rs.stepDown({ secondaryCatchUpPeriodSecs: 60, force: false })
这个例子中,我们提供了两个参数:
-
secondaryCatchUpPeriodSecs: 60
:指定从节点追赶上来的时间为60秒。在当前主节点放弃主节点角色后,新的主节点会等待60秒,以便其他从节点追赶上来。如果不提供此参数,默认值为0,即不等待。 -
force: false
:设置为 false,表示只有当当前节点的健康状态正常时,才会放弃主节点角色。如果设置为 true,则无论当前节点的健康状态如何,都会强制放弃主节点角色。如果不提供此参数,默认值为 false。
根据你的需求,可以根据具体情况选择是否提供这些参数。
请注意,手动触发主从切换可能会导致服务中断或数据不一致的风险。
在执行此操作之前,请确保已经备份了重要的数据,并且了解风险的影响,最好在非生产环境中先进行测试。