加入收藏 | 设为首页 | 会员中心 | 我要投稿 惠州站长网 (https://www.0752zz.com.cn/)- 办公协同、云通信、物联设备、操作系统、高性能计算!
当前位置: 首页 > 教程 > 正文

一文了解数据库高可用容灾方案的设计与实现

发布时间:2018-09-14 21:07:24 所属栏目:教程 来源:丁顺
导读:副标题#e# 9月15日技术沙龙 | 与东华软件、AWS、京东金融、饿了么四位大咖探讨精准运维! 一个系统可能包含很多模块,如数据库、前端、缓存、搜索、消息队列等,每个模块都需要做到高可用,才能保证整个系统的高可用。对于数据库服务而言,高可用的实现可能

第一,怎样准确判断需要容灾。这是实现自动容灾的基础和前提,它需要结合实际情况讨论和判断。如发生网络波动时,可能有一段时间发现无法连上主库,实际上几秒钟以后整个业务系统又恢复了,如果这时候数据库做容灾的话代价比较大,且容灾后还可能会有额外的风险。所以需要在前期准确判断是否需要容灾,并保证在最需要容灾的时候及时容灾;

第二,容灾切换时,备库数据尽量和主库数据保持一致,否则,就会带来数据丢失的问题。

一文了解数据库高可用容灾方案的设计与实现

针对上述问题,MySQL已经有比较常用方案供参考,老牌的如MHA,还有一种比较新的方案叫Orchestrator,如果大家自己搭建数据库,可以考虑采用这两种方案。

2、健康状况自动检查。健康状况检查需要通过自动监控搭配告警来做,高可用容灾中,最关心的还是高可用数据库的主库和备库数据是否一致,一般情况,导致主从库数据不一致的主要是两点:

第一,复制有没有正常进行,如发送日志时主库与备库之间的连接突然断掉,这时候需要系统时常扫描主备库是否异常;

第二,主从延时,如果主从之间的数据延迟较大,那么切换数据库时也会比较麻烦,这方面也可以考虑使用业内比较常用的监控模块如Prometheus等工具定期采集,发现异常状况后及时调整。

一文了解数据库高可用容灾方案的设计与实现

第三,异常情况自适应调整。以主从延迟为例,一般来说可能是CPU的问题或者IO的问题等,如果是IO的问题,一种办法是将IO调高,这是一种比较好的解决方案,如果IO调高以后发现还是无法降低延时,可以在从库把日志的持久化等级暂时性调低。当然,如果主从之间延迟过大,完全无法调整为正常水平,这时候就要考虑通过一些手段重做从库。

UDB:海量高可用数据库自动化运维

UDB拥有海量的高可用数据库,在自动化运维和管理方面,UDB采用的是高可用容灾集中式自动化管理的方式,通过自研的自动容灾逻辑,进行大规模、高并发的DB自动化容灾。同时,UDB的运维体系还可以做到自动化的问题探测以及问题修复,如自动拉起DB、恢复服务,自动恢复数据同步,自适应流量控制等。此外,UDB还会配合一些高效运维工具和巡检工具做更深层次的问题的发现和解决。

一文了解数据库高可用容灾方案的设计与实现

在UDB高可用运维当中,有几点经验可以跟大家分享:

  • 第一,日常需要做例行巡检,保证高可用数据库的健康。主从延时是导致高可用数据库无法容灾的关键原因之一,这一点一定要在日常运维工作中重视起来;
  • 第二,定期容灾演练很有必要。容灾演练就是在平台上跑自己的容灾逻辑,我们需要在不同场景下做切换,看数据有没有丢失、是否保持了数据的一致性等等,因为线上环境非常复杂,可能会有各种莫名其妙的问题导致切换逻辑在发生切换以后结果不一致,所以要通过定期演练把各种可能性降到最低;
  • 第三,高可用切换需要记录日志,并且在切换失败的时候马上告警。切换日志可以做事后复盘分析,看这个DB是什么时候崩溃做的容灾。进入告警后可以保证第一时间介入并解决,缩短整个DB崩溃对用户的影响时间。
一文了解数据库高可用容灾方案的设计与实现

四、总结

(编辑:惠州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读