一文彻底搞懂MySQL Replication（复制）

MySQL Replication 基本包含以下三种：

1. 异步复制（MySQL Asynchronous Replication）

此乃最为传统且最为原始、效率最高的一种复制方式。从相关图片中能够清晰地洞察到数据流向，源端（Source/Master）承担接收业务操作之职责，随后以二进制日志（binlog）的形式将数据传输至目标端（Replica/Slave）。源端并不会对目标端是否完整接收这些变更日志进行判断，而是直接继续处理后续事务。

通过上述简要描述，能够发现此种复制方式存在明显弊端。在源端传输变更日志的过程中，若源端出现异常宕机的状况，目标端便会出现与源端数据不一致的情形

2. 半同步复制（MySQL Semisynchronous Replication）

从相关图片中能够清晰地观察到，半同步复制与异步复制存在显著区别。当源端发生数据变更并向目标端同步日志时，需待目标端接收并完成日志应用，且源端收到目标端的响应后，才会对该变更操作进行提交。除这一关键环节外，其余操作二者均保持一致。

通过上述简要阐述可知，半同步复制可有效避免异步复制中源端与目标端数据不一致情况的发生。不过，从源端开始传输数据至接收到目标端的确认应答（ACK）这一时间段内，半同步复制受网络因素的影响较为显著，并且会对涉及一样数据的事务操作产生阻碍。

3. 组复制（MySQL Group Replication）

• 从图中，可以看到是三个Master，也就意味着一个节点异常，是不影响整个组使用的。它也就是一个冗余系统。实现也和前面描述的两种架构不同，在一开始就把相应的变更操作传输到其它节点。

大家可以思考下？为什么我说一个节点异常，不影响整体使用？

• 从图中可以清晰的看到Master1、Master2、Master3，也就意味着是三个主节点，对应的也会有单主节点。他们适用场景有哪些呢？

单主节点：

使用场景：高并发操作场景。如果一个节点宕机，服务可以正常提供服务，那么是剩余的两个是如何选择谁为主呢？A、MySQL版本 B、
group_replication_member_weight权重 C、UUID的字典生成顺序

多主节点：

使用场景：相对来说简单的场景 。由于多主模式，如果同时写入许多，容易引发冲突。如果碰到冲突，它使用的是first commit wins，后面的回滚。