MYSQL5.1--MySQL binlog 地雷

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

5.1版本后，MySQL引入了基于ROW方式的binlog格式，不同于Statement方式的是，ROW方式记录了变更的内容，而不仅仅是SQL。
通过mysqlbinlog工具可以解析查看，mysqlbinlog mysql-bin.000001就可以查看解出后的格式，Statement方式记录的SQL被还原，但是Row方式记录的内容，还是BASE64的结构。

如何避免这个问题呢？有两个办法，最保险的只加字段不删字段，加字段总是在表末尾，一句话：不改变字段的顺序。另一个办法就是改变字段顺序的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可能会增长的很高。