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 界面
拖拽改变主从关系
参考
