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可以解决这种情况，但影响性能
转载于:https://www.cnblogs.com/youhunyimeng/p/6407544.html
