MySQL master 宕机导致slave数据库比master多的case

先说环境吧：

Server version:         5.6.16-enterprise-commercial-advanced-log MySQL Enterprise Server - Advanced Edition (Commercial)

mysql> show variables like ‘%innodb_flush_log_at_trx_commit%‘;
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 2     |
+--------------------------------+-------+
1 row in set (0.00 sec)

mysql> show variables like ‘%sync_binlog%‘;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 0     |
+---------------+-------+

-- Master上的error log:

2015-03-21 08:07:24 17646 [Note] Crashed binlog file /paic/mylog/3308/mysql-bin.002977 size is 130408448, but recovered up to 130407973. Binlog trimmed to 130407973 bytes

-- 从这个日志上看，当时主机启动后binary log从130408448 回滚到了130407973.

-- Slave上的error log:

2015-03-21 04:41:21 22181 [Note] Slave I/O thread exiting, read up to log ‘mysql-bin.002977‘, position 130484169

-- Slave上读到的binlog为130484169这个pos.

-- 这样的话slave会比master上多一点数据

可以看出slave上读取到的binlog pos(130484169)比master binlog recovery 后的pos（130407973）要大，甚至比recovery前的binlog（130408448）也要大！

slave收到了binlog并不会回滚，并在slave sql thread执行写入 导致slave数据比master要新！！！ 

同时可以看出master的 Binlog Dump 线程推送binlog内容时，没有刷盘已经推给slave了。可见MySQL 的replication 在数据一致性方面确实难以实现。

根据CAP理论： 主从同步能达到A、P 但是C无法满足，其实严格意义上来讲A也没有达到！

MySQL master 宕机导致slave数据库比master多的case

原文：http://www.cnblogs.com/xingye001/p/4377317.html