在详细介绍如何设置复制之前，让我们先看看MySQL服务器实际上是如何复制数据的。总的来说，复制有三个步骤:

1.在主库上把数据更改记录到二进制日志(Binary Log)中(这些记录被称为二进制日志事件)。

2.备库将主库上的日志复制到自己的中继日志(Relay Log)中。

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

        第一步是在主库上记录二进制日志(精后介绍如何设置)，在每次准备提交事务完成数。据更新而，主席将数据更新的事件记录到二进制日志中，MySQL会按事务提交的顺序而非每条语句的执行顺序来记录二进制日志。在记录进制日志后，主库会告诉存储引擎可以提交事务了。

        下一步，备库将主库的二进制日志复制到其本地的中继日志中。首先，备库会启动个工作线程，称为I/O线程，I/O线程跟主库建立一个普通的客户端连接，然后在主库上启动一个特殊的二进制转储(inlog dump)线程(该线程没有对应的SQL命令)，这个二进制转储线程会读取主库上二进制日志中的事件。它不会对事件进行轮询。如果该线程追赶上了主库，它将进入睡眼状态，直到主库发送信号量通知其有新的事件产生时才会

被唤醒，备库1/0线程会将接收到的事件记录到中继日志中。

        MySQL 4.0之前的复制与之后的版本相比改变很大，例如MySQL最初的复制功能没有使用中继日志，所以复制只用到了两个线程，而不是现在的三个线程。目前大部分人都是使用的最新版本，因此在本章我们不会去讨论关于老版本复制的更多细节。

        备库的SQL线程执行最后一步，该线程从中继日志中读取事件并在备库执行，从而实现备库数据的更新。当SQL线程追赶上I/O线程时，中继日志通常已经在系统缓存中，所以中继日志的开销很低。SQL线程执行的事件也可以通过配置选项来决定是否写人其自己的二进制日志中，它对于我们稍后提到的场景非常有用。

        在备库有两个运行的线程，在主库上也有一个运行的线程:和其他普通连接一样，由备库发起的连接，在主库上同样拥有一个线程。

        这种复制架构实现了 获取事件和重放事件的解耦，允许这两个过程异步进行。也就是说I/O线程能够独立于SQL线程之外工作。但这种架构也限制了复制的过程，其中最重要的一点是在主库上并发运行的查询在备库只能串行化执行，因为只有一个SQL线程来重放中继日志中的事件。后面我们将会看到，这是很多工作负载的性能瓶颈所在。虽然有一些针对该问题的解决方案，但大多数用户仍然受制于单线程。