一、導致主從不一致的原因主要有：
-
人為原因導致從庫與主庫數據不一致（從庫寫入）
-
主從復制過程中，主庫異常宕機
-
設置了ignore/do/rewrite等replication等規則
-
binlog非row格式
-
異步復制本身不保證，半同步存在提交讀的問題，增強半同步起來比較完美。 但對於異常重啟（Replication Crash Safe），從庫寫數據（GTID）的防范，還需要策略來保證。
-
從庫中斷很久，binlog應用不連續，監控並及時修復主從
-
從庫啟用了諸如存儲過程，從庫禁用存儲過程等
-
數據庫大小版本/分支版本導致數據不一致？，主從版本統一
-
備份的時候沒有指定參數 例如mysqldump --master-data=2 等
-
主從sql_mode 不一致
-
一主二從環境，二從的server id一致
-
MySQL自增列 主從不一致
-
主從信息保存在文件里面，文件本身的刷新是非事務的，導致從庫重啟后開始執行點大於實際執行點
-
采用5.6的after_commit方式半同步，主庫當機可能會引起主從不一致，要看binlog是否傳到了從庫
-
啟用增強半同步了（5.7的after_sync方式），但是從庫延遲超時自動切換成異步復制
二、預防和解決的方案有:
1、
master:
innodb_flush_log_at_trx_commit=1
sync_binlog=1
2、
slave:
master_info_repository="TABLE"
relay_log_info_repository="TABLE"
relay_log_recovery=1
3、設置從庫為只讀模式
4、可以使用5.7增強半同步避免數據丟失等
5、binlog row格式
6、必須引定期的數據校驗機制
7、當使用延遲復制的時候，此時主從數據也是不一致的（計划內），但在切換中，不要把延遲從提升為主庫哦~
8、mha在主從切換的過程中，因主庫系統宕機，可能造成主從不一致（mha本身機制導致這個問題）