MySQL binlog的地雷

6月 6th, 2010 | Posted by | Filed under 未分类

本文内容遵从CC版权协议, 可以随意转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.penglixun.com/database/mysql_binlog_risk.html

上周在研究MySQL binlog格式的时候,发现了一些MySQL binlog的风险点,记录一下。

5.1版本后,MySQL引入了基于ROW方式的binlog格式,不同于Statement方式的是,ROW方式记录了变更的内容,而不仅仅是SQL
通过mysqlbinlog工具可以解析查看,mysqlbinlog mysql-bin.000001就可以查看解出后的格式,Statement方式记录的SQL被还原,但是Row方式记录的内容,还是BASE64的结构。
mysqlbinlog -vv mysql-bin.000001就可以将Row方式记录的内容也解开来,可以看到类似这样的内容:
### UPDATE test.a
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=’abc’ /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=’cba’ /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
我们可以发现,binlog中并没有记录列名,只记录了顺序,这样会有什么风险呢?
单机的时候问题不大,但是在双Master的结构下,这问题可就大了,假设Master A <--> Master B正在相互复制,我在Master B做一个DDL改变了字段顺序,那么从B DDL完成开始,到A接受执行完这个DDL为止,之间A产生的这张表的数据复制到B都是错误的!因为MySQL只按字段顺序应用binlog。

如何避免这个问题呢?有两个办法,最保险的只加字段不删字段,加字段总是在表末尾,一句话:不改变字段的顺序。另一个办法就是改变字段顺序的DDL只在提供服务的主机上执行,如果双Master都提供服务,这就不行了,只能在末尾添加字段。

这只是地雷之一,还有第二个地雷。mysqlbinlog这个工具的作者真的比较懒,-d参数过滤数据库的时候,只有Statement方式记录的SQL能被过滤,所有按Row方式记录的SQL都没有被过滤!也就是说,假设你的数据库是基于Row方式记录binlog的,你想通过mysqlbinlog -d db1来过滤出db1的SQL,这是不靠谱的,所有Row方式记录的SQL全部被解出来了,你要是到数据库去应用这些解出来的SQL,你就准备悲剧了,各种Duplicate Key!

还有一个不算地雷但是值得说一下的是,即使不需要使用-d参数,你需要全部binlog都解出来,到数据库去应用,也会有一个悲剧点,Row方式记录的SQL都是Base64格式,解出来还是一样,传到数据库去执行的话,MySQL还会把这些BASE64的字串解成SQL,再去应用,所以数据库Load可能会增长的很高。

  1. chan
    9月 19th, 201218:16

    您好,
    请问这些问题现在有没有好的方法解决呀。假如要恢复这些数据,那加了注释那些该怎么处理呢,谢谢。

    [回复]