• 1. 概览
• 2. IO thread, SQL thread状态变更
• 3. Master_Log_File，Read_Master_Log_Pos；Relay_Log_File，Relay_Log_Pos；Relay_Master_Log_File，Exec_Master_Log_Pos的具体位置
• 4. 参考资料

1. 概览

  mysql的replication复制可以通过show slave status;
  我们天天都在用，但是对它的理解却不见的很深，
  特别把show slave status的每一项都解析一下
  如下是一个普通的MySQL show slave status的输出：
  admin@localhost : (none) 05:59:24> show slave status\G
  *************************** 1. row ***************************
                 Slave_IO_State: Waiting for master to send event
                    Master_Host: 172.20.164.67
                    Master_User: repl
                    Master_Port: 3306
                  Connect_Retry: 60
                Master_Log_File: mysql-bin.001896
            Read_Master_Log_Pos: 226029100
                 Relay_Log_File: mysql-relay-bin.002014
                  Relay_Log_Pos: 87341525
          Relay_Master_Log_File: mysql-bin.001896
               Slave_IO_Running: Yes
              Slave_SQL_Running: Yes
                Replicate_Do_DB:
            Replicate_Ignore_DB:
             Replicate_Do_Table:
         Replicate_Ignore_Table:
        Replicate_Wild_Do_Table:
    Replicate_Wild_Ignore_Table:
                     Last_Errno: 0
                     Last_Error:
                   Skip_Counter: 0
            Exec_Master_Log_Pos: 226029100
                Relay_Log_Space: 87341723
                Until_Condition: None
                 Until_Log_File:
                  Until_Log_Pos: 0
             Master_SSL_Allowed: No
             Master_SSL_CA_File:
             Master_SSL_CA_Path:
                Master_SSL_Cert:
              Master_SSL_Cipher:
                 Master_SSL_Key:
          Seconds_Behind_Master: 0
  Master_SSL_Verify_Server_Cert: No
                  Last_IO_Errno: 0
                  Last_IO_Error:
                 Last_SQL_Errno: 0
Last_SQL_Error:

做了一个列表，简单注释了一下各个字段的意思，如下：

  这么多信息，有一些是一看就知道是什么意思的字段。
  其他的至少可以分为以下几个专题：

• IO thread, SQL thread状态变更
• Master_Log_File，Read_Master_Log_Pos；Relay_Log_File，Relay_Log_Pos；Relay_Master_Log_File，Exec_Master_Log_Pos的具体位置
• Replicate_Do, Replicate_Ignore 讨论
• mysql ssl连接
• replication文件 master.info, relay.info和连接信息解析
• Seconds_Behind_Master 精确性
• replication until和复制延迟控制
• skip counter忽略event计数和精确性本文只涉及第一和第二个议题

2. IO thread, SQL thread状态变更

1. IO线程状态变更,对应show slave status的Slave_IO_State字段

状态变更图如下：

代码请参考sql/slave.cc的handle_slave_io函数

1. SQL线程状态变更,对应服务器上SQL线程的State字段，通过show processlist查看

状态变更图如下：

代码请参考sql/slave.cc的handle_slave_sql函数

3. Master_Log_File，Read_Master_Log_Pos；Relay_Log_File，Relay_Log_Pos；Relay_Master_Log_File，Exec_Master_Log_Pos的具体位置

1. 定义

• Master_Log_File，Read_Master_Log_Pos 记录了IO thread读到的当前master binlog文件和位置，对应master的binlog文件和位置。
• Relay_Log_File，Relay_Log_Pos记录了SQL thread执行到relay log的那个文件和位置，对应的是slave上的relay log文件和位置。
• Relay_Master_Log_File，Exec_Master_Log_Pos记录的是SQL thread执行到master binlog的文件和位置，对应的master上binlog的文件和位置。

1. 日志文件介绍需要明确这几个值的意思，我们首先需要了解binlog日志文件和relay log日志文件的具体结构。binlog的文件格式可以参考 Mats Kindah和Lars Thalman的binlog API文档。binlog的event可以参考我之前的blog和binlog events 介绍
   • binlog数据文件示例binlog文件和relay log文件都可以用mysqlbinlg工具来打开。下图是一个mysqlbinlog解析普通的binlog文件出来的文本文件：我们这里主要是row方式的binlog。

     注意：binlog的event语句开始位置就是二进制binlog文件的字节偏移位置。而且根据上一个event的end_log_pos可以找到下一个event开始的位置，如上图所示。

• relay log数据文件示例binlog文件和relay log文件都可以用mysqlbinlg工具来打开。下图是一个mysqlbinlog解析普通的relay log文件出来的文本文件：relay log和binlog记录方式基本相同，最大的不同就是end_log_pos记录的是master的binlog文件中event的位置，而不是relay log自己event的位置。如图所示，上一个event的end_log_pos和下一个relay log event开始的位置不一样。

为什么需要这样设置？原因很简单，就是为了方便找到master binlog的位置，在slave上，记录relay log 下一个event的开始偏移意义不大，但是如果记录了master binlog的偏移量，我们就可以在SQL thread中明确我们执行到master的某个binlog的哪个位置了。那么是哪个binlog列。我们找到relay log的最前面。

如图所示，每个relay log开头都有这么一个rotate event，也就是当前master的binlog文件名。引用一下Automated master failover的一页PPT如下。

这里列出了Read_Master_Log_Pos，Relay_Log_Pos，Exec_Master_Log_Pos 的具体位置。

• IO thread 把所有从master读到的binlog记录到本地的binlog中，所以relay log的最后一个event的end log_pos就是Read_Master_Log_Pos
• SQL thread 按照transaction来执行，所以Exec_Master_Log_Pos对应relay log中最后一个事务event的end_log_pos，这个位置对应的是master的binlog的位置。
• Relay_Log_Pos 记录的是SQL thread执行的event在relay log中结束位置，这个才是relay log的偏移量。

4. 参考资料

mysql reference IO 线程状态

mysql reference SQL 线程状态

mysql reference show slave status

binlog events

binlog API

Automated master failover

最近做了一些搭建复制和迁移替换MySQL备机的工作。
特别记录下来MySQL非常规change master的小技巧。

1、问题1：
A<->B
C
A和B相互复制，应用访问A，现在需要搭建A到C的复制。A和B不对等，尽量避免应用切换到访问B。
回答：
在B上做备份，由于B是standby；不管你是做冷备，逻辑热备，逻辑冷备...都可以，把数据导入到C。
之后，搭建B到C的复制如下：
A <-> B -> C
这里停掉B的IO 线程，来确保B的SQL线程已经赶上IO线程，
此时，B不再赶A的复制，并且确定B到C的复制延迟都为0以后。
B和C的数据是保持完全一致的。
那么此时B复制到的位置就可以作为C change master 的位置。
简单写的脚本如下：
while read LINE; do
    OFFER_D_IP=`echo "$LINE" | awk '{print $1}'`
    OFFER_D_SOCK=`echo "$LINE" | awk '{print $2}'`

    SLAVE_STATUS_D=`ssh -n root@$OFFER_D_IP "mysql -S $OFFER_D_SOCK -uroot -pxxxx -e 'show slave status\G'"`
    OFFER_B_IP=`echo "$SLAVE_STATUS_D" | grep 'Master_Host:' | awk '{print $2}'`

    # stop io thread of offer b
    ssh -n root@$OFFER_B_IP "mysql -S /data/mysqldata/sock/mysql.sock -uroot -pxxxx -e 'stop slave io_thread'";

    # check if offer b, offer d slave have catch up
    #SLAVE_STATUS_D=`ssh -n root@$OFFER_D_IP "mysql -S $OFFER_D_SOCK -uroot -pxxxx -e 'show slave status\G'"`
    while [ 1 ]; do
        SECOND_BEHIND=`echo "$SLAVE_STATUS_D" | grep 'Seconds_Behind_Master:' | awk '{print $2}'`
        if [ $SECOND_BEHIND -eq 0 ]; then
            break
        fi
        sleep 1
    done
    SLAVE_STATUS_B=`ssh -n root@$OFFER_B_IP "mysql -S /data/mysqldata/sock/mysql.sock -uroot -pxxxx -e 'show slave status\G'"`
    while [ 1 ]; do
        SECOND_BEHIND=`echo "$SLAVE_STATUS_B" | grep 'Seconds_Behind_Master:' | awk '{print $2}'`
        if [ "x$SECOND_BEHIND" == "xNULL" ]; then
            break
        fi

        sleep 1
    done

    # build change master sql
    MASTER_HOST=`echo "$SLAVE_STATUS_B" | grep 'Master_Host:' | awk '{print $2}'`
    MASTER_LOG_FILE=`echo "$SLAVE_STATUS_B" | grep 'Relay_Master_Log_File:' | awk '{print $2}'`
    MASTER_LOG_POS=`echo "$SLAVE_STATUS_B" | grep 'Exec_Master_Log_Pos:' | awk '{print $2}'`
    CHANGE_MASTER_SQL="stop slave; CHANGE MASTER TO MASTER_HOST='$MASTER_HOST',    MASTER_PORT=3306,  MASTER_USER='repl',     MASTER_PASSWORD='xxxx',     MASTER_LOG_FILE='$MASTER_LOG_FILE',     MASTER_LOG_POS=$MASTER_LOG_POS;  start slave;"
    echo "$CHANGE_MASTER_SQL"

    # change master of offerd
    ssh -n root@$OFFER_D_IP "mysql -S $OFFER_D_SOCK -uroot -pxxxx -e \"$CHANGE_MASTER_SQL\""
    ssh -n root@$OFFER_D_IP "mysql -S $OFFER_D_SOCK -uroot -pxxxx -e 'show slave status\G'"

    # start offer d slave
    ssh -n root@$OFFER_B_IP "mysql -S /data/mysqldata/sock/mysql.sock -uroot -pxxxx -e 'start slave'"

done  <host.list
该脚本读取host.list参数文件获得C(OFFER_D)的IP和sock。B的IP通过C的show slave status获得。

问题2、
D <- A <-> B -> C
A和B互为主备，C为B的备机，D为A的备机。需要把C change master到D。形成：
C <- D <- A <-> B
的结构
回答：
这里我们在A上故意制造了binlog复制错误。
set sql_log_bin=0; use test; create table test_del (id int NOT NULL AUTO_INCREMENT, PRIMARY KEY(id)); set sql_log_bin=1; drop table test_del;
使得B和D都停止在同一个复制位置。也就是说，此时B和D的数据是完全一致的。
这样在D上show master status\G就是C change master 的位置。
简单写了一个脚本如下：
while read LINE; do
    XY_OFFER_A_IP=`echo "$LINE" | awk '{print $1}'`
    XY_OFFER_B_IP=`echo "$LINE" | awk '{print $2}'`
    QD_OFFER_C_IP=`echo "$LINE" | awk '{print $5}'`
    QD_OFFER_C_SOCK=`echo "$LINE" | awk '{print $6}'`
    XY_OFFER_D_IP=`echo "$LINE" | awk '{print $7}'`
    XY_OFFER_D_SOCK=`echo "$LINE" | awk '{print $8}'`
    echo "$XY_OFFER_A_IP"
    echo "$XY_OFFER_B_IP"
    echo "$QD_OFFER_C_IP"

    MYSQL_ROOT_PASS="xxxx"

    ssh -n root@$XY_OFFER_A_IP "mysql -uroot -p$MYSQL_ROOT_PASS -e 'set sql_log_bin=0; use test; create table test_del (id int NOT NULL AUTO_INCREMENT, PRIMARY KEY(id)); set sql_log_bin=1; drop table test_del;'"

    while [ 1 ]; do
        XY_SLAVE_STATUS_D=`ssh -n root@$XY_OFFER_D_IP "mysql -S $XY_OFFER_D_SOCK -uroot -p$MYSQL_ROOT_PASS -e 'show slave status\G'"`
        SLAVE_SQL_STATUS=`echo "$XY_SLAVE_STATUS_D" | grep 'Slave_SQL_Running:' | awk '{print $2}'`
        if [ "x$SLAVE_SQL_STATUS" == "xNo" ]; then
            break
        fi
        sleep 1
    done

    while [ 1 ]; do
        XY_SLAVE_STATUS_B=`ssh -n root@$XY_OFFER_B_IP "mysql -S /data/mysqldata2/sock/mysql.sock -uroot -p$MYSQL_ROOT_PASS -e 'show slave status\G'"`
        SLAVE_SQL_STATUS=`echo "$XY_SLAVE_STATUS_B" | grep 'Slave_SQL_Running:' | awk '{print $2}'`
        if [ "x$SLAVE_SQL_STATUS" == "xNo" ]; then
            break
        fi
        sleep 1
    done

    # now we have xy-offer-d and xy-offer-b slave stop at the same place
    # we can now change master of qingdao-offer-c from xy-offer-b to xy-offer-d
    XY_MASTER_STATUS=`ssh -n root@$XY_OFFER_D_IP "mysql -S $XY_OFFER_D_SOCK -uroot -p$MYSQL_ROOT_PASS -e 'show master status\G'"`
    MASTER_LOG_FILE=`echo "$XY_MASTER_STATUS" | grep 'File:' | awk '{print $2}'`
    MASTER_LOG_POS=`echo "$XY_MASTER_STATUS" | grep 'Position:' | awk '{print $2}'`
    ssh -n root@$QD_OFFER_C_IP "mysql -S $QD_OFFER_C_SOCK -uroot -p$MYSQL_ROOT_PASS -e \"stop slave; CHANGE MASTER TO MASTER_HOST='$XY_OFFER_D_IP',    MASTER_PORT=3306,  MASTER_USER='repl',     MASTER_PASSWORD='xxxx',     MASTER_LOG_FILE='$MASTER_LOG_FILE',     MASTER_LOG_POS=$MASTER_LOG_POS;  start slave;\""

    # now we start the slave of xy offer b and xy offer d slave
    ssh  -n root@$XY_OFFER_D_IP "mysql -S $XY_OFFER_D_SOCK -uroot -p$MYSQL_ROOT_PASS  -e 'stop slave; SET GLOBAL sql_slave_skip_counter = 1; start slave;'";
    ssh  -n root@$XY_OFFER_B_IP "mysql -S /data/mysqldata2/sock/mysql.sock -uroot -p$MYSQL_ROOT_PASS  -e 'stop slave; SET GLOBAL sql_slave_skip_counter = 1; start slave;'";

done  <host.list
该脚本读取host.list参数文件获得A(XY_OFFER_A)，B(XY_OFFER_B)的IP，C(QD_OFFER_C)的IP和sock，D(XY_OFFER_D)的IP和sock。

may your success

may your success

我们有一套环境使用的是MySQL的多实例，并且我们MySQL不是放在MySQL认为应该放的目录：/usr/local/mysql下，所以今天又一个悲剧了。
数据库主机创建了一个ascii为字符集的表，主机创建成功，但是传到备机执行的时候，出错：
110510 17:14:55 [Warning] Slave: Unknown character set: ‘ascii’ Error_code: 1115
也就是说备机没有ascii字符集。
好吧，那就SHOW CHARACTER SET来看看，确实没有。
但是主机确实是有的，主备机的SHOW CHARACTER SET是不一样的。。。

好吧，其实我们备机使用的是多实例，主机是单实例。并且备机的MySQL采用的是二进制包的绿色安装。
那么这里就有一个问题，我们使用的mysqld_multi启动MySQL时它采用的是什么样的默认配置，这样的配置是否都是正确的
我们其实并不是非常肯定。
这里ascii字符集就是一个问题。

mysql的字符集配置详细请见：http://dev.mysql.com/doc/refman/5.1/en/charset-configuration.html
这里我们的备机用mysqld_multi启动以后，
show variables like ‘character_sets_dir’;
显示为：/usr/local/mysql/share/charsets。
而这个目录根本就不存在。

解决这个问题其实有三个办法：
1、mkdir -p /usr/local/mysql/share/; ln -s /path/to/correct/share/charsets /usr/local/mysql/share/charsets。
2、修改mysqld_multi，使得指向正确的目录。(目前这个办法没有走通，有待跟进)
3、在my.cnf中添加：character_sets_dir=/path/to/correct/share/charsets/
由于这个参数是read-only的，你只能重启MySQL来使它生效了

唉，其实作为一个MySQL DBA，连MySQL的这些配套的脚本都没有详细的搞清楚，有点汗颜，需要好好看一下。
如果你嫌麻烦，还是建议你把MySQL的二进制包放在MySQL指定的/usr/local/mysql下把，避免意外。

may your success

为了提高开发人员和部门内部MySQL使用的技能和深度，我们特别制作了一些开发培训的计划，下面是一些主题

mysql应用开发培训
mysql安装的三种方式：rpm安装，tar.gz安装，configure安装
mysql 数据类型和函数，字节数，最大最小值，
mysql 适用SQL和不适用SQL。哪些SQL应该杜绝，哪些SQL应该避免，哪些在oracle适用但是尽量避免在MySQL中使用。
mysql 索引，约束，索引是否越多越好，覆盖索引，主键索引。
mysql 自定义函数以及procedure。delimiter,游标，调用，
mysql 视图，子查询，连接，union。不使用视图的原因，子查询的弊端，替换方案，内联接，外联接，union all和union的区别，使用场景。
mysql 分页limit,以及简单的实现原理
mysql 存储引擎介绍和比较。至少包括innodb,MyISAM,csv,memory,federated,ndb

mysql管理维护培训
mysql 备份和恢复。包括物理冷备；mysqldump； select into outfile；xtrabackup备份，优缺点，限制和使用场景。
mysql 复制搭建。步骤：备份并恢复数据；获得主机备份位置的binlog；change master
mysql binlog介绍。三种格式，分别的优缺点，statement复制的安全问题，row方式下目前我们遇到的几个问题。
mysql show processlist中，各个查询的状态的含义：query，NULL，executing，update等等。
mysql show engine innodb status介绍。
mysql show slave status输出详细解释。包括master.info,relay-log.info,logbin.index,relay-log.index, logbin.0001,relay-log.0001解释，slave io和slave sql 的不同状态含义
mysql 用户权限介绍。localhost,127.0.0.1，%的不同点。限制IP，限制数据库，限制表，限制字段，数据库或者表等的单字匹配以及多字匹配。
mysql 工具介绍：目前我们使用比较频繁的工具：mysql;mysqld_safe;mysqladmin;mysqlcheck;mysql_install_db;mysqlbinlog;mysqldump;mysqld_multi;以及第三方工具innotop;maatkit;mysqlsla
mysql my.cnf介绍。作用，mysql默认的位置，组的概念，工具特定参数介绍。
mysql 多实例概念和管理
mysql information_schema介绍，peconar新增信息介绍。
mysql ’mysql‘schema介绍，对应表信息。
mysql cluster介绍，性能问题，内存问题。

mysql高级培训
mysql configure安装的配置参数
mysql 源码框架和文件介绍
mysql binlog格式，二进制解释。文件头，event分类，二进制格式。
innodb 物理文件格式介绍以及数据恢复方法，实用案例分析，最终导出数据展示。
innodb 锁介绍
mysql 参数介绍。
mysql 状态变量介绍.目前在性能视图中的变量有哪些
mysql 大事务情况下，show slave status锁分析，解决方案。
mysql 唯一约束和普通索引在加锁上的区别。

sql培训单独列出，不包含在这些内容里面

一直使用xtrabackup来备份MySQL，之前也没有出过特别的问题，但是在备份我们的一个库的时候，出现了：Bad file descriptor的错误
具体错误类似如下：
InnoDB: Operating system error number 9 in a file operation.
InnoDB: Error number 9 means ‘Bad file descriptor’.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.1/en/operating-system-error-codes.html
InnoDB: File operation call: ‘close’.
InnoDB: Cannot continue operation.

仔细检查，发现用户的权限有点问题；修改好了以后，再次备份，还是有问题。
然后看看这个机器跟其他机器的不同点：他的数据文件是链接到另外的mount点的，但是这个为什么会影响xtrabackup出错真是搞不懂。
有问题找google，还好搜到一篇好文章，有人也碰到了这个问题。

https://bugs.launchpad.net/percona-xtrabackup/+bug/568087

问题一样，还有人解决了，一直追到：http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/133
仔细一看，这个版本是release版本之后的修改，也就是说，现成的rpm包我们是没有办法用了。
只好自己编译。
好吧，那就自己编译，还好之前在solaris上编译有经验。
这里也简单记录一下编译的一些步骤：
1、133版 http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/133 下只有xtrabackup.c下载，我们可以自己到http://launchpad.net/percona-xtrabackup/release-1.2/1.2/+download/xtrabackup-1.2.tar.gz下载1.2版的源码。并把里面的xtrabackup.c替换掉。
2、xtrabackup-1.2/utils对应的目录里面有build51tree.sh， buildtree.sh分别是在linux下编译5.0和5.1版xtrabackup的脚本
3、正常的话，按照xtrabackup-1.2/Makefile里面的默认的配置是MySQL Plugin并使用XTRADB。而我并不想这样，所以我注释掉了DEFS+=  -DXTRADB_BASED和#MySQL Plugin下面的那些编译项。但是编译还是报错，查看了之前solaris编译时的注意实现发现要注释掉#MySQL 5.1下的第二个INNODBOBJS=。不知道为什么Makefile这边有两个这样的INNODBOBJS=，管它，注释掉第二个以后编译就成功。
用新版本备份，备份成功。

其实后面看了一下这个版本修改的代码：
2326
2326

2327
2327
/* close */
2328
2328
printf(“        …done\n”);
2329

os_file_close(src_file);

2329
if (!node->open) {

2330
os_file_close(src_file);

2331
}
2330
2332
os_file_close(dst_file);
2331
2333
ut_free(buf2);
2332
2334
return(FALSE);
2333
2335
error:
2334

if (src_file != -1)

2336
if (src_file != -1 && !node->open)
2335
2337
os_file_close(src_file);
2336
2338
if (dst_file != -1)
2337
2339
os_file_close(dst_file);
就那么几行，是因为没有判断节点是否还打开，结果导致出错，唉，程序的异常处理确实需要比程序本身的逻辑复杂很多啊。
不过还是没有想明白为什么这台机器就有问题，其他的都没有问题。

may your success.

有三台MySQL服务器，a,b和c，复制关系为 a -> b -> c。a,b,c的server_id分别为1，2，3
因为需要切换为 a b <-> c，也就是说，a单独出来，b和c作为双master结构时。
这种切换会经常出现在需要搭建备机把数据备份出来，然后把a独立出来的case中。

昨天，我就做了这样的切换，结果发现出现莫名奇妙的slave lag。
Seconds_Behind_Master一下子为0，一下子变成几千秒。
使用mysqlbinlog查看，binlog日志里面也有很多时间在几小时以前的event数据。
为了验证复制是否正常，我特别测试了一下，在b建一个表，并插入时间数据，到c上一看，表已经复制过来了，时间数据也是正确。
询问了一下同事，他说应该是MySQL的bug，在这种切换的情况下很容易触发这个bug，可以采用stop slave;change master; start slave;的方法来修复。但是实际的数据其实完全没有影响，复制还是正常的。

于是我按照这个办法:
stop slave io_thread;
stop slave;
show slave status\G
(这里先停io_thread是为了SQL thread和IO thread都执行到了同一个位置，change master 的时候没有风险)
stop slave;change master to … ; start slave;
(change master到show slave status的Master_Log_File:和Exec_Master_Log_Pos:位置，也就是说，其实根本没有改变复制的位置)

结果slave lag依然故我。这个问题就比较郁闷了。时间已经过了午夜，脑袋也转不动了，想过不管它了，反正复制没有问题。但是问题没有解决总觉得什么东西卡在喉咙一样。各种资料，各种变量都参考了一遍，最后，基本不太意识的输入:
show master logs;
show binlog events in ‘mysql-bin.000680′ from 34385301;
想看看最新产生的event，结果就发现不对的地方了。
这个最新产生的event有很多，并且server_id是1，1是a的server_id啊，应用访问的是b啊，怎么会在b上面产生a的server_id列，MySQL哪里出问题了？

仔细一想，明白了，事情是这样的：
a -> b -> c，a的event1(server_id为1)复制到b，也会复制到c，这个是正常的。
然后搭建c -> b的复制关系时，b需要断开a的连接，切换主库到c，在 change master 的位置在event1出现之前，那么event1肯定会被重新复制到b去，event1的server_id是1，那么b判断，这个event1不是我提交的，需要在本地执行，并且把它记录到了自己的binlog中；
由于b和c是双master结构，event1又复制到了c，c同样判断它不是我提交的，那么我需要在本地执行，并且记录到本地binlog中。
这样event1就在b和c之间循环往复，时间保持不变，MySQL的slave lag也就一下子是0，一下子是几千秒了。

这里，还需要说明一点，在环型复制里面，event之所以能够在环内只循环一次，而不是重复做，是因为提交的那个节点会发现这个event的server_id是自己的server_id，也就是说是自己提交的。那么，它就不会把这个event再应用一次，自然也不会记录到binlog。这个循环就结束了。除非你闲着没事做，设置了replicate-same-server-id参数。

那么解决问题怎么办列，很简单，把没有应用访问的c的server_id设置成a的server_id：
set global server_id=1;
看看时间差不多了，server_id为1的event都被干掉以后：
set global server_id=3;
然后再设置回来。
还好，MySQL 5.0和5.1的server_id都是动态的。

may your success.