MySQL8.0支持内置的异步复制、半同步复制，还有延迟复制。
1. 简介
异步复制：其中一个服务器充当源，而一个或多个其他服务器充当副本。
半同步复制：在返回执行事务的会话之前，对源执行提交，直到至少有一个副本确认它已经接收并记录了事务的事件。
延迟复制：使副本故意落后于源至少指定的时间。
2. 异步复制
异步复制存在三个线程：
- 主库提交事务的线程：主库收到客户端提交的事务，将数据先写入binlog(多个日志文件)，再提交事务，更新存储引擎中的数据，事务提交完成后，响应数据给客户。
- 从库复制的线程：从库的I/O线程请求具体的binlog文件以及其位点给主库，主库的dump线程获取指定位点的日志，推送给从库。从库专门有一个线程接收主库的binlog，把它写到中继日记relay log，最后响应给主库复制成功的信息。
- 从库回放的sql线程：读取和解析中继日志，然后回放relay log中的命令，更新存储引擎中的数据。
劣势 ：可能存在主从延迟，如果主节点宕机，可能会丢数据。
3. 半同步复制
这种机制和异步复制的区别：
- 主节点在收到客户端的请求后，必须在完成本节点日志写入的同时，还需要等待至少一个从节点完成数据同步的响应（或超时），才会响应请求。
- 从节点只有在写入 relay-log 并完成刷盘之后，才会向主节点响应。
- 当从节点响应超时时，主节点会将同步机制退化为异步复制。在至少一个从节点恢复，并完成数据追赶后，主节点会将同步机制恢复为半同步复制。
首先这个半同步需要安装同步插件。
#from MySQL 8.0.26:
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
#验证是否成功安装
SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE '%semi%';
主从节点都要开启半同步的功能：
SET GLOBAL rpl_semi_sync_source_enabled=1;
还有两个重要的参数：
rpl_semi_sync_master_wait_slave_count（8.0.26之后改为
rpl_semi_sync_source_wait_for_replica_count）：至少等待数据复制到几个从节点再返回。这个数量配置的越大，丢数据的风险越小，但是集群的性能和可用性就越差。
rpl_semi_sync_master_wait_point（8.0.26之后改为rpl_semi_sync_source_wait_point）：这个参数控制主库执行事务的线程，是在提交事务之前（AFTER_SYNC）等待复制，还是在提交事务之后（AFTER_COMMIT）等待复制。默认是 AFTER_SYNC，也就是先等待复制，再提交事务，这样就不会丢数据。
4. 基于全局事务标识符（GTID）复制
GTID是的同步方案和位点同步的方案不一样，前者是通过主库自己计算出主库A的X集合和从库B的Y集合的差集，取第一个元素之后的binglog日志推给从库，从库加载binlog日志到relaylog中继日志，sql线程解析relaylog，执行sql完成同步。而位点同步时需要人工从从库上指定位点，主库对应发送指定的日志，主库不做日志的完整性判断。
GTID这里说明一下，主库在判断差集的时候，会先判断主库A的集合X是否包含集合Y的所有GTID，如果不是，说主库A删除了从库B的binlog，主库A存在问题，直接返回错误。
所以说GTID 的产生时为了解决首次开启位点同步主从复制和回复主从复制的步骤复杂的问题。
介绍下全局事务ID ------ GTID 的结构：
GTID = source_id:transaction_id
source_id是源服务器唯一的server_uuid；
transaction_id是一个序列号，由事务在源上提交的顺序决定。
这个全局事务ID在所有的主从关系的MySQL服务器上是唯一的，在一个服务器上只执行一次，复制的方法也不再是 binlog文件+位点的方式，而是使用 MASTER_AUTO_POSTION=1的方式开始复制。从节点的那一端也强制开启binlog，目的是记录执行过的 GTID。
GTID的工作原理：
主库计算 主库 GTID 集合和从库 GTID 的集合的差集，主库推送差集 binlog 给从库。
GTID在配置的时候，主库和从库都要做修改：
#启用全局事务标识符（GTID）模式
gtid_mode=on
强制GTID的一致性。这意味着在执行事务时，MySQL将确保所有涉及的服务器都使用相同的GTID集。
enforce_gtid_consistency=on
5. 组复制（MGR）
组复制是为了解决主节点宕机导致主从数据不一致的问题而推出的高可用、高拓展的解决方案。
组复制是在GTID的增强，分为单主模式和多主模式，只要保证大多数主机可用，则服务可用。
单主模式下，只有一个主服务器设置成读写模式，其他设置成只读模式。
多主模式下：
group_replication_single_primary_mode=OFF
多主模式下，所有成员都是读写模式。
多主模式本身不处理客户端故障转移，因此需要使用中间件框架(如MySQL Router 8.0)、代理、连接器或应用程序本身来安排。
6.InnoDB Cluster
InnoDB Cluster是MySQL高可用+读写分离的架构方案，主要包含组复制（MGR）、MySQL shell、MySQL route三大组件。
MGR提供主从高可用的方案，MySQL shell是创建和管理集群，MySQL route是业务入口，根据主从角色的判断实现读写分离。后面两个是需要安装的。
可以通过配置memberWeight这个属性提高该节点在单主模式下选为主节点的概率。
cluster.setInstanceOption('mgr-node1:3306','memberWeight',100)
集群的角色切换有三种：
- 单主模式------指定主节点：cluster.setPrimaryInstance("homename:3306")
- 单主模式切换到多主模式：cluster.switchToMultiPrimaryMode()
- 多主模式切换到指定节点的单主模式：cluster.switchToSinglePrimaryMode("homename:3306")
7. InnoDB ReplicaSet和InnoDB Cluster的区别
InnoDB ReplicaSet
-
基于传统的主从复制：一个主节点 + 一个或多个从节点
-
异步复制：采用 MySQL 原生的异步复制
-
读写分离：主节点处理写和读，从节点处理只读查询
-
自动故障转移：通过 MySQL Shell 和 MySQL Router 实现自动故障转移
-
手动切换 ：支持手动故障转移，但不支持自动选举
InnoDB Cluster
-
基于组复制：使用 MySQL Group Replication
-
多主或单主模式：默认单主模式，所有节点数据一致
-
自动选举：内置的 Paxos 协议实现自动故障转移和主节点选举
-
强一致性：同步复制（多数节点确认后才提交）
-
自动数据分片：通过 MySQL Shell 自动管理