MySQL 内建的复制功能是构建基于 Mysql 的大规模、高性能应用的基础，同时也是高可用性、可扩展性、灾难恢复、备份及数据仓库等工作的基础。通过本章内容，可以更好地理解主从复制的实现机制。

复制解决的问题

• 高可用，避免单点问题，主库出现故障时，应用依然可以从从库查询数据，不影响查询业务，另外通过故障切换功能，可以将从库切换为主库，缩短系统宕机时间。
• 数据备份，数据在系统中存在多份，其中一个机器出现故障，还可以从其它机器获取数据及修复数据，但是复制不能取代备份。
• 负载均衡，应用系统可以通过读写分离实现分流，减轻数据库访问压力。
• 升级测试，需要升级 Mysql 版本时，可以先升级从库的版本，保证查询业务可以在高版本的从库中正常运行，之后再全面升级所有实例。

复制方式

Mysql 支持两种复制方式：基于语句的复制 和 基于行的复制。两种方式都是通过在主库上记录二进制日志，在从库重放日志的方式来实现异步的数据复制。这意味着，同一时间点，从库可能与主库的数据不一致，并且无法保证延迟时间，一些大的语句可能导致从库产生几秒、几分钟甚至几小时的延迟。

• 基于语句的复制

主库会将造成数据变更的语句记录到二进制日志，然后到从库重放，本质上就是把主库执行过的语句到从库再执行一遍。实现简单、事件紧凑，占用带宽小。

• 基于行的复制

主库会将实际数据记录到二进制日志，由于无须重放更新主库数据的语句，基于行的复制模式能够更高效地复制数据。

有的语句执行开销比较大，如下面的语句，最终只在目标表上增加三条记录，如果使用基于行的复制模式，在从库上开销就小很多。

insert into summary(col1, col2, col3)
select col1, col2, sum(col3)
from enormous
group by col1, col2;

下面的语句，进行了全表更新，使用基于行的复制模式开销就很大，因为每一行的数据都会被记录到二进制日志，这使得二进制日志非常庞大，占用大量磁盘空间。

update enormous set cole = 0;

理论上基于行的复制整体上更优。

复制工作原理

1、主库把数据更新记录到二进制日志（Binary Log）中。

每次提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中。Mysql 会按事务提交顺序而非每条语句的执行顺序来记录二进制日志。记录完二进制日志后，主库会通知存储引擎执行事务提交。

2、从库将主库上的日志复制到从库的中继日志（Relay Log）中。

从库启动一个工作线程，称为IO线程，IO线程与主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转储（binlog dump）线程，这个二进制转储线程会读取主库上二进制日志中的事务，但它不会对事件进行轮询。如果该线程追赶上了主库，它将进入睡眠状态，直到主库发送信号量通知其有新的事件产生时才会被唤醒，从库IO线程会将接收到的事件记录到从库的中继日志中。

3、从库读取中继日志中的事件，将其重放到从库数据之上。

从库启动一个SQL线程，读取中继日志中的事件并在从库执行，实现从库数据更新。当SQL线程追赶上IO线程时，中继日志通常已经在系统缓存中，所以中继日志的开销很低。

具体工作流程如下图所示：

这种架构实现了获取事件与重放事件的解耦，允许这两个过程异步执行，也就是说 IO 线程可以独立于 SQL 线程之外工作。

多级复制

log_slave_updates 选项可以让从库变成其它服务器的主库，该选项默认是打开的，这样就会形成级联的复制。

具体工作流程如下图所示：

结束语：

Mysql 主从复制并没有使用轮询的方式从主库请求事件，而是主库通知从库新的事件，因为前者低效且缓慢，从主库读取一个二进制日志事件是一个阻塞型网络调用，当主库记录事件后，马上就开始发送，因此可以说，只要复制线程被唤醒并且能够通过网络传输数据，事件就会很快到达从库，大多数小查询在主库的执行时间与在备库的执行时间间隔小于 0.3 毫秒。