mysql主从复制的实现细节（一）主服务器探究-ag捕鱼王app官网

这篇文章主要从主从复制的实现机制方面来进行论述，可能对于我们实际应用没有直接的帮助，但是理解其原理毕竟对于以后的维护和优化能起到事半功倍的效果。由于本人水平有限，文字之中有欠妥的地方还请大家批评指正。

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. finished reading one binlog; switching to next binlog
表示binlog dump 线程已经读取完一个binlog日志，现在正在打开下一个binlog日志读取来发送给从服务器

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

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

上述几个状态就是一次主从复制过程中binlog dump 线程所经历的状态，如果我们是在测试的环境中，上述1、2、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。

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 语句同样也需要锁定大量的数据，对数据库的性能有所损耗。

获取更详细的信息可以参考

row-based优点和缺点分析

优点

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

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

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

缺点

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

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

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

获取更详细的信息可以参考

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日志是否有更新。