MySQL数据库高可用架构探索
如果无法正常显示，请先停止浏览器的去广告插件。
1. MySQL数据库高可用架构探索
演讲人：郑增权
2. 关于本人及公司
郑增权 上海爱可生南区 项目技术负责人
演讲主题 MySQL数据库高可用架构探索
⚫ 参与过多家大型客户的数据库架构方案设计 ⚫ 开源方案：MySQL MGR + MySQL ROUTER
⚫ 维护超过上千套数据库实例 ⚫ 商用方案：爱可生云树®DMP 数据库集群管理平台
⚫ 专注于开源数据库技术的探索与实践
⚫ 在数据库建设、迁移、故障处理和调优等方面具有一定经验
基于 某运营商-智慧营业厅系统 业务需求
上海爱可生 开源数据库解决方案和服务提供商
⚫ 为企业提供开源数据库的整体解决方案与技术服务
⚫ 客户覆盖金融、电信、能源、零售、制造业等行业
提供两个高可用方案以供选择
描述两个方案如何实现数据一致性保障
及其在网络隔离场景下的表现
阐明实现一个数据库高可用解决方案的主要思路
3. 1.业务背景
2.架构选型
目
录
CONTENTS
3.数据一致性保障
4.网络隔离场景下的高可用保障
5.架构优劣性对
比
6.选型结论
4. 01
业务背景
5. 业务背景
1、业务RTO&RPO要求
a)
不一定能查到最新的数据(保障业务连续性，需优先保证业务可用，可容忍低延迟)
b) 数据库需保障数据最终一致性
2、机房要求
a) 应用不跨机房访问数据库
b) 将跨机房访问的请求交由数据库中间件完成
RPO = 0 ，RTO < 30S
3、双机房网络隔离切换演练要求
a) 在双机房切换演练过程中，保证数据从同一个主库写入（避免脑裂）
6. 02
架构选型
7. 架构选型
什么是MGR？
• 全称：MySQL Group Replication
• MySQL 5.7.17 发布的高可用解决方案
• 单主模式
MySQL
Primary
• 多主模式
MGR
• 是 MySQL 自带的一个插件，具备强一致、高容错等特性。
• 由最少3个server节点共同组成，基于Paxos协议和原生复制
的分布式集群,每个server都有完整的副本。
MySQL
Secondary-1
MySQL
Secondary-2
8. 架构选型
方案一：MySQL MGR + MySQL ROUTER
1. MySQL ROUTER ：是MySQL官方提供的一个轻量级中间件，位于应用与MySQL服务器之间,主要用于解决MySQL集群的高可用、读写分离等问题。
2. A、B双机房，应用和MySQL ROUTER同主机部署，MySQL ROUTER 可自动识别MGR集群中的Primary节点。
3. 业务直连MySQL ROUTER 通过6446和6447端口将写和读操作下发到对应的节点。
9. 架构选型
什么是爱可生云树®DMP 数据库集群管理平台？
爱可生多数据库自动化运维管理平台(简称“云树DMP”)是一
款针对MySQL、Redis、MongoDB、Oracle、TiDB 等主流数据库
的专业运维管理平台。旨在帮助数据库管理员（DBA）完成日常的数
据库运维操作，解决企业内部复杂的数据库管理效率瓶颈问题，提供
集群化、自动化、服务化的技术能力，帮助企业快速建立“高可靠、
高性能、高效率、易使用”的数据库全维度管理体系。
大体量自动化
部署
统一资源管理
备份恢复编排
企业级监控告警
产品特点
金融级数据库
高可用
数据库全生命周
期管理
10. 架构选型
双机房 - 绑定“同园区高可用策略”以满足业务需求
方案二：爱可生DMP平台主备高可用架构
• 同城双数据中心，光纤直连。
• 应用单活
• 数据层热切换（可绑定同园区或RPO、RTO ）。
（本方案采用：同园区高可用策略）
• 故障自动切换，数据零丢失。
11. 03
数据一致性保障
12. 数据一致性保障
⚫ MySQL的数据一致性保障需满足如下两因素
1. 完整接收数据
2. 完整应用数据
⚫ MySQL的复制架构演进
13. 数据一致性保障 （MySQL MGR
）
MGR如何保障完整接收数据？
• MGR采用XCom(一个Paxos变体)组通讯引擎，可
以让数据被大多数节点接收确认后才返回成功
的消息。
• 因此对于MGR架构而言，发生切换时，是可以
保障新主接已接收到完整的数据。
14. 数据一致性保障 （DMP主备高可用
）
半同步：after_commit
• MySQL 5.5 & 5.6 默认：rpl_semi_sync_master_wait_point = after_commit
• 主库先提交事务，在接收到从库的ACK后将commit结果返回给客户端。
• 此模式下，当客户端事务在主库提交后，在获取从库ACK 的过程中若主
库发生crash，如果有事务尚未发送至从库，主从切换后，这部分在主
库上已经提交的事务可能会丢失。
15. 数据一致性保障 （DMP主备高可用
）
半同步：after_sync
• MySQL 5.7默认：rpl_semi_sync_master_wait_point = after_sync
• 主库等待从库反馈已写入relay log的ack后，再提交事务并返回
commit OK的结果给客户端。
• 即使主库出现crash，所有在主库上已经提交的事务都已经同步
到slave的relay log中,保障了主从数据的一致性。
DMP如何保障完整接收数据？
• DMP采用主备(半同步+ after_sync模式)
• rpl_semi_sync_master_timeout = 30S
• 因此可以保证在主备切换时，新主可以接收到完整的数据。
16. 数据一致性保障 （MySQL MGR
）
MGR如何保障完整应用数据？
• MySQL 8.0.14 引进参数 group_replication_consistency 用于控制组提交的事务一致性保障，以下为两个常用值：
• EVENTUAL：发生切换后，新主不会等待旧主事务应用完成，会造成读取旧数据，以及可能导致新的冲突的rw事务
回滚，在 MySQL 8.0.14 版本发布前，此参数为默认值。
• BEFORE_ON_PRIMARY_FAILOVER：新主在应用完旧主积压的数据之前，新的RO/RW事务都将被阻塞(根据延迟大
小，阻塞业务的时间不一定)。
17. 数据一致性保障 （DMP主备高可用
）
DMP 如何保障完整应用数据？
• DMP会根据左侧流程判断数据是否被完整应用及
进行数据补偿。
• RPO 及 RTO 高可用策略则能根据业务需求在完整
应用数据上提供不同保障。
18. 数据一致性保障 （DMP主备高可用
）
DMP 如何保障完整应用数据？
数据一致性优先(RPO)
• 切换时允许新主节点丢失的事务数（默认为0）Level分为P和PE两个级别:
• P级别表示在实际状态满足RPO要求时执行自动切换
• PE级别表示在实际状态无法满足RPO要求时需要人工干预，将不会自动切换
• 配置方法：在【添加模板】中，选择切换策略为RPO:
• 在P级别和PE级别中填入数字，单位为秒，英文逗号分隔数字表示多个等级
• 例如：【RPO P级别】：20, 60, 600 表示将RPO分成P1，P2，P3，P4 四个等级
• 描述信息在DMP界面动态显示。其配置行为如右：
19. 数据一致性保障 （DMP主备高可用
）
DMP 如何保障完整应用数据？
服务连续性优先(RTO)
• 切换时允许备节点最多等待多久切换成主节点（默认是10分钟，600秒）Level分为T和
TE两个级别：
• T级别表示在实际状态满足RTO要求时执行自动切换
• TE级别表示在实际状态无法满足RTO要求时需要人工干预，将不会自动切换
• 配置方法：在【添加模板】中，选择切换策略为RTO，在【RTO T级别】填入数字，单位
为秒，英文逗号分隔数字表示多个等级。
• 例如：例如：【RTO T级别】：20, 60, 600 表示将RTO分成 T1，T2，T3 三个等级，描述
信息在DMP界面动态显示。
• 注：TE级别不允许用户自定义，默认为T级别最后一级别的数值，单位秒，表示数据丢
失超过极限时间。其配置行为如右：
20. 04
网络隔离场景下的高可用保障
21. 网络隔离场景下的高可用保障
我们将整个业务访问流程分为如下4层
• 业务层跨数据中心负载均衡SLB可实现跨数据中心
的流量切换，将流量发送给应用层。
• 应用集群连接中间件层
• 中间件层连接数据库层，以此实现对数据库的读
写操作。
22. 网络隔离场景下的高可用保障 （同机房MGR架构网络隔离场景
）
业
务
层
跨
数
据
中
心
负
载
均
衡
S
L
B
中间件层
应用层
数据库层
NGINX
APPLICA
TION
MySQL
Primary
MySQL ROUTER
Data Center
APPLICA
TION
Read
\
wr ite
splitting
J
D
B
C
MySQL ROUTER
MySQL
Secondary-1
MySQL
Secondary-2
APPLICA
TION
NGINX
MySQL ROUTER
• 若应用访问到的MySQL ROUTER无法正常访问MySQL Primary节点 • MySQL ROUTER与应用分别部署于同一主机（3主机） • 数据库层为有状态层
• 由JDBC提供Failover切换至可正常访问 Primary节点的MySQL ROUTER • 必须存在能访问到Primary节点的中间件层
• 需要确保能正确选出Primary
23. 网络隔离场景下的高可用保障 （同机房DMP架构网络隔离场景
）
管
理
区
核心配置组件
核心节点
核心节点
1. DMP确认Master节点故障。
核心节点
高可用切换决策组件
高可用管理节点(主)
高可用管理节点(备)
高可用决策下发，进行主从切换
数
据
区
状态采集节点
高可用_Agent
管理任务
状态采集
高可用_Agent
3. 在新Master上进行数据补偿，补偿完成后开启流量入口(绑
状态采集节点
管理任务
定VIP)。
状态采集
数据库复制
机房网络隔离
MySQL主
2. DMP选出新Master节点后关闭流量入口(卸载VIP)。
4. 应用继续连接VIP访问数据库即可(即应用对切换无感知)。
MySQL主
MySQL从
24. 网络隔离场景下的高可用保障 （双机房MGR架构网络隔离场景
）
• 业务层SLB需要将流量导入
给正常访问的应用层
• 多数节点机房的应用能通过本机房的MySQL ROUTER访问Primary节点，故应用正常读写。
• 少数节点机房的应用无法通过本机房的MySQL ROUTER访问到Primary节点，也无法访问多数节
点机房的MySQL ROUTER ，故少数节点机房的应用访问失败。
• 数据库层为有状态层
• 需要确保能正确选出Primary
• 且Primary节点一定是在多数节点机房
25. 网络隔离场景下的高可用保障 （双机房DMP架构网络隔离场景
）
A园区(生产中心)
B园区（容灾中心）
1. 一个机房存放主备2个节点，另一个机房存放2个备节点。
半同步
APPLICA
TION
Master
Slave-2
半同步
半同步
Slave-1
S
L
B
A园区(生产中心):故障
APPLICA
TION
2. 绑定”同园区切换”的高可用策略。
3. (流量入口)VIP 绑定在Master节点上。
Slave-3
B园区（容灾中心）
4. DMP会优先确保Master角色是在原Master节点所在机房（A园
区，生产中心）选出，生产中心故障则自动切换至容灾中心。
5. 同机房应用通过VIP正常访问数据库，部署在其他机房的应用
MySQL
Master
半
同
步
APPLICA
TION
则因网络隔离访问失败。
6. 业务层SLB需要将流量导入给正常访问的应用层。
MySQL
Slave-1
26. 05
架构优劣性对比
27. 架构优劣性对比
MySQL MGR + MySQL ROUTER 方案优势
1、MGR能保证自动选主
2、MySQL ROUTER 自动识别Primary节点
3、自身具有数据一致性保障
爱可生DMP平台的主备高可用方案优势
1、数据库的高可用由 DMP 平台的组件实现，组件本身存在高可用，组件之间存在协同，
统一调度，不存在单点故障。
2、主备架构相较MGR架构而言，架构整体链路较短，排错、运维更为简单。
3、主备架构没有存储引擎、主键、网络性能的约束，但也不建议大事务。
4、主备架构在Master节点上绑定VIP作为流量入口，故障时一般只需排查数据库本身问题
即可。
5、实例故障时会主动拉起两次；主实例故障时能自动进行主从切换，在 Master 上绑定VIP。
6、可根据客户需求自定义设置或绑定RTO、RPO规则。
7、运维包含 安装、升级、监控、备份、告警 等功能。
28. 架构优劣性对比
MySQL MGR + MySQL ROUTER 方案劣势
1、MySQL ROUTER 本身不具备高可用，只能通过在 JDBC 上配置多个IP：PORT，由JDBC实现MySQL
ROUTER的故障转移。
爱可生DMP平台的主备高可用方案
劣势
1、平台组件较多，运维存在复杂性。
2、MGR架构对于无相关经验的DBA或运维人员而言，排查问题较为复杂，不如DMP主备架构简单。 2、由于web界面的要求，对使用的浏览
器有要求（需通过chrome访问）
3、MGR存在诸多约束和限制:【
a) 良好的网络性能（毫秒级延迟）
b) 对大事务不友好 】 3、某些在本地违规修改的参数，需手动
更改元数据以保持参数的一致性。
4、架构整体的链路较长:【
a) 排查问题时，需要排查的链路节点多一点（如JDBC、 MySQL ROUTER 、MGR）
b) 网络链路也长，相较VIP方案性能下降
c) 需要编写的监控指标更多一些】
5、MGR架构在某些场景会导致集群hang住/成为只读，影响业务正常运行;
例如：多数派异常(3节点MGR集群可容忍1个节点故障，2个节点故障则无法正常联系将异常节点踢出集群)
29. 06
选型结论
30. 选型结论
服务化
自动化
集群化
客户选择“爱可生DMP平台主备高可用（同园区）架构“方案
已在线上高效、稳定运行两年+时间
具备故障自动切换、全天候告警监控、自动备份、自动巡检等保障
高效率
高性能
高可靠
31. THANK YOU！