这篇文章主要从主从复制的实现机制方面进行论述，可能对于我们实际应用没有直接的帮助，但是理解它的原理毕竟对于以后的维护和优化能起到事半功倍的效果。

　　Mysql一次主从复制需要有三个线程来实现，其中一个线程(Binlog dump thread)在主服务器上，另外两个线程(Slave I/O thread , Slave SQL thread)在从服务器上(如果一台主服务器配两台从服务器那主服务器上就会有两个Binlog dump 线程，而每个从服务器上各自有两个线程)。下面我们分别来介绍

　　主服务器线程 Binlog dump thread

　　Binlog dump 线程是当有从服务器连接的时候由主服务器创建，其大致工作过程经历如下几个阶段

　　首先bin-log日志文件加锁，然后读取更新的操作，读取完毕以后将锁释放掉，最后将读取的记录发送给从服务器。

　　我们可以使用下面所示的命令来查看该线程的信息

　　mysql> SHOW PROCESSLIST\G

　　以我的系统为例，因为我这系统中是一台主服务器和两台从服务器，所以会列出两条Binlog dump线程的信息

　　*************************** 1. row ***************************

　　Id: 2

　　User: repuser

　　Host: 192.168.144.131:41544

　　db: NULL

　　Command: Binlog Dump

　　Time: 54

　　State: Master has sent all binlog to slave; waiting for binlog to be updated

　　Info: NULL

　　*************************** 2. row ***************************

　　Id: 3

　　User: repuser

　　Host: 192.168.144.132:40888

　　db: NULL

　　Command: Binlog Dump

　　Time: 31

　　State: Master has sent all binlog to slave; waiting for binlog to be updated

　　Info: NULL

　　上述字段中的state字段会有以下几种状态

　　1. Sending binlog event to slave

　　表示Binlog dump 线程已经读取完binlog日志中更新的event，现在正在发送给从服务器

　　2. Master has sent all binlog to slave; waiting for binlog to be updated

　　这就是上面我们看到的state的值，表示Binlog dump 线程已经读取完所有的binlog日志文件，并且将其发送给了从服务器。现在处于空闲状态，正在等待读取有新的操作的binlog日志文件

　　3. Finished reading one binlog; switching to next binlog

　　表示Binlog dump 线程已经读取完一个binlog日志，现在正在打开下一个binlog日志读取来发送给从服务器

　　4. Waiting to finalize termination

　　这个状态持续的很短暂，我们几乎看不到。当线程停止的时候显示此状态

　　上述几个状态就是一次主从复制过程中Binlog dump 线程所经历的状态，如果我们是在测试的环境中，上述1、3、4状态我们几乎是看不到的，因为它执行的很快。

　　在主从系统中主服务器上的一个主要的文件就是bin-log日志，该线程操作的文件也是此日志文件，因此这是我们需要在配置文件my.cnf 中打开bin-log日志的原因，使用此文件来记录我们的更新操作

　　[mysqld]

　　log-bin = mysql-bin

　　server-id = 1

　　还有一点需要注意，在上面已经说过，但是在这里觉得有必要再重复一遍，就是有多少个从服务器连接主服务器上就有多少个Binlog dump 线程

　　Binary Log 的简单介绍

　　因为Binlog dump 线程操作的文件是bin-log 日志文件，并且实现主从复制在主服务器上主要依靠bin-log日志文件，所以我们来简单介绍一下bin-log日志文件。

　　bin-log 日志文件有两种格式，一种是Statement-Based，另一种是Row-Based。

　　Row-Based优点和缺点分析

　　优点

　　1. 所有的改变都会被复制，这是最安全的复制方式

　　2. 对于 update、insert……select等语句锁定更少的行

　　3. 此种方式和大多数的数据库系统一样，所以了解其他的系统的人员可以很容易的转到mysql

　　缺点

　　1. 使用不方便，我们不能通过bin-log日志文件查看什么语句执行了，也无从知道在从服务器上接收到什么语句，我们只能看到什么数据改变了

　　2. 因为记录的是数据，所以说bin-log日志文件占用的存储空间要比Statement-based大。

　　3. 对于数据量大的操作其花费的时间有更长

　　获取更详细的信息可以参考官方文档——Row-Based的优点和缺点Statement-Based优点和缺点分析

　　优点

　　1. bin-log日志包含了描述数据库操作的事件，但是这些事件包含的情况只是对数据库进行改变的操作，例如 insert、update、create、delete等操作。相反对于select、desc等类似的操作并不会去记录，并且它记录的是语句，所以相对于Row-Based来说这样会占用更少的存储空间。

　　2. 因为bin-log日志文件记录了所有的改变数据库的语句，所以此文件可以作为以后的数据库的审核依据

　　缺点

　　1. 不安全，并不是所有的改变数据的语句都会被记录复制。任何的非确定性的行为都是很难被记录复制的。

　　例如：对于delete 或者update语句，如果使用了limit但是并没有 order by ，这就属于非确定性的语句，就不会被记录

　　2. 对于没有索引条件的update语句，必须锁定更多的数据，降低了数据库的性能。

　　3. insert……select 语句同样也需要锁定大量的数据，对数据库的性能有所损耗。

　　获取更详细的信息可以参考官方文档——Statement-Based的优点和缺点bin-log日志文件默认的格式为Statement-Based，如果想改变其格式在开启服务的时候使用—binlog-format选项，其具体命令如下

　　# mysqld_safe –user=msyql –binlog-format=格式 &

　　bin-log日志文件管理

　　对于bin-log日志文件，其默认的名称为 mysql-bin.xxxxxx。而且还有一个索引文件mysql-bin.index，其中记录了当前所有的bin-log日志文件。

　　对于新的主服务器只有一个bin-log日志文件 mysql-bin.000001。此时所有的操作都有这个文件来记录，如果我们想更换bin-log日志文件，可以使用如下命令

　　Mysql>flush logs;

　　此时会创建一个mysql-bin.000002文件来记录以后的操作。除了使用以上所示的命令以外，当bin-log日志文件达到其最大值的时候也会产生新的bin-log日志文件

　　其文件最大值和文件名包括索引文件的名称可以使用 –max_binlog_size、--log-bin和—log-bin-index 选项来改变，具体命令如下所示：

　　# mysqld_safe –user=msyql –max_binlog_size=文件长度 –log-bin=新的日志文件名称 –log-bin-index=新索引文件名 &

　　对于主服务器来说，总起来一句话：主服务器针对于每一个从服务器都创建一个Binlog dump线程，用来读取bin-log日志中更新的操作将其发送给从服务器，发送完毕以后继续等待bin-log日志是否有更新。