mysql 主从错误情况与原因

mysql 主从错误情况
1，master 上删除一条记录是从库报错 找不到该记录
引起原因：master出现宕机或者从库已经删除。
解决方案：stop slave;set global sql_slave_skip_counter=1;start slave;
2，主键冲突
引起原因：master宕机或者从库宕机
解决方案：删除此主键，重新start slave;
3，update 时候slave上找不到次数据
引起原因：master宕机或者从库做了删除操作
解决方案：master上扎到次数据插入到从库
4，slave 中继日志损坏
引起原因：slave 宕机
解决方案：找到同步的位置，重置从库复制点
5，slave上同步位置大于主库现在位置
引起原因：主库宕机
解决方案：直接重置从库复制点到新的binlog里的新节点
6，binlog_ignore_db引起同步复制故障
解决方案：replicate_ignore_db代替

为什么主库宕机会引起主从不一致？
情况一：
mysql事务提交先刷新到binlog，然后刷新到redo log。当刷新到binlog后宕机，mysql下次启动时，由于redo log里没有该事务记录就回滚，
但二进制日志已经记录该事务信息，不会回滚，所以slave会和主库不一样。
XA事务可以保证 innodb redo log 和binlog一致性。innodb_support_xa=1解决此种情况，但影响性能

情况二：
当sync_binlog=0的情况，很容易出现主从异常
sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘
等待系统决定什么时候刷新，或者cache满了之后同步到磁盘
sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
当 sync_binlog=0的时候，一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失，即master binlog 文件的 flush log buffer 中的数据未刷新到磁盘。
但Slave IO 线程在读取master dump 线程的位置，一般是直接读取log buffer的,这个位置，可能远远大于binlog文件实际大小。
也就是当master出现宕机的时候，slave IO线程也许已经把master binlog buffer中的数据已经读到slave中继日志并在slave上执行，导致主库和从库出现不一样现象。
sync_binlog=1可以解决这种情况，但影响性能