最近TEAM里面的每个DB都在做高可用失效后的应急方案和处理的文档,要写这个东西我和MONGODB 的DBA 主要要做的有以下内容
1 环境的准备 三台MOGNODB 4.2 社区版本
2 安装成为复制集
3 制定测试计划
测试计划主要从以下几个方面考虑
1 从库DOWN机,对应用程序的影响
2 主库DOWN机对应用程序的影响
3 两个从库DOWN机最应用程序的影响
4 一主一从DOWN机对应用程序的影响
5 全部三台DOWN机后如何恢复,最快让应用可以进行工作
4 测试的方法,写PYTHON程序,通过程序的连接复制集的方式来进行,而不是单机的方式来连接,因为最终我们是要对应用程序负责的.
测试机器的
10.50.132.166 (主库)
10.50.132.167 (从库)
10.50.132.168 (从库)
废话不讲开始
1 一台从库挂掉
在关掉从库后(切断电源后), 应用程序不会被影响 (结论,如果从库挂掉),应用程序的连接是不会被影响的.
从库启动后如果可以追上oplog,则从库会,从库的状态恢复到 SECONDARY
从rs.status() 中可以看到,从库的信息
1 syncingto 这说明 这个从库连接的数据源并不是 10.50.132.166 ,而是另一个从库,这个是MONGODB 的特性, 根据当前的情况自动连接从库先追数据,这样的好处是,如果拉下的数据较多,则对主库的压力会比较小.
结论: MONGODB 从库DOWN 后, 应用连接到复制集中的主库不会有任何影响,并且失效的从库会选择连接到其他从库进行数据的追取. (也有可能直接连接到主库)
2 关闭主库
在关闭主库后, 会根据初期设置的权重,将权重高的,变为主库, 一般10秒中一次进行扫描,直到权重高的从库变为主库(前提是数据必须和其他从库一致)
结论,应用程序不会被影响 (连接到复制集的方式)
在恢复主库的服务后,原主库服务启动后,在数据追平后,会自动切换会主库,这也不会影响到应用.
问题: 如果新主库上已经在运行数据连接的情况下, 会等待写连接完毕后,MONGODB 在进行主从角色的切换.
结论,主库挂掉,对MONGODB 的是没有任何影响的,应用可以继续工作,可能会有闪断的情况.
3 两个从库都DOWN
将两个从库DOWN机后,主库可以进行读取,但已经不能进行写入了, 此时应用连接被 Hang住, 应用程序没有响应,显示TIMEOUT, 读取也无法进行,此时数据库进入无法为应用提供工作的状态
分两种情况,
1 如果从库能恢复至少一台,则数据库系统可以恢复, 见下图
应用系统重新启动户,业务会直接恢复
2 如果无法恢复2台从库的情况下
4 一主一从关闭的情况下,系统的状态与两从DOWN机后的状态一致,无法提供正常的数据库服务.
5 全部机器DOWN 机,则无法提供服务.
这就不用说了
问题来了
在我只有一台MONGODB的情况下,剩余的两台无法工作的情况下,如果恢复业务.
在这样的情况下我们需要两步走
1 修改配置文件, 将replication: 中的 replSetName 注释后
2 重启服务
3 告诉应用修改连接串,重启应用服务
应用就会恢复正常工作见上图
以上就是在MONGODB 出现问题后, 各种情况以及各种处理的意见,最终的目的就是让业务尽快的恢复工作.
那么如果在两台机器恢复后,会怎么样,咱们继续
在打开两台失效的机器后, 失效的两台机器会自动恢复,并且进入集群的模式,
然后在将正在工作的MONGODB 打开复制, 机器就自动加入到复制集群了.
其实我们并不觉得这就可以了, 试问我们在单独工作的机器插入了大量的数据后, 那么这台机器如果在融合到原有的集群中,会是什么状态,能不能将后期插入的数据,同步到失败的两台机器.
我们来做下一步的操作, 将两台失效的机器启动后,两台机器自动重组为集群,然后我们在将原来应在单机的机器修改配置(打开repl的设置),后 这台机器也自动加入到集群中, 但是出现了问题,
出事了 出事了
在此加入集群的曾经是单机的数据库的数据和另外两台机器不一致了
那怎么办
1 关闭已经单机工作的MONGODB
2 将他的数据拷贝到其他两台机器
3 先启动MONGODB 的主库(权重最大的)
2 然后在启动原有的从库们
整体系统恢复
通过思维导图总结一下.
