mysql的Replication机制

参考文档：http://www.doc88.com/p-186638485596.html

Mysql的 Replication 是一个异步的复制过程。

从上图可以看见MySQL 复制的基本过程如下：

Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容；
Master 接收到来自 Slave 的 IO 线程的请求后，通过复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置；
Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；
Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave 端执行了同样的 Query，所以两端的数据是完全一样的。

注意：要实现主从同步，master必须打开Binary Log功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “--log-bin” 参数选项，或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。

从上面来看，主从同步延迟的主要原因是因为主库采用多线程更新，而从库采用单线程更新。看起来解决问题很简单，只要从库也采用多线程更新即可。

但这样做会带来一个新问题，当从relay_log读到对同一个条记录的多条操作时（比如先后insert和update 了同一个记录），此时如果这两个操作分配给了2个sql 线程并发去更新从库，那就不能保证它们的执行顺序了。

解决这个问题的方法是，当有多个sql_thread线程来更新从库的时候，必须让每个sql_thread对应一张表，如果从库有10张表，那么就使用10个sql_thread分别更新，这样就解决了并发带引起的乱序的问题；

改进的主从同步方案：

1、在io_thread接收主库日之后，分成N份relay-log存放；
2、再用N个sql_thread分别读取日志分发；
3、确保同一个表的更新语句顺序与主库binlog相同；

事实上，淘宝工程师丁奇已经实现了上述改造方案，并创造了一个叫transfer的工具来完成这个功能，如何获取和使用transfer工具可以自行google之。