云数据库RDS

    高可用

    服务高可用

    服务高可用由 XMaster、XAgent、Noah 、冷备服务等模块组成。配合7*24小时值班的运维人员负责保障数据链路服务的可用性、数据安全、处理数据库内部的异常以及发生无法自动修复的异常时报警(主动通知运维人员)。

    另外,用户还可以通过在支持多可用区的地域创建实例、采用适当的数据复制方式,进一步提升 云数据库 RDS 服务的高可用性。

    XMaster

    XMaster 模块部署在集群中控机上,接受 XAgent 模块发来的心跳信息(内容为健康状态),分析主节点、热备节点和只读节点的心跳信息,自动发起主备热切换,自动修复各个节点等任务,保障云数据库 RDS 服务的高可用性。

    例如:

    • 主从同步异常中断的自动修复;
    • 主、备、只读节点表级别损坏的自动修复;
    • 主、备、只读节点Crash的现场保存和自动修复;
    • 主节点Crash或网络不可达时自动提升热备节点成为主节点保证服务。
    • XMaster模块还负责把主、备、只读节点的身份变化、状态变化上报给负载均衡和Proxy,保证用户访问到正确的节点,把无法自动修复的异常状态上报给Noah ,通知运维人员尽快介入。

    XAgent

    XAgent模块负责检测云数据库 RDS 服务各节点的健康状态(服务是否正常,CPU、内存、磁盘等资源占用是否正常等)。通过间隔为3秒的心跳信息,将各节点的健康状态报告给XMaster,供XMaster模块判断是否发起主备热切换,自动修复等高可用性维护任务。

    XAgent模块还负责监控没有自动修复的异常状态(如非抖动性网络异常,磁盘使用量超过警戒线,主从同步异常中断、主从延迟过大等),将信息报告给Noah 模块发出报警,通知运维人员尽快介入,保证极端情况下云数据库 RDS 服务的高可用性。

    BCM

    BCM 是监控报警模块,负责接收XAgent上报的异常信息并通过邮件、短信、电话通知运维人员尽快介入,保证极端情况下云数据库 RDS 服务的高可用性。

    冷备服务

    冷备服务周期性全量备份云数据库 RDS 服务数据,与热备节点共同作用保证用户数据的安全。

    高可用各模块关系说明

    2.png

    XMaster模块根据XAgent上报的健康信息发现主节点异常,发起主备热切换。此时用户流量均指向提升上来的新主节点。然后自动修复切换下来的节点。若尝试后无法修复,则将异常信息上报给BCM ,BCM 通知运维人员。

    XMaster模块根据XAgent上报的健康信息发现热备节点主从中断,尝试自动修复后发现无法恢复,则将异常信息上报给BCM ,BCM 通知运维人员。

    多可用区

    多可用区是在单可用区的基础上,将同一地域的多个单可用区组合成的逻辑区域,主、备节点部署在不同的单可用区上。相对于单可用区 云数据库 RDS 服务,多可用区云数据库 RDS 服务可以承受更高级别的灾难。

    例如,单可用区云数据库 RDS 服务可以承受服务器和机架级别的故障,而多可用区云数据库 RDS 服务可以承受机房级别的故障。

    目前多可用区云数据库 RDS 服务不额外收取费用,已开通多可用区地域的用户可以直接购买多可用区云数据库 RDS 服务,也可以利用D云数据库 RDS 服务将单可用区云数据库 RDS 实例迁移至不同的可用区组成多可用区云数据库 RDS 服务。

    注意: 因为多可用区之间存在一定的网络延迟,因此多可用区云数据库 RDS 实例在采用半同步数据复制方案时,对于单个更新的响应时间会比单可用区实例长。这种情况最好通过提高并发量的方式来实现整体吞吐量的提高。

    数据复制方式

    用户可以根据自身业务特点,选择合适的数据复制方式,提高可用性。当前云数据库 RDS for MySQL提供以下两种数据复制方式:

    • 异步复制:异步复制是指当应用发起更新请求,即进行增加、删除、修改数据的操作时,主库完成相应操作后会立即响应应用,同时主库向备库异步复制数据。因此,备库不可用时不会影响主库上的操作。但如果在操作提交完成时,主库恰好出现宕机,此时数据尚未发送给备库,那么备库上将没有已经完成提交的事务修改的数据,因此在备库切换为新主库时,会造成数据丢失。不过总体而言,因主库不可用引起主备库数据不一致的概率较低。
    • 半同步:为了解决异步复制的数据丢失问题,MySQL引入了半同步复制特性。半同步复制指的是在MySQL的复制过程中,事务在主库上提交后,事务日志需要在主库上落盘,传送到至少一个备库上,并在该备库上也完成落盘并通知主库之后,主库上的事务才提交成功。在半同步复制模式下,主库上已完成提交的事务能在至少一个备库上找回,因而解决了异步复制的数据丢失问题。但是需要等待至少一个备库落盘并发送确认,主库上事务提交的时延会变大,因而TPS会下降。主备复制出现异常时,复制方式会退化成异步复制,异常恢复后复制方式才会恢复,因此主库不可用仍然可能会较小概率出现数据不一致。