21 MySQL高可用-技术方案选型

# 1.高可用与数据库容灾
## 1.1.基本概念

- 关于SLA

```bash
SLI:服务质量指标 SLI （Service Level Indicator）
- 服务的某项服务质量的一个具体量化指标，用于测量性能.比如响应请求延时

SLO: 服务质量目标 SLO（Service Level Objective）
- 服务的某个SLI的目标值、或目标范围，用于说明预期性能。比如在 14 天衡量的所有有效请求中，95% 的服务响应应快于 400 毫秒 (ms)。

SLA：服务质量协议 SLA（Service Level Agreement）
- 服务与用户之间的一个明确的、或不明确的协议，描述了在达到或没有达到SLO的后果。比如数据库全年高可用99.9%未达到,则该服务提供商每分钟都会因不合规而补偿客户。
```

![Untitled (26)](https://img.sunrisenan.com/img/2024/04/27/120817213.png)

- 高可用

```bash
概念:高可用HA（High Availability）通过设计减少系统不能提供服务的时间。
高可用架构核心准则:冗余+自动故障转移

企业高可用标准：全年无故障率 
LSA:
无故障时间 故障时间 
99.9% 0.1%        = 525.6 min 
99.95%  0.05%     = 4h,22min,57s    
99.99% 0.01%      = 52.56 min         
99.999% 0.001%    = 5.256 min         
99.9999% 0.0001%  = 0.5256 min
```

- 容灾

```bash
#0.灾难定义
从一个计算机系统的角度讲，一切引起系统非正常停机的事件都可以称为灾难。大致可以分成以下三个类型：　　
1.自然灾害，包括地震、火灾、洪水、雷电等，这种灾难破坏性大，影响面广；　　
2.设备故障，包括主机的CPU、硬盘等损坏，电源中断以及网络故障等，这类灾难影响范围比较小，破坏性小。　　
3.人为操作破坏，包括误操作、人为蓄意破坏等等。

#1.概念:
容灾（Disaster Tolerance），就是在上述的灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断地运行。
	- 异地建立两套或多套功能相同的IT系统,主系统提供服务,备用系统提供冗余备份。
	- 互相进行健康状态监视
	- 主系统停止工作,整个应用系统可以切换备用系统
	- 提供系统级别的恢复功能

#2.分类
1.数据级容灾
- 数据远程异地备份
- 发生灾害时候可以异地拉去数据进行恢复

2.应用级容灾
- 数据容灾基础上,建立IT系统
- 通过同步or异步复制技术,保证关键应用在范围时间内恢复,用户基本感知不到.
- 网络、主机、应用、甚至IP,包括负载均衡、集群技术

3.业务级容灾
- IT系统+硬件设施+办公环境

#3.等级
第0级：
- 没有备援中心
- 本地备份数据

第1级：本地磁带备份，异地保存
- 本地备份 异地保存

第2级：热备份站点备份
- 实时数据备份

第3级：活动备援中心
- 灾备IDC数据中心,0数据丢失
- 灾害发生另一个备份站点可以接替主站点数据业务
- 典型:同城两中心,两地三中心,三地五中心

#4.关键指标
RTO（RecoveryTimeObjective，恢复时间目标）是可容许服务中断的时间长度。RTO数值越小，代表容灾系统的数据恢复能力越强。提升RTO的常用技术及其RTO的表

RPO（RecoveryPointObjective，恢复点目标）是指能容忍的最大数据丢失量，是指当业务恢复后，恢复得来的数据所对应时间点。提升RPO的常用技术及其RPO的表现见下表：
```

![Untitled (27)](https://img.sunrisenan.com/img/2024/04/27/121023130.png)

- RTO容灾技术

| 容灾技术 | 时长 |
| --- | --- |
| 磁带恢复 | 日级 |
| 人工迁移 | 小时级 |
| 应用系统远程切换 | 秒级 |

- RPO容灾技术

| 容灾技术 | 时长 |
| --- | --- |
| 磁带备份 | 日级 |
| 定期数据复制 | 小时级 |
| 异步数据复制 | 分钟级 |
| 同步数据复制 | 秒级 |

- 容灾基本架构-同城两中心

![Untitled (28)](https://img.sunrisenan.com/img/2024/04/27/121206245.png)

# 2.Mysql高可用架构方案选型

## 2.1.概述

Mysql高可用架构考虑方向:

- 数据库宕机或者意外中断等故障
    - 尽快恢复数据库高可用性
    - 尽可能减少停机时间
    - 保障业务不被中断
- 备份,只读副本等功能的slave节点数据与主节点数据保持 实时 或者 最终一致
- 业务发生数据库切换时,切换前后数据库内容一致,不会因为数据库确实或者数据不一致影响业务

## 2.2.高可用方案

### 2.2.1.主从或者主主半同步复制

- 使用双节点数据库，搭建单向或者双向的半同步复制。
    - 利用5.7版本之后的lossless replication、logical多线程复制等,使MySQL原生半同步复制可靠

- 常见架构
    - 与proxy，keepalived等服务一起使用,功能
        - 监控数据库健康
        - 主库发生故障,切换到备库仍然可以使用

![Untitled (29)](https://img.sunrisenan.com/img/2024/04/27/121320463.png)

- 优点
    - 架构比较简单，使用原生半同步复制作为数据同步的依据；
    - 双节点，没有主机宕机后的选主问题，直接切换即可；
    - 双节点，需求资源少，部署简单；
- 缺点
    - 完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证；
    - 需要额外考虑haproxy、keepalived的高可用机制

### 2.2.2.高可用架构优化

```bash
方案思路:
- 双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。
- 利用多个半同步复制的可靠性和多节点同时宕机的几率小于单节点
- 多节点架构用冗余设计,保障高可用性好与双节点架构
- 数据库数量较多,需要多个数据库管理软件保证数据库可维护性,MMM,MHA以及各个版本的Proxy
```

- 常见架构方案

**1.MHA+多节点集群**

```bash
MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。

MHA node处理 binlog,保证切换后的数据一致性
```
![Untitled (30)](https://img.sunrisenan.com/img/2024/04/27/121546410.png)

也可MHA多节点集群

![Untitled (31)](https://img.sunrisenan.com/img/2024/04/27/121634505.png)

- 优点
    - 进行故障的自动检测和转移;
    - 扩展性较好，可以根据需要扩展MySQL的节点数量和结构;
    - 相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低
- 缺点
    - 至少需要三节点，相对于双节点需要更多的资源;(MHA也可修改一主一从,这里不做讨论)
    - 逻辑较为复杂，发生故障后排查问题，定位问题更加困难;
    - 数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险;
    - 可能因为网络分区发生脑裂现象;

**2.zookeeper+proxy**

```bash
方案思路:
1.ZK分布式算法保证集群数据一致性
2.ZK保证proxy高可用,避免网络分区现象发生

优点:
1.较好的保证了整个系统的高可用性，包括proxy、MySQL;
2.扩展性较好，可以扩展为大规模集群;

缺点:
1.数据一致性仍然依赖于原生的mysql半同步复制;
2.引入zk，整个系统的逻辑变得更加复杂;
```

![Untitled (32)](https://img.sunrisenan.com/img/2024/04/27/121801028.png)

### 2.2.3.共享存储

> 方案思路:共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。

1.SAN共享存储

- SAN的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与LAN相比）连接，通过这种连接实现数据的集中式存储。常用架构如下
    - Mysql主从节点公用一个文件系统-保证主从使用相同数据
    - 优点
        - 两节点即可，部署简单，切换逻辑简单；
        - 很好的保证数据的强一致性；
        - 不会因为MySQL的逻辑错误发生数据不一致的情况；
    - 缺点
        - 共享存储的高可用；
        - 价格昂贵；

![Untitled (33)](https://img.sunrisenan.com/img/2024/04/27/121912086.png)

### 2.2.4.分布式协议

```bash
1.利用分布式协议可以解决数据一致性问题,常见方案。未来会成为主流方向
2.引入Paxos，Ratf,2PC等分布式算法保障高可用和一致性,
3.常用方案
- Percona XtraDB Cluster(PXC)
- MySQL Group Replication(MGR)
- MariaDB Galera Cluster(MGC)
```

### 2.2.5.云数据库数据同步服务

```bash
核心组件:DTS:数据传输服务
作用:异构数据库之间进行数据迁移、数据同步和数据订阅.数据库容灾核心组件
方案设计思路:利用实时同步通道构建异地容灾的高可用数据库架构。DTS 往往支持在主流数据库之间进行结构迁移、全量数据迁移和实时增量数据同步，其迁移同步任务还可按照同步范围并行进行同步。

方案架构:
1.同城双活
2.两地三中心
```

- DTS架构设计

![Untitled (34)](https://img.sunrisenan.com/img/2024/04/27/122046050.png)

# 3.总结

1.方法论上，高可用是通过冗余+自动故障转移来实现的
2.对于MySQL来说,如何保障选主和故障切换后的数据一致性是关键
3.业界比较流行的高可用方案
- MySQL+MHA(高可用)+域名读写分离-成熟体系(推荐生产环境使用)
- MySQL+MHA+ProxySQL-成熟体系(推荐生产环境使用)
- MGR:未来方向,对网络延时要求很高,新业务可以在限定场景下使用
- PXC:解决数据一致性问题,高可用是顺带实现,短板效应明显,运维成本过高
- ORCH:Go编写的mysql高可用工具,新兴,但是流行度不高(MHA功能足够,可以理解为Go语言的MHA)