mysql proxy master宕机_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 130407973bytes--从这个日志上看，当时主机启动后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也没有达到！

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