症状：1、主从延迟Seconds_Behind_Master: 83676
2、主从表双据不一致（从库表总行数>主库表总行数）
3、从库卡Relay_Log_Pos点不动
分析：1、利用mysqlbinlog查看binlog的sql语句，查看dump出的文件pos点的sql语句是十六进制的。
2、核对主从的数据，从库莫名多了好多条数据，而且某个表的字段为null，但是主的表字段没有为null的
总结
该问题主要的原因在于MySQL的两种不同的Item在处理字符串转整型的方法不一致，Item_param通过类似于atoi的形式，直接把字符中的数字通过-'0'转换到整型，而Item_hex_string则通过强制内存转化所得，这两种方式都合理，但是两边没有统一，造成replication出错，MySQL从5.1版本后到目前MySQL5.5的版本中都存在该问题(MySQL5.6没有测试过，应该也存在该问题)。解决方法：
1、服务端使用utf8字符集编码(由于前面时gbk,改成utf8会出现乱码等很多问题)
2、更改应用不对int字段进行非int数据的插入
3、更改应用不使用prepare statement
4、binlog的format设置成row格式
参考：http://backend.blog.163.com/blog/static/20229412620133274030845/
http://www.linuxidc.com/Linux/2011-08/41439.htm
2、主从表双据不一致（从库表总行数>主库表总行数）
3、从库卡Relay_Log_Pos点不动
分析：1、利用mysqlbinlog查看binlog的sql语句，查看dump出的文件pos点的sql语句是十六进制的。
2、核对主从的数据，从库莫名多了好多条数据，而且某个表的字段为null，但是主的表字段没有为null的
总结
该问题主要的原因在于MySQL的两种不同的Item在处理字符串转整型的方法不一致，Item_param通过类似于atoi的形式，直接把字符中的数字通过-'0'转换到整型，而Item_hex_string则通过强制内存转化所得，这两种方式都合理，但是两边没有统一，造成replication出错，MySQL从5.1版本后到目前MySQL5.5的版本中都存在该问题(MySQL5.6没有测试过，应该也存在该问题)。解决方法：
1、服务端使用utf8字符集编码(由于前面时gbk,改成utf8会出现乱码等很多问题)
2、更改应用不对int字段进行非int数据的插入
3、更改应用不使用prepare statement
4、binlog的format设置成row格式
参考：http://backend.blog.163.com/blog/static/20229412620133274030845/
http://www.linuxidc.com/Linux/2011-08/41439.htm
一次DRBD脑裂行为的模
MySQLMTOP开源的
