分类目录归档：同步中的Bug

MySQL运行中被改权限测试

发表于由

作者：吴炳锡　来源：http://wubx.net/ 联系方式： wubingxi#163.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

今天一个接到一个朋友求助，说是数据在运行中，数据库的目录被改了权限。如： 数据库目结构如下：

datadir=/data/mysql/mysql3306/data
log-bin = /data/mysql/mysql3306/logs
tmpdir  = /data/mysql/mysql3306/tmp

被运维同步执行了：

chown -R  root:root /data/mysql/mysql3306

1.构建主从环境

mysql;3306 主
/data/mysql/mysql3306/{data,tmp,logs}
mysql;3307 从
/data/mysql/mysql3307/{data,tmp,logs}

2. 在主的wubx库里创建：

CREATE TABLE `t2` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(32) DEFAULT NULL,
PRIMARY KEY (`id`)
)

确认复制正常。

3. 把主库的目录权限改成root

chown -R root:root /data/mysql/mysql3306

4. 弄出来大量的写入

for i in `seq(100000); do mysql wubx -e "insert into t2(name) vlaues('golang$i')"; done

5. 观查主库和从库上数据
发现日志没有切换时，数据都可以写入，同步正常。 主库上binlog还可以正常写入。

6. 模拟日拟切换
主库上执行: flush logs;
得到报错:
切换日志错误

从库同步报错：
1595错误
show slave status\G;
show slave status\G;

从这里看出来，从库获取到主库日志切换指令，但主库没能创建出来新的日志，所以造成复制中断。

7.结论
主库上不影响数据写入，但发生日志切换后，不能进行新的日志写入，但没卡住写入。
从库上在主库日志发生切后，能得到新的日志文件名，但不能获到新的日志，所以同步停掉。

8.修复建议：
通过实验说明，主库上的数据是最全的，在后续日志切换失败后，没有影响数据的写入。但数据没有同步到从上。

 

思考：

这个有点是mysqld的一个bug的感觉了，日志已经无法写入，但数据还可以写入。 很容易造成同步有问题。 对于数据不同步怎么修复。多次给学生们讲过，也能很快的把环境处理好。

Good luck!

truncate table 不能复制到从库

发表于由

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究。

          bug说明： 该BUG在是MySQL5.1.X中存在的一个问题。
重现方法：
        利用 5.1.31-enterprise-gpl-pro-log (Or 5.1.31-sp1-enterprise) 搭建master/slave结构同步正常进行（确认同步进行）
 注意参数：
事务隔级为： READ-COMMITTED
日值格式为： mixed

然后在主库建表：

create database wubx;
create table t1 (id int) engine=innodb;
insert into t1 values(1),(2),(3),(4),(5);
select * from t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+

从库：

use wubx;
select * from t1 ;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+

主库上：

use wubx;
mysql> truncate table t1;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t1;
Empty set (0.01 sec)

从库：

use wubx;
select * from t1 ;
+------+
| id |
+------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+------+

解决办法：
先删除该表，然后创建该表。
如: truncate table wubx;改变为：

drop table wubx;
create table wubx( id int) engine=innodb;

另一种方式：
修改事务隔离级别为默认的。可以MySQL的版本升级到MySQL-5.1.37后的版本。

Relay log read failure的处理

发表于由

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式：select unhex(’777562696E67786940676D61696C2E636F6D’); 载请注明作/译者和出处，并且不能用于商业用途，违者必究。
       众所周知MySQL5.1的Replication是比较烂的。MySQL的每一个版本更新关于同步方面每次都是可以看到一大堆。但MySQL 5.1性能是比较突出的。所以经不住诱惑使用MySQL 5.1。所以也要经常遇到一些Bug。如： 

   
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.118
                  Master_User: repl_wu
                  Master_Port: 3306
                Connect_Retry: 30
              Master_Log_File: mysql-bin.005121
          Read_Master_Log_Pos: 64337286
               Relay_Log_File: relay-bin.003995
                Relay_Log_Pos: 18446697137031827760
        Relay_Master_Log_File: mysql-bin.005121
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 4
              Relay_Log_Space: 64337901
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
1 row in set (0.00 sec)
 

        从上面可以看到是中继日值或是Master上的日值出问题了。
        首先如果是中继日值坏掉，那只需要找到同步的时间点，然后重新同步，这样就可以有新的中继日值了。如果Master上的日值坏了就麻烦了。
从经验来看，这是中继日值出问题了。处理方法：

    需要找到同步的点。

日值为：Master_Log_File: mysql-bin.005121，Relay_Master_Log_File: mysql-bin.005121以Relay_Master_Log_File为准，Master_Log_File为参考。

日值执行时间点：

Exec_Master_Log_Pos: 4

那么现在就可以：

  
      mysql>stop slave;

    mysql>change master to Master_Log_File=’mysql-bin.005121’, Master_Log_Pos=4;
   
    mysql>start slave;

    mysql>show slave status\G;

    进行确认。

 

   建议：

    在使用MySQL-5.1.36以下的版本的同学，请尽快升级到MySQL-5.1.40 & MySQL-5.1.37sp1