Mysql主从复制的实现细节（一）主服务器探究
这篇文章主要从主从复制的实现机制方面来进行论述，可能对于我们实际应用没有直接的帮助，但是理解其原理毕竟对于以后的维护和优化能起到事半功倍的效果。由于本人水平有限，文字之中有欠妥的地方还请大家批评指正。
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 语句同样也需要锁定大量的数据，对数据库的性能有所损耗。
获取更详细的信息可以参考官方文档——Statement-Based的优点和缺点
Row-Based优点和缺点分析
优点
1. 所有的改变都会被复制，这是最安全的复制方式
2. 对于 update、insert……select等语句锁定更少的行
3. 此种方式和大多数的数据库系统一样，所以了解其他的系统的人员可以很容易的转到mysql
缺点
1. 使用不方便，我们不能通过bin-log日志文件查看什么语句执行了，也无从知道在从服务器上接收到什么语句，我们只能看到什么数据改变了
2. 因为记录的是数据，所以说bin-log日志文件占用的存储空间要比Statement-based大。
3. 对于数据量大的操作其花费的时间有更长
获取更详细的信息可以参考官方文档——Row-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日志是否有更新。
本文转载自：迹忆客（https://www.jiyik.com）
以上是 Mysql主从复制的实现细节（一）主服务器探究 的全部内容， 来源链接： utcz.com/z/290023.html
