加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 教程 > 正文

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

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

问题:默认情况下,MySQL的复制是异步的,主库将新生成的日志发送给各从库后,无需等待从库的ack回复(从库将接收到的日志写进relay log后,才会回复ack),直接就认为这次DDL/DML成功了。但在极端情况下,如主库刚提交日志,其他从库还没有接收到相关日志时,数据库发生故障,此时,该日志的内容就会全部丢失。

改进措施:半同步复制机制。半同步复制是指主库在将新生成的日志发送给各从库前,需发送日志到一个(默认)从库,等待从库返回ack信息后,主库再提交日志发送给各从库,这就防止了上述情况下的数据丢失。半同步复制是一种提升数据一致性的有效方式,也是比较关键的技术。

方案四:数据库高可用集群

前面三种方案主要是通过日志的复制模式实现高可用,第四种方案则是基于一致性算法来做数据的同步,数据库提供多节点一致性同步机制,利用该机制构建多节点同步集群。这种方式比较经典的案例包括MGR(MySQL Group Replication)和Galera等,最近业内也有一些类似的尝试,如使用一致性协议算法,自研高可用数据库的架构等。

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

以上示意图有五个节点,他们之间是构建成了一个一致性的同步集群,客户端可以读写其中的任何一个节点,任意一节点写入,其他节点都能够将数据进行同步,因此,理论上每个节点都可以进行读写操作。这种方式的容灾实现也比较简单,假设第二个节点出现故障,系统只需要断开客户端对第二个节点的访问路径,其他节点照常访问就可以了,这也是业界近年来比较流行的高可用集群方案。

UCloud高可用数据库解决方案UDB

UCloud对比了业内的各解决方案的优劣点,综合了原生MySQL兼容,不同版本、不同应用场景的覆盖等多种因素,最终选择采用基于数据库主从复制的方式实现高可用架构,并在原架构基础上,使用双主架构、半同步复制、采用GTID等措施进行了系列优化,保证数据一致性的同时,实现日志的自动寻址。

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

如上图所示,最底层为数据层,使用了双主架构,主库与备主库之间通过半同步的方式实现数据同步,整个数据层是双主架构+半同步架构的模式。中间层有一个代理服务器Proxy,Proxy将流量导入到双主数据库的主节点,架构使用了GTID的模式,方便从库自动寻址。

系统的容灾切换也非常简单,数据库崩溃前,Proxy将流量导到主DB上,发生容灾以后,只需要把Proxy从左边Master导到右边的Slave,即可快速完成切换。

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

三、高可用数据库的自动化运维

自动化运维的重点方向

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

那么,如何同时管理大量高可用数据库,让他们都可以进行容灾呢?这里有一些自动化运维方向的思路:1、容灾切换自动化;2、高可用数据库运行状况监控;3、健康状况自动检查和问题修复。

1、容灾切换自动化。要实现容灾切换的自动化,首先需要考虑两个问题:

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

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

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

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

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

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

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

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

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

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

(编辑:核心网)

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

热点阅读