mysql同步之1

答案：手册来源：MySQL手册版本 5.0.20，出处：http://imysql.cn，转载请注明译者和出处，并且不能用于商业用途，违者必究。

　　6 MySQL 同步

　　同步功能在MySQL 3.23.15就开始引进了，它可以把一个MySQL服务器上的数据复制到另一个服务器上去。本章描述了MySQL的各种复制特性。介绍了同步的概念，如何设置同步服务器，以及可用服务器的参照。还提供了一系列的常见问题及其答案，疑难解答。 "14.6 Replication Statements"中介绍了同步相关的SQL语句语法。我们建议经常访问"http://www.mysql.com"经常阅读本章的最新内容。同步功能一直在改进，我们经常把这部分的手册更新到当前的最新内容。

　　6.1 同步介绍

　　MySQL 3.23.15及更新的版本支持单向同步。一个服务器作为master(主服务器)，一个或者多个服务器作为slave(从服务器)。master服务器把更新的内容写到二进制日志(binary log或binlog)中，并且维护了一个索引文件来记录日志循环的情况。这些日志中的更新部分会被发送到slave服务器。一个slave连接到 master之后，它通知master最后一次成功增量更新的日志位置。slave会找出所有从那个时刻开始的更新操作，然后阻塞并等待master发送新的更新操作。如果想要做一个同步服务器链的话，slave同时也可以作为master。注意，启用同步后，所有要同步的更新操作都必须在master上执行。否则，必须注意不要造成用户在master上的更新和在slave上的更新引起冲突。

　　单向同步的好处是稳健，高速，系统易管理：

　　* 有了master/slave机制后，就更稳健了。当master上发生问题时，可以把slave作为备用切换过去。

　　* 可以在slave和master之间分担一些查询，这就能加速响应时间。SELECT 查询就可以在slave上执行以减少master的负载。更新数据的语句则要放在mater上执行以保持master和slave的同步。当非更新操作占多数时，负载均衡就很有效了，不过这只是普通情况而言。

　　* 另一个好处是可以在slave上备份数据，无需干扰master。备份数据时master照样继续运作。详情请看"5.7.1 Database Backups"。

　　6.2 同步机制实现概述

　　MySQL同步机制基于master把所有对数据库的更新操作(更新、删除 等)都记录在二进制日志里。因此，想要启用同步机制，在master就必须启用二进制日志。详情请看"5.9.4 The Binary Log"。

　　每个slave接受来自master上在二进制日志中记录的更新操作，因此在slave上执行了这个操作的一个拷贝。应该非常重要地意识到，二进制日志只是从启用二进制日志开始的时刻才记录更新操作的。所有的slave必须在启用二进制日志时把master上已经存在的数据拷贝过来。如果运行同步时slave上的数据和master上启用二进制日志时的数据不一致的话，那么slave同步就会失败。

　　把master上的数据拷贝过来的方法之一实在slave上执行 LOAD DATA FROM MASTER 语句。不过要注意，LOAD DATA FROM MASTER 是从MySQL 4.0.0之后才开始可以用的，而且只支持master上的 MyISAM 类型表。同样地，这个操作需要一个全局的读锁，这样的话传送日志到slave的时候在master上就不会有更新操作了。当实现了锁自由表热备份时(在MySQL 5.0中)，全局读锁就没必要了。

　　由于有这些限制，因此我们建议只在master上相关数据比较小的时候才执行 LOAD DATA FROM MASTER 语句，或者在master上允许一个长时间的读锁。由于每个系统之间 LOAD DATA FROM MASTER 的速度各不一样，一个比较好的衡量规则是每秒能拷贝1MB数据。这只是的粗略的估计，不过master和slave都是奔腾700MHz的机器且用100MBit/s网络连接时就能达到这个速度了。

　　slave上已经完整拷贝master数据后，就可以连接到master上然后等待处理更新了。如果master当机或者slave连接断开，slave会定期尝试连接到master上直到能重连并且等待更新。重试的时间间隔由 --master-connect-retry 选项来控制，它的默认值是60秒。每个slave都记录了它关闭时的日志位置。msater是不知道有多少个slave连接上来或者哪个slave从什么时候开始更新。

　　6.3 同步实现细节

　　MySQL同步功能由3个线程(master上1个，slave上2个)来实现。执行 START SLAVE 语句后，slave就创建一个I/O线程。I/O线程连接到master上，并请求master发送二进制日志中的语句。master创建一个线程来把日志的内容发送到slave上。这个线程在master上执行 SHOW PROCESSLIST 语句后的结果中的 Binlog Dump 线程便是。slave上的I/O线程读取master的 Binlog Dump 线程发送的语句，并且把它们拷贝到其数据目录下的中继日志(relay logs)中。第三个是SQL线程，salve用它来读取中继日志，然后执行它们来更新数据。

　　如上所述，每个mster/slave上都有3个线程。每个master上有多个线程，它为每个slave连接都创建一个线程，每个slave只有I/O和SQL线程。

　　在MySQL 4.0.2以前，同步只需2个线程(master和slave各一个)。slave上的I/O和SQL线程合并成一个了，它不使用中继日志。

　　slave上使用2个线程的优点是，把读日志和执行分开成2个独立的任务。执行任务如果慢的话，读日志任务不会跟着慢下来。例如，如果slave停止了一段时间，那么I/O线程可以在slave启动后很快地从master上读取全部日志，尽管SQL线程可能落后I/O线程好几的小时。如果slave 在SQL线程没全部执行完就停止了，不过I/O线程却已经把所有的更新日志都读取并且保存在本地的中继日志中了，因此在slave再次启动后就会继续执行它们了。这就允许在master上清除二进制日志，因为slave已经无需去master读取更新日志了。

　　执行 SHOW PROCESSLIST 语句就会告诉我们所关心的master和slave上发生的情况。下例说明了 SHOW PROCESSLIST 结果中的3个线程是什么样的。这是在MySQL 4.0.15及更新上执行 SHOW PROCESSLIST 的结果，State 字段的内容已经比旧版本显示的更有意义了。

　　在master上，SHOW PROCESSLIST 的结果如下：

　　mysql> SHOW PROCESSLIST\G

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

　　Id: 2

　　User: root

　　Host: localhost:32931

　　db: NULL

　　Command: Binlog Dump

　　Time: 94

　　State: Has sent all binlog to slave; waiting for binlog to

　　be updated

　　Info: NULL

　　在这里，线程2是为一个slave连接创建的。结果表明所有未完成的更新日志已经都发送到slave了，master正等待新的更新日志发生。在slave上，SHOW PROCESSLIST 的结果如下：

　　mysql> SHOW PROCESSLIST\G

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

　　Id: 10

　　User: system user

　　Host:

　　db: NULL

　　Command: Connect

　　Time: 11

　　State: Waiting for master to send event

　　Info: NULL

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

　　Id: 11

　　User: system user

　　Host:

　　db: NULL

　　Command: Connect

　　Time: 11

　　State: Has read all relay log; waiting for the slave I/O

　　thread to update it

　　Info: NULL

　　这表明线程10是I/O线程，它正连接到master上；线程11是SQL线程，它执行中继日志中的更新操作。现在，这2个线程都处于空闲状态，正等待新的更新日志。注意，Time 字段的值告诉我们slave上的日志比master晚了多久。详情请看"6.9 Replication FAQ"。

　　6.3.1 Master 同步线程状态

　　以下列出了master的 Binlog Dump 线程 State 字段中最常见的几种状态。如果在master上没有 Binlog Dump 线程，那么同步就没有在运行。也就是说，没有slave连接上来。

　　Sending binlog event to slave

　　事件是由二进制日志构成，一个事件通常由更新语句加上其他信息。线程读取到一个事件并正发送到slave上。

　　Finished reading one binlog; switching to next binlog

　　读取完了一个二进制日志，正切换到下一个。

　　Has sent all binlog to slave; waiting for binlog to be updated

　　已经读取完全部未完成更新日志，并且全部都发送到slave了。它处于空闲状态，正等待在master上执行新的更新操作以在二进制日志中产生新的事件，然后读取它们。

　　Waiting to finalize termination

　　当前线程停止了，这个时间很短。

　　6.3.2 Slave的I/O线程状态

　　以下列出了slave的I/O线程 State 字段中最常见的几种状态。从MySQL 4.1.1开始，这个状态在执行 SHOW SLAVE STATUS 语句结果的 Slave_IO_State 字段也会出现。这意味着可以只执行 SHOW SLAVE STATUS 语句就能了解到更多的信息。

　　Connecting to master

　　该线程证尝试连接到master上。

　　Checking master version

　　确定连接到master后出现的一个短暂的状态。

　　Registering slave on master

　　确定连接到master后出现的一个短暂的状态。

　　Requesting binlog dump

　　确定连接到master后出现的一个短暂的状态。该线程向master发送一个请求，告诉它要请求的二进制

上一个：Mysql数据库字符集转换及版本升级/降级的详细教程
下一个：mysql同步之2