1 高可用定义
高可用架构（High Availability Architecture），是指在任何情况下都能确保系统持续运行，且服务不中断的设计方法。
如何量化系统是否满足高可用？有两个指标尤其重要:
1、RTO(RecoveryTime Objective)：系统服务恢复时间，从IT系统宕机导致业务停顿之刻开始，到IT系统恢复至可以支持各部门的业务恢复运营之时，此两点之间的时间段。该指标单位是秒(s)。
比如：RTO=5s，指系统在故障发生后，需要在5s内重新启动或者进行高可用切换成功，以提供正常服务。
2、RPO(Recovery Point Objective)：系统数据恢复点目标，当IT系统故障恢复时，指IT系统的数据应恢复到过去哪个时间点的数据。该指标单位是秒(s)。
比如：RPO=0s，指系统在故障发生后，需要把系统故障前已经提交的数据全部恢复，换句话说，就是不能容忍有任何数据丢失。
3 一致性要求。比如强一致性要求系统从任一节点读取到的数据都是最新且一致的，弱一致性允许有一定的延迟。
4 支持跨地区部署，且Master可以跨地区切换。
2 如何设计数据高可用
如何设计满足上述指标的数据库架构？
保证 RPO = 0 的设计思路，意味着在发生灾难或故障时，系统不允许任何数据丢失，即数据在全时段都是在大于一台机器上是保持一致的。
2.1 Mysql高可用设计
方案一 主从架构
- Master 将数据改变记录到二进制日志(binary log)中，也就是配置文件 log-bin 指定的文件， 这些记录叫做二进制日志事件(binary log events)；
- Slave 通过 I/O 线程，定时读取 Master 中的 binary log events 并写入到它的中继日志(relay log)；
- Slave 通过SQL线程，重做中继日志中的事件，把中继日志中的事件信息一条一条的在本地执行一次，完 成数据在本地的存储，从而实现将改变反映到它自己的数据(数据重放)。
主从复制根据一致性由弱变强分为：异步复制，半同步复制，增强半同步复制，同步复制四种，只有后两者满足RPO=0的要求。 主从复制流程如图所示：
如果RPO要求比较高首推增强半同步。
半同步与异步的区别？
半同步在收到从的ACK之前会阻塞请求，使数据丢失限制在一个事务之内。
半同步与增强半同步区别？
增强半同步将等待ACK的点放在提交Commit之前，此时数据还未被提交，外界看不到数据变更，此时如果发送主从切换，新库依然还是老数据，不存在数据不一致的问题。
增强半同步与同步区别？
同步接收ACK的时机更晚，在从完成更新之后
但该架构本身不支持多主，出现故障无法自动转移，需要手动恢复。
方案二 组复制架构（MySQL Group Replication，简称MGR）
为了支撑多主和出现故障时自动转移，Mysql提供了组复制架构。该架构采用多写+一致性协议的方式实现了主机宕机不中断。
该架构由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。
优点：
- 支持强一致性，保证所有节点的数据一致。
- 自动故障转移，节点故障后自动恢复。（需要借助第三方工具）
- 不需要外部的负载均衡器。
缺点：
- 性能开销较大，特别是在写操作较多时。
- 配置和管理较为复杂。
方案三 InnoDB Cluster架构（推荐*****）
MySQL InnoDB Cluster 是基于 Group Replication，Mysql Shell 和 MySQL Router 构建的一个高可用集群解决方案，提供自动故障转移和分布式事务支持，它是MySQL官方推荐的高可用架构之一。 MySQL InnoDB 集群由以下几部分组成：
Group Replication：向集群的所有成员复制数据，同时提供容错、自动故障转移和弹性 MySQL Router：确保客户端请求是负载平衡的，并在任何数据库故障时路由到正确的服务器。 MySQL Shell：通过内置的管理API创建及管理Innodb集群。
方案四 InnoDB ClusterSet架构
顾名思义，InnoDB Cluster集群的集群，主要用于大型企业多个数据中心的数据同步。
InnoDB ClusterSet 使用专用的 ClusterSet 复制通道自动管理从主集群到副本集群的复制。如果主集群由于数据中心损坏或网络连接丢失而变得无法使用，用户可以激活副本集群以恢复服务的可用性。
InnoDB ClusterSet 的特点：
- 主集群和副本集群之间的紧急故障转移可以由管理员通过
MySQL Shell，使用 AdminAPI 进行操作 - InnoDB ClusterSet 部署中可以拥有的副本集群的数量没有定义的限制
- 异步复制通道将事务从主集群复制到副本集群。
clusterset_replication在InnoDB ClusterSet创建过程中，在每个集群上都设置了名为 ClusterSet 的复制通道，当集群是副本时，它使用该通道从主集群复制事务。底层组复制技术管理通道并确保复制始终在主集群的主服务器（作为发送方）和副本集群的主服务器（作为接收方）之间进行 - 每个
InnoDB ClusterSet集群，只有主集群能够接收写请求，大多数的读请求流量也会被路由到主集群，不过也可以指定读请求到其他的集群
InnoDB ClusterSet 的限制：
- InnoDB ClusterSet 只支持异步复制，不能使用半同步复制，无法避免异步复制的缺陷：数据延迟、数据一致性等
- InnoDB ClusterSet 仅支持Cluster实例的单主模式，不支持多主模式。 即只能包含一个读写主集群，所有副本集群都是只读的，不允许具有多个主集群的双活设置，因为在集群发生故障时无法保证数据一致性
- 已有的 InnoDB Cluster 不能用作 InnoDB ClusterSet 部署中的副本集群。副本集群必须从单个服务器实例启动，作为新的 InnoDB 集群
- 只支持 MySQL 8.0
方案五 MySQL InnoDB ReplicaSet架构
InnoDB ReplicaSet 是 MySQL 团队在 2020 年推出的一款产品，用来帮助用户快速部署和管理主从复制，在数据库层仍然使用的是主从复制技术。
InnoDB ReplicaSet由单个主节点和多个辅助节点（传统上称为 MySQL 复制源和副本）组成。
与InnoDB cluster 类似，MySQL Router 支持针对 InnoDB ReplicaSet 的引导, 这意味着可以自动配置 MySQL Router 以使用 InnoDB ReplicaSet，而无需手动配置文件。这使得 InnoDB ReplicaSet 成为一种快速简便的方法，可以启动和运行 MySQL 复制和 MySQL Router，非常适合扩展读取，并在不需要 InnoDB 集群提供高可用性的用例中提供手动故障转移功能。
InnoDB ReplicaSet 的限制：
- 没有自动故障转移，在主节点不可用的情况下，需要使用 AdminAPI 手动触发故障转移，然后才能再次进行任何更改。但是，辅助实例仍可用于读取
- 由于意外停止或不可用，无法防止部分数据丢失：在意外停止时未完成的事务可能会丢失
- 在意外退出或不可用后无法防止不一致。如果手动故障转移提升了一个辅助实例，而前一个主实例仍然可用，例如，由于网络分区，裂脑情况可能会导致数据不一致
- InnoDB ReplicaSet 不支持多主模式，允许写入所有成员的经典复制拓扑无法保证数据一致性
- 读取横向扩展是有限的。
InnoDB ReplicaSet基于异步复制，因此无法像Group Replication那样调整流量控制 - 一个 ReplicaSet 最多由一个主实例组成。支持一个或多个辅助。尽管可以添加到 ReplicaSet 的辅助节点的数量没有限制，但是连接到 ReplicaSet 的每个 MySQL Router 都必须监视每个实例。因此，一个 ReplicaSet 中加入的实例越多，监控就越多
使用 InnoDB ReplicaSets 的主要原因是你有更好的写性能。使用 InnoDB ReplicaSets 的另一个原因是它们允许在不稳定或慢速网络上部署，而 InnoDB Cluster 则不允许。
方案六 MySQL Cluster（NDB）架构
MySQL Cluster 是一个高度可扩展的，兼容 ACID 事务的实时数据库，基于分布式架构不存在单点故障，MySQL Cluster 支持自动水平扩容，并能做自动的读写负载均衡。
MySQL Cluster 使用了一个叫 NDB 的内存存储引擎来整合多个 MySQL 实例，提供一个统一的服务集群。
mysql cluster 的优点：
- 99.999％的高可用性
- 快速的自动失效切换
- 灵活的分布式体系结构，没有单点故障
- 高吞吐量和低延迟
- 可扩展性强，支持在线扩容
mysql cluster 的缺点：
- 存在很多限制，比如：不支持外键，数据行不能超过8K（不包括BLOB和text中的数据）
- 部署、管理、配置很复杂
- 占用磁盘空间大，内存大
- 备份和恢复不方便
- 重启的时候，数据节点将数据 load 到内存需要很长时间
