闲聊数据库高可用容灾规划设计

一个系统可能包含很多模块，如数据库、前端、缓存、搜索、消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用的实现可能更加复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，在容灾之外，还要同时考虑方案中数据一致性问题。

3. 数据库主从复制。

这种方案是较经典的数据同步模式，系统采用一个主库和多个从库，主库同步数据库日志到各个从库，从库各自回放日志。它的好处是一个主库可以连接多个从库，能很方便地实现读写分离，同时，因为每个备库都在启动当中，所以备库当中的数据基本上都是热数据，容灾切换也非常快。

3. 自动化管理平台规划

通过数据库自动化管理平台中容灾&灾备监控管理中心可以实现对多个数据中心全局数据容灾、数据灾备的情况进行整体拓扑监控与管理。并且

为了保证数据容灾、数据灾备有效性对数据同步延迟、数据传输流量根据数据中心的链路带宽分配情况定制对应的告警监控。

自动化运维是高可用数据库中的难点，因为企业业务不一定只有一个数据库，可能需要同时管理十几个甚至上百个数据库，如果每一个数据库都配置一个高可用数据库架构，系统则需要保证其中任何一个发生问题以后都可以进行容灾，这无疑给运维带来了极大挑战。

下面提供几个自动化运维方向的思路：

(1) 容灾切换自动化。

要实现容灾切换的自动化，首先需要考虑两个问题：

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

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

(2) 健康状况自动检查。

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

• 第一，复制有没有正常进行，如发送日志时主库与备库之间的连接突然断掉，这时候需要系统时常扫描主备库是否异常;
• 第二，主从延时，如果主从之间的数据延迟较大，那么切换数据库时也会比较麻烦，这方面也可以考虑使用业内比较常用的监控模块如Prometheus等工具定期采集，发现异常状况后及时调整。
• 第三，异常情况自适应调整。以主从延迟为例，一般来说可能是CPU的问题或者IO的问题等，如果是IO的问题，一种办法是将IO调高，这是一种比较好的解决方案，如果IO调高以后发现还是无法降低延时，可以在从库把日志的持久化等级暂时性调低。当然，如果主从之间延迟过大，完全无法调整为正常水平，这时候就要考虑通过一些手段重做从库。

4. 数据库容灾&灾备演练规划

规划通过使用数据库自动化管理平台中的“一键容灾切换”-演练切换、“一键灾备恢复”-数据库恢复模块进行恢复演练操作。

定期容灾演练很有必要。容灾演练就是在平台上跑自己的容灾逻辑，我们需要在不同场景下做切换，看数据有没有丢失、是否保持了数据的一致性等等，因为线上环境非常复杂，可能会有各种莫名其妙的问题导致切换逻辑在发生切换以后结果不一致，所以要通过定期演练把各种可能性降到最低。

总结

高可用架构是数据库运行稳定必不可少的一部分，设计架构时要考虑诸多问题，如数据是否同步、高可用自动切换、自动化运维等等。

当前文章：闲聊数据库高可用容灾规划设计
转载来源：https://www.cdcxhl.com/news34/99184.html

成都网站建设公司_创新互联，为您提供网站设计公司、网页设计公司、软件开发、全网营销推广、动态网站、静态网站

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联