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!

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.3. UTC+08:00, 2024-12-01 00:28
浙ICP备14020137号-1 $bản đồ khách truy cập$