共计 2595 个字符，预计需要花费 7 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 MySQL 中怎么实现异步复制，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
一、MYSQL 复制架构衍生史
在 2000 年，MySQL 3.23.15 版本引入了 Replication。Replication 作为一种准实时同步方式，得到广泛应用。这个时候的 Replicaton 的实现涉及到两个线程，一个在 Master，一个在 Slave。Slave 的 I / O 和 SQL 功能是作为一个线程，从 Master 获取到 event 后直接 apply，没有 relay log。这种方式使得读取 event 的速度会被 Slave replay 速度拖慢，当主备存在较大延迟时候，会导致大量 binary log 没有备份到 Slave 端。
在 2002 年，MySQL 4.0.2 版本将 Slave 端 event 读取和执行独立成两个线程(IO 线程和 SQL 线程)，同时引入了 relay log。IO 线程读取 event 后写入 relay log，SQL 线程从 relay log 中读取 event 然后执行。这样即使 SQL 线程执行慢，Master 的 binary log 也会尽可能的同步到 Slave。当 Master 宕机，切换到 Slave，不会出现大量数据丢失。
在 2010 年 MySQL 5.5 版本之前，一直采用的是这种异步复制的方式。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸 crash，那么就会导致数据丢失。于是在 MySQL 在 5.5 中就顺其自然地引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到 relay log 中。
在 2016 年，MySQL 在 5.7.17 中引入了一个全新的技术，称之为 InnoDB Group Replication。目前官方 MySQL 5.7.17 基于 Group replication 的全同步技术已经问世，全同步技术带来了更多的数据一致性保障。
下图对应 MySQL 几种复制类型，分别是异步、半同步、全同步
二、异步复制(Asynchronous replication)
1. 逻辑上
MySQL 默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果 crash 掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
2. 技术上
主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。
3. 原理图
(1) 在 Slave 服务器上执行 sart slave 命令开启主从复制开关，开始进行主从复制。
(2) 此时，Slave 服务器的 IO 线程会通过在 master 上已经授权的复制用户权限请求连接 master 服务器，并请求从执行 binlog 日志文件的指定位置 (日志文件名和位置就是在配置主从复制服务时执行 change master 命令指定的) 之后开始发送 binlog 日志内容
(3) Master 服务器接收到来自 Slave 服务器的 IO 线程的请求后，其上负责复制的 IO 线程会根据 Slave 服务器的 IO 线程请求的信息分批读取指定 binlog 日志文件指定位置之后的 binlog 日志信息，然后返回给 Slave 端的 IO 线程。返回的信息中除了 binlog 日志内容外，还有在 Master 服务器端记录的 IO 线程。返回的信息中除了 binlog 中的下一个指定更新位置。
(4) 当 Slave 服务器的 IO 线程获取到 Master 服务器上 IO 线程发送的日志内容、日志文件及位置点后，会将 binlog 日志内容依次写到 Slave 端自身的 Relay Log(即中继日志)文件 (Mysql-relay-bin.xxx) 的最末端，并将新的 binlog 文件名和位置记录到 master-info 文件中，以便下一次读取 master 端新 binlog 日志时能告诉 Master 服务器从新 binlog 日志的指定文件及位置开始读取新的 binlog 日志内容
(5) Slave 服务器端的 SQL 线程会实时检测本地 Relay Log 中 IO 线程新增的日志内容，然后及时把 Relay LOG 文件中的内容解析成 sql 语句，并在自身 Slave 服务器上按解析 SQL 语句的位置顺序执行应用这样 sql 语句，并在 relay-log.info 中记录当前应用中继日志的文件名和位置点
三、全同步复制(Fully synchronous replication)
1. 逻辑上
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
2. 技术上
当主库提交事务之后，所有的从库节点必须收到、APPLY 并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。
3. 原理图
四、半同步复制(Semisynchronous replication)
1. 逻辑上
是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。
2. 技术上
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到 relay log 中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个 TCP/IP 往返的时间。所以，半同步复制最好在低延时的网络中使用。
3. 原理图
master 将每个事务写入 binlog(sync_binlog=1)，传递到 slave 刷新到磁盘(sync_relay=1)，同时主库提交事务(commit)。master 等待 slave 反馈收到 relay log，只有收到 ACK 后 master 才将 commit OK 结果反馈给客户端。
关于 MySQL 中怎么实现异步复制就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
