Py学习  »  DATABASE

MGR复制架构+自动化运维平台,汽车之家MySQL高可用建设实践

DBAplus社群 • 1 年前 • 192 次点击  


作者介绍

陶会祥,2020年加入汽车之家,任职智能数据中心-云平台部,负责之家数据库的运维及RDS产品研发工作,致力于为公司提供安全,稳定,可靠的数据库服务。


前言


MySQL具有开源免费,运维简单,性能好等优点,是在汽车之家使用最多的一种数据库。数据库作为应用的后端存储,承担着数据持久化存储的功能,是应用可以正常对外提供服务的关键组件,数据库的高可用非常重要。


相对于成熟的商业数据库软件,开源的 MySQL高可用需要使用者自己进行设计和研发,本文介绍汽车之家MySQL高可用架构发展历程,建设实践情况。


一、高可用定义及度量


在介绍MySQL高可用前,先介绍下高可用定义及关键度量指标RPO,RTO。


高可用定义:高可用(High Availability,缩写HA)是一个IT术语,指系统无中断执行其功能的能力,代表系统的可用性程度。


高可用度量指标:


  • RPO:RPO(Recovery Point Obejective,恢复点目标)是指业务系统所允许的在灾难过程中的最大数据丢失量,用来衡量容灾系统的数据冗余备份能力。


图1 RPO计算


  • RTO :RTO(Recovery Time Objective,恢复时间目标)是指信息系统从灾难状态恢复到可运行状态所需的时间,用来衡量容灾系统的业务恢复能力。


图2 RTO计算


二、MySQL高可用问题


1、问题定义


MySQL高可用问题:如果MySQL数据库发生宕机故障,是否可以实现数据库服务不中断或者故障快速恢复。即实现数据不丟失(RPO)并且故障恢复时间短(RTO)?


2、MySQL主从架构


故障是难免的,一个可靠的系统需要数据冗余来避免单点故障带来的数据丢失,提升可靠性。


虽然MySQL有MySQL NDB Cluster, PXC(Percona XtraDB Cluster)等集群架构,但是MySQL主从架构因为结构简单且成本较低,是最使用广泛的MySQL架构。MySQL主从架构通过主从复制技术来实现主库的数据冗余,当主库故障可以把服务切换到从库,来避免数据库服务中断。


MySQL主从架构的高可用:


图3 MySQL主从架构


一个典型场景如图3,MySQL使用主从架构对外提供服务。图中主库Master有三个从库分别是slave1,slave2,slave3,若是主库故障,为了恢复DB服务,可以选择一个从库(slave1)成为新主库继续对外提供服务,原slave2,slave3改同步新主库的数据。


3、高可用问题挑战


MySQL是一个有数据有状态的服务,通常主库写入数据,通过异步复制二进制日志到从库执行,来实现主从库的数据一致性。当故障发生时,如何实现数据不丢失,各节点数据一致,业务影响小会有一定难度及挑战。


1)挑战1:如何实现主库突然故障,主库数据不丢失?


假想主库故障突然发生,从库还没有接收到主库的二进制日志,此时就有可能引起数据丢失


2)挑战2:如何实现故障后新主从库架构的搭建及数据一致性保证?


多个从库对主库进行复制,有可能各从库对主库复制有不同的时延,各从库之间如何实现数据一致,各节点如何搭建成新的主从架构?


3)挑战3:如何实现故障自动Failover及业务影响最小?


若DB故障发生,如何让业务影响最小,甚至无感知,需要"自动故障转移"来支持。


4、高可用相关工作


一个真实线上可以使用的MySQL高可用架构需要考虑如下工作。


图4 MySQL高可用相关工作


三、常见的MySQL高可用架构


本节介绍几种常见的MySQL高可用架构。


1、主从复制+VIP


图5 主从复制+VIP


2、主从复制+MHA


MHA(Master High Availability) 是一种相对成熟的MySQL高可用解决方案。MHA是独立于MySQL的第三方软件,当主库故障发生后,MHA会尽最大努力来保证数据不丢失(若原主库可以登录,MHA会传输二进制日志到从库节点并执行),并且完成新主从架构的搭建。


图6 主从复制+MHA


3、MGR复制 + Proxy


MySQL Group Replication(简称MGR)是MySQL5.7版本出现的新特性,提供高可用、高扩展、高可靠,强一致性的MySQL集群服务。MGR架构由若干个节点共同组成一个复制组,一个事务的提交,必须经过组内大多数节点(N / 2 + 1)决议并通过,才能得以提交,解决了传统复制可能的数据不一致的问题。


MGR+Proxy高可用架构:虽然MGR可以在主节点故障选举出新主,但应用层常不能自动修改配置中DB地址为新主IP。可使用MGR+Proxy来实现主节点故障时应用无感应自动切换到新的主节点。


图7 MGR复制+Proxy


四、汽车之家MySQL高可用实践


1、汽车之家MySQL高可用发展历程


汽车之家MySQL高可用发展可以分成三个阶段:


1)主从复制+VIP 时代:2016年前使用传统主从复制+VIP/DNS,主库故障通过VIP自动漂移,DBA手动调用脚本进行主从架构切换及域名切换。


2)主从复制+MHA时代:2016年MHA在汽车之家核心业务开始使用,实现了核心业务的故障自动切换,但是此时并没有自动化高可用平台来管理数据库。


3)MGR+自动化平台时代:2020年MGR高可用架构在汽车之家推广应用,MGR基于paxos协议的组复制技术保证各节点数据一致性,简化了主库故障切换工作。另外数据库自动化高可用平台上线,让汽车之家的MySQL高可用水平得到很大提升。


图8 汽车之家MySQL高可用发展历程


2、汽车之家MySQL高可用运维平台


1)高可用运维平台架构


一个高可用系统需要解决两个问题:如何发现故障?故障发生后如何处理故障?具体到MySQL数据库的高可用,因为故障恢复细节和MySQL架构有较强关联,设计者需要重点考虑三个方面:


  • 故障发现:如何发生准确,快速的发现DB故障,不误报错报。


  • 高可用架构:如何选择合适的MySQL高可用架构来处理故障的数据一致性问题。


  • 故障自动化Failover:如何实现"自动故障转移"来保证DB服务的快速恢复?


图9 MySQL高可用设计


汽车之家MySQL高可用实现架构图:


图10 MySQL高可用实现架构图


汽车之家MySQL高可用由MGR复制架构+监控平台+自动化运维平台三者来实现。


  • MGR高可用架构:MGR使用基于paxos协议的组复制,主库的事务在从库中会至少存在一份记录,从而保证故障时数据不会丢失。并且 MGR主库故障会自动选择新主库,进一步减化了主库故障切换工作。


  • 监控平台:基于Prometheus的监控平台对DB状态实时监控,若是发现主库故障将调用数据库运维平台相关API。


  • 自动化运维平台:运维平台中的高可用模块负责故障的自动Failover。高可用模块会确认DB状态,故障恢复时新DB集群搭建,修改原来主库域名后端DB IP等工作,最终实现了主库故障对应用影响的尽量透明。


图10的高可用架构图,描述了经典环境下MySQL高可用实现。监控平台持续探测主库状态,若连续探测3次均发现主库故障,则调用运维平台的高可用模块API,发起主库切换,可以在2-3分钟内完成FailOver。


2)容器布署MySQL高可用


汽车之家有大量MySQL跑在k8S容器上,容器布署MySQL的高可用实现和物理机布署类似,主要区别是容器MySQL的主库故障监控由MySQL-Operator负责,而不是外部监控平台。


图11 容器布署MySQL高可用实现


容器MySQL-Operator每10秒探测一次MGR主库状态,若连续探测3次均为故障,将调用运维平台的高可用模块API,发起主库切换,通常可以在1-2分钟内完成FailOver。


3、未来规划


汽车之家MySQL高可用建设,未来计划做如下工作:


1)网络抖动或大事务有时会引起MySQL集群的主从库自动切换,计划进一步调优改进。


2)数据库故障智能自愈是一个较热的方向,计划研究并应用实践提升数据库的稳定性。


五、结语


本文介绍了常见的MySQL高可用架构,并重点介绍了汽车之家MySQL高可用体系发展历程,高可用建设实践情况。


汽车之家MySQL高可用使用MGR复制架构+自动化运维平台,实现了物理机及容器MySQL主库故障的自动Failover。若MySQL主库down,可以在2-3分钟内完成主库的故障切换,数据库服务的稳定性得到了很好保障。


作者丨陶会祥

来源丨公众号:之家技术(ID:Autohometech)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn


Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/150884
 
192 次点击