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代替
爲什麼主庫宕機會引起主從不一致？
事務的提交過程：
存儲引擎實現事務的通用方式是基於 redo log 和 undo log。
簡單來說，redo log 記錄事務修改後的數據, undo log 記錄事務前的原始數據。
所以當一個事務執行時實際發生過程簡化描述如下：
1.先記錄 undo/redo log，確保日誌刷到磁盤上持久存儲。
2.更新數據記錄，緩存操作並異步刷盤。
3.提交事務，在 redo log 中寫入 commit 記錄。
MySQL 執行事務過程中如果因故障中斷，可以通過 redo log 來重做事務或通過 undo log 來回滾，確保了數據的一致性。
這些都是由事務性存儲引擎來完成的（innodb_flush_log_at_tx_commit），
但 binlog 不在事務存儲引擎範圍內，而是由 MySQL Server 來記錄的（sync_binlog）。
那麼就必須保證 binlog 數據和 redo log 之間的一致性，所以開啓了 binlog 後實際的事務執行就多了一步，如下：
1.先記錄 undo/redo log，確保日誌刷到磁盤上持久存儲。
2.更新數據記錄，緩存操作並異步刷盤。
3.將事務日誌持久化到 binlog。
4.提交事務，在 redo log 中寫入commit記錄。
這樣的話，只要 binlog 沒寫成功，整個事務是需要回滾的，而 binlog 寫成功後即使 MySQL Crash 了都可以恢復事務並完成提交。
要做到這點，就需要把 binlog 和事務關聯起來，而只有保證了 binlog 和事務數據的一致性，才能保證主從數據的一致性。
所以 binlog 的寫入過程不得不嵌入到純粹的事務存儲引擎執行過程中，並以內部分佈式事務（xa 事務）的方式完成兩階段提交。
情況一：
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可以解決這種情況，但影響性能
如何幹淨清除slave同步信息??
reset slave 會刪除master.info和relay-log.info文件，但是不清除同步信息
reset slave all 可以清除所有同步信息。