首页
数据库

分类

当前位置: 云海天教程网 > 技术新闻 > 数据库 >正文

mongodb在双活(主备)机房的部署方案和切换方案设计

更新时间:2021-07-19  作者:佚名   来源: 网络转载

mongodb在双活(主备)机房的部署方案和切换方案设计

1. 概述

现在很多高可用系统为了应对极端情况,比如主机宕机、网络故障以及机房宕机等灾难的发生,通常会部署主备架构(双机房),或者双活架构(双机房),甚至多活架构(三个机房或者以上),mongodb天然就适合部署双机房或者多机房,但是在发生机房宕机灾难时,也会遇到无法选举主节点的问题,本文重点讨论在主备或者双活架构下的mongodb的部署方案和切换方案,下文中的讨论以主备架构为例(双活同理)。

2. 主备架构网络部署图

在主备架构部署方案中,用户请求都是路由到主机房,备用机房无用户请求,为了简化示意,这里先把cdn、dns、waf等部分略去,重点突出应用和mongo集群内部节点的部署结构,如下图:

mongodb在双活(主备)机房的部署方案和切换方案设计

从上图可以看到,负载均衡和应用服务部分都是主备架构,mongodb集群是一体的(两边都会处理请求),没有主备之分,只是部署在两个机房而已。

当然,这种方式下,mongodb集群的资源利用率会高一些,不存在上层备用机房的应用服务的资源闲置浪费的问题。

3. mongodb的主备架构痛点

在主备架构环境中,mongodb的高可用部署方案,推荐复制组内的节点数是奇数(比如3个节点,1主2从),此时存在一个机房部署2个节点,一个机房部署1个节点,当部署2个节点的机房宕机时,由于另外一个机房只有1个节点,而mongodb的选举协议是raft一致性协议,此时是无法选举出主节点的(要求存活节点数大于原节点数的1/2),导致mongodb服务的不可用,示意图如下:

mongodb在双活(主备)机房的部署方案和切换方案设计

 

4. mongodb主备部署方案

 针对章节3中遇到的问题,我们调整了部署方案,即在备用机房准备一个备用节点,平时是不启动的,仅在主机房灾难发生时,才启动该备用节点,示意图如下:

mongodb在双活(主备)机房的部署方案和切换方案设计

 

5. mongodb的主备切换方案

部署方案已经有了,下面谈一下主备切换方案,当主机房发生灾难时,我们要解决两个问题:

1. 怎么启动先前的备用节点。

2. 怎么让刚刚启动的备用节点加入到复制组中,否则是无法参与主节点选举的。

启动备用节点

在备用节点上准备好启动脚本,然后使用运维软件(例如saltstack)发送启动命令,即可启动备用节点。

备用节点加入复制组

 我们知道如果要把一个新的节点加入复制组,是需要在主节点执行rs.add命令的,但是在灾难发生时,由于还没有主节点,是无法使用这个办法的,因此需要换一个思路,即让备用节点“替换”原主机房的从节点,这里的“替换”是指让复制组的其他成员认为该备用节点,就是原来的从节点,技术方案如下:

1. 首先复制组内的成员,在加入复制组时,使用域名替换ip的方式,例如:rs.add("shardA1.mongodb.net:27017"),同时修改mongodb集群所有服务器的/etc/hosts文件,配置shardA1.mongodb.net和IP的映射关系。

2. 在灾难发生时,先把mongodb集群内所有服务器的/etc/hosts中shardA1.mongodb.net对应的IP修改为备用节点的IP,再启动备用节点,此时复制组内的其他节点能快速连上新的节点。

解释一下,为什么把域名和IP的映射关系配置到hosts文件而不是配置到dns服务器,主要是考虑到修改hosts文件生效更快,从而快速选举出主节点。

小结

1. 该方案比较大的亮点是通过修改/etc/hosts文件的方式,让新的节点可以加入集群,从而快速完成主节点选举。

2. 该方案是一个比较通用的方案,适合很多分布式的系统使用,比如zookeeper等。

当然,在实施时,需要考虑主备双向切换,主备切换后监控原主机房的原从节点是否被启动等异常情景。

以上方案有任何不妥之处,欢迎斧正。

上一篇:vue实现可改变购物数量的购物车 下一篇:Java实现普通类注入service对象
小编推荐
快速导航更多>>
JavaScript 教程 HTML5 教程 CSS3 教程 jQuery 教程 Vue.js 教程 Node.js 教程 SQL 教程 C 教程 PHP 教程 Linux 教程 Docker 教程 Nginx 教程 Python 教程 Java 教程

云海天教程网 版权所有

陕ICP备14013131号-3