MySQL内核月报 2014.10-MySQL· 捉虫动态·binlog重放失败

背景

在 MySQL 日常维护中,要回滚或者恢复数据,我们经常会用 binlog 来在数据库上重放,执行类似下面的语句:

mysqlbinlog mysql-bin.000001 | mysql -hxxxx -Pxx -u

最近遇到了这样一个问题,在重放 binlog 时,mysqld 报这样的错

ERROR 1064 (42000) at line 25: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DELIMITER ;


分析

上面的错是说语法不对,难道是 binlog 写错了,为了方便查看,先把 mysqlbinlog 解析结果保存到一个文件

mysqlbinlog mysql-bin.000001 > abc.sql

然后打开 abc.sql 文件,会看到这样的语句

"CREATE TABLE t_binlog_sbr(a int)^@"

最后面的奇怪的 "^@" 这是啥呢,我们用二进制方式打开文件后,发现这个其实是1个字节,值是 00,被显示成 "^@"了。

为啥后面会多 1 个 0 呢,后来发现是用户在用 MySQL C API 时用错了,具体是这个函数 mysql_real_query,基原型是

int mysql_real_query(MYSQL *mysql, const char *stmt_str, unsigned long length)

详细说明参考这里,length 参数表示 stmt_str 的长度,所以正常的调用应该是这样的:

mysq_real_query(mysql, sql, strlen(sql))

可是用户在使用时多加了个1,变成这样

mysq_real_query(mysql, sql, strlen(sql) + 1)

最终导致记录的 binlog 后面多了个 '\0'。 这个问题只在 statement 格式有,row 格式没有。


解决方法

有同学会问,+1 可以,+2、 +3 呢,这个是不可以的,>=2 的都是不行的,语句发过来后,mysqld 在 parse_sql 阶段直接报错返回了,后面就不会执行了。

1) 修改代码

mysq_real_query(mysql, sql, strlen(sql) + 1) 这种用法是不对的,但是 MySQL 却允许,虽然这么用是不对的,但是为了兼容性,最好还是允许这种使用方式,但是在写binlog的时候做个判断,长度是不是写错了,错了的话纠正过来,在 THD::binlog_query 里面改。


2) 5.6 版本加参数

如果是用 5.6 版本的 mysql client 的话,在重放时出错提示信息不一样,是类似下面这样的,更加友好,这个错误是 mysql client 报的,不是mysqld报的:

ERROR at line 24: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected....

5.6 版本的 mysql client 多了一个参数 --binary-mode,允许语句里有 '\0',所以如果是用5.6的话,就可以不用修改代码,重放binlog时这样做就可以了:

mysqlbinlog mysql-bin.000001 | mysql --binary-mode -hxxxx -Pxx -u


上一篇:阿里云ACK联合云效助力「上海博卡 」DevOps转型


下一篇:新零售效能机器人助力企业是怎样提效降本?