3 主从复制的缺点及解决方案
3.1 主从延迟
- 只能数据分片,把数据量做小
主从同步适用场景
推荐在读 >> 写,且读时对数据时效性要求不高时采用。所以可以考虑用MySQL的并行复制,但问题是那是库级别的并行,所以有时作用不是很大。
主从延迟严重解决方案
分库 : 将一个主库拆分,每个主库的写并发就降低了,主从延迟即可忽略不计
打开MySQL支持的并行复制,多个库并行复制,若某个库的写入并发特别高,写并发达到了2000/s,并行复制还是没意义。二八法则,很多时候比如说,就是少数的几个订单表,写入了2000/s,其他几十个表10/s。
从库开启多线程,并行读取relay log中不同库的日志,然后并行重放不同库的日志,这是库级别的并行。
重构代码 : 重构代码,插入数据后,直接更新,不查询
若确实存在必须先插入,立马要求查询,然后立马就反过来执行一些操作,对这个查询设置直连主库(不推荐,这会导致读写分离失去意义)
3.2 应用侧需要配合读写分离框架
读写分离
借助于主从复制,我们现在有了多个 MySQL 服务器示例。
如果借助这个新的集群,改进我们的业务系统数据处理能力?
最简单的就是配置多个数据源,实现读写分离
动态切换数据源
- 基于 Spring/Spring Boot,配置多个数据源(例如2个,master 和 slave)
- 根据具体的 Service 方法是否会操作数据,注入不同的数据源,1.0版本
优化:
1.1:基于操作 AbstractRoutingDataSource 和自定义注解 readOnly 之类的,简化自动切换数据源
1.2:支持配置多个从库
1.3:支持多个从库的负载均衡
框架
“动态切换数据源”版问题:
- 代码侵入性强
- 降低侵入性会导致”写后立即读”不一致问题
写时(还没同步到从库),立马读(从库),导致你 insert 数据后去查却查不到!
改进方式,ShardingSphere-jdbc 的 Master-Slave 功能
1)SQL 解析和事务管理,自动实现读写分离
2)解决”写完读”不一致的问题
只要一个事务中解析到有写,所有读都读主库,而无需我们业务代码处理。
数据库中间件
“框架版本”的问题?
- 对业务系统还是有侵入
- 对已存在的旧系统改造不友好
优化方案:MyCat/ShardingSphere-Proxy 的 Master-Slave 功能
- 需要部署一个中间件,规则配置在中间件
- 模拟一个 MySQL 服务器,对业务系统无侵入
但是该方案需要单独部署中间件,需要运维成本和领导审批,所以一般开发人员使用框架方案。
3.3 无法高可用
3.3.1 为什么要高可用
1、读写分离,提升读的处理能力
2、故障转移,提供 failover 能力
加上业务侧连接池的心跳重试,实现断线重连,业务不间断,降低RTO和RPO。
高可用意味着,更少的不可服务时间。一般用SLA/SLO衡量。
1年 = 365天 = 8760小时 99 = 8760 * 1% = 8760 * 0.01 = 87.6小时 99.9 = 8760 * 0.1% = 8760 * 0.001 = 8.76小时 99.99 = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟 99.999 = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟
3.3.2 failover,故障转移,灾难恢复
容灾:热备与冷备
对于主从来说,就是主挂了,某一个从,变成主,整个集群来看,正常对外提供服务。
常见的一些策略:
- 多个实例不在一个主机/机架上
- 跨机房和可用区部署
- 两地三中心容灾高可用方案
3.3.3 高可用方案
3.3.3.1 主从手动切换
若主节点宕机,将某个从改成主;重新配置其他从节点。修改应用数据源配置。
缺点:
- 可能数据不一致
- 需要人工干预
- 代码和配置的侵入性
3.3.3.2 主从自动切换
用 LVS+Keepalived 实现多个节点的探活+请求路由。
配置 VIP 或 DNS 实现配置不变更。
缺点:
- 手工处理主从切换
- 大量的配置和脚本定义
只能算半自动。
3.3.3.2 MHA
MHA,Master High Availability,目前在 MySQL 高可用方面是一个相对成熟的解决方案,它由日本 DeNA 公司的 youshimaton(现就职于 Facebook)开发,是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。
基于 Perl 语言开发,一般能在30s内实现主从切换。
切换时,直接通过 SSH 复制主节点的日志。
缺点:
- 需要配置 SSH 信息
- 至少3台
3.3.3.2 MGR
不借助外部力量,只使用 MySQL 本身。如果主节点挂掉,将自动选择某个从改成主;无需人工干预,基于组复制,保证数据一致性。
缺点:
- 外部获得状态变更需要读取数据库
- 外部需要使用 LVS/VIP 配置
特点:
- 高一致性
基于分布式Paxos协议实现组复制,保证数据一致性 - 高容错性
自动检测机制,只要不是大多数节点都宕机就可继续工作,内置防脑裂保护机制 - 高扩展性
节点的增加与移除会自动更新组成员信息,新节点加入后,自动从其他节点同步增量数据,直到与其他节点数据一致 - 高灵活性
提供单主模式和多主模式,单主模式在主库宕机后能够自动选主,所有写入都在主节点进行,多主模式支持多节点写入
适用场景:
- 弹性复制
需要非常流畅的复制基础架构的环境,其中服务器的数量必须动态地增长或缩减,而最少尽可能的痛苦。
高可用分片
Sharding is a popular approach to achieve write scale-out. Users can use MySQL Group Replication to implement highly available shards. Each shard
can map into a Replication Group.
分片是实现写横向扩展的一种流行方法。用户可以使用MySQL组复制来实现高度可用的分片。每个分片可以映射到副本组。
3.3.3.4 MySQL Cluster
完整的数据库层高可用解决方案。
MySQL InnoDB Cluster是一个高可用的框架,构成组件:
MySQL Group Replication
提供DB的扩展、自动故障转移
MySQL Router
轻量级中间件,提供应用程序连接目标的故障转移。MySQL Router是一个轻量级的中间件,可以提供负载均衡和应用连接的故障转移。它是MySQL团队为MGR量身打造的,通过使用Router和Shell,用户可以利用MGR实现完整的数据库层的解决方案。如果您在使用MGR,请一定配合使用Router和Shell,可以理解为它们是为MGR而生的,会配合MySQl 的开发路线图发展的工具。
MySQL Shell
新的MySQL客户端,多种接口模式。可以设置群组复制及Router。MySQL Shell是MySQL团队打造的一个统一的客户端, 它可以对MySQL执行数据操作和管理。它支持通过JavaScript,Python,SQL对关系型数据模式和文档型数据模式进行操作。使用它可以轻松配置管理InnoDB Cluster。
3.3.3.5 Orchestrator
如果主节点挂掉,将某个从改成主。
一款MySQL高可用和复制拓扑管理工具,支持复制拓扑结构的调整,自动故障转移和手动主从切换等。后端数据库用MySQL或SQLite存储元数据,并提供Web界面展示MySQl 复制的拓扑关系及状态,通过Web可更改MySQL实例的复制关系和部分配置信息,同时也提供命令行和API接口,方便运维管理。
特点:
- 自动发现MySQL的复 制拓扑,并且在web.上展示;
- 重构复制关系, 可以在web进行拖图来进行复制关系变更;
- 检测主异常,并可以自动或手动恢复,通过Hooks进行自定义脚本;
- 支持命令行和web界面管理复制。
基于 Go 语言开发,实现了中间件本身的高可用。
两种部署方式
orchestrator/raft:
- 数据一致性由orchestrator的raft协议保证
- 数据库之间不通信
orchestrator/[galera | xtradb cluster | innodb cluster]: - 数据一致性由数据库集群保证
- 数据库结点之间通信
如果不部署client
- 使用HTTP (/api/leader-check)查询并路由到主节点
优势:
能直接在 UI 界面
拖拽改变主从关系
参考