主從不同步的情況

1.網路延遲

由於mysql主從複製是基於binlog的一種非同步複製，通過網路傳送binlog檔案，理所當然網路延遲是主從不同步的絕大多數的原因，特別是跨機房的資料同步出現這種機率非常的大，所以做讀寫分離，注意從業務層進行前期設計。

2.主從兩臺機器的負載不一致，由於mysql主從複製是主資料庫上面啟動1個io執行緒，而從上面啟動1個sql執行緒和1個io執行緒，當中任何一臺機器的負載很高，忙不過來，導致其中的任何一個執行緒出現資源不足，都將出現主從不一致的情況。

3.max_allowed_packet設定不一致，主資料庫上面設定的max_allowed_packet比從資料庫大，當一個大的sql語句，能在主資料庫上面執行完畢，從資料庫上面設定過小，無法執行，導致的主從不一致。

4.自增鍵不一致，key自增鍵開始的鍵值跟自增步長設定不一致引起的主從不一致。

5.同步引數設定問題，mysql異常宕機情況下，如果未設定sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出現binlog或者relaylog檔案出現損壞，導致主從不一致。

6.主庫binlog格式未Statement，同步到從庫執行後可能造成主從不一致。

7.主庫執行更改前有執行set sql_log_bin=0，會使主庫不記錄binlog，從庫也無法變更這部分資料。

8.從節點未設定只讀，誤操作寫入資料。

9.主庫或從庫意外宕機，宕機可能會造成binlog或者relaylog檔案出現損壞，導致主從不一致

10.主從例項版本不一致，特別是高版本是主，低版本是從的情況下，主資料庫上面支援的功能從資料庫上面可能不支援

11.MYSQL自身bug導致

主從不一致檢視

主庫上檢視是否有太多sleep執行緒，發現執行緒正常

mysql> show processlist;
+----+----------+------------------+------+------------------+------+-----------------------------------------------------------------------+------------------+
| Id | User     | Host             | db   | Command          | Time | State                                                                 | Info             |
+----+----------+------------------+------+------------------+------+-----------------------------------------------------------------------+------------------+
|  1
 
 | repluser | 10.0.0.216:48640 | NULL | Binlog Dump GTID | 3595 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             |
|  3 | root     | localhost        | NULL | Query            |    0 | init                                                                  | show processlist |
+----+----------+------------------+------+------------------+------+-----------------------------------------------------------------------+------------------+
2 rows in set (0.00 sec)

檢視主庫，狀態也正常

mysql> show master logs;
+----------------------+-----------+
| Log_name             | File_size |
+----------------------+-----------+
| localhost-bin.000001 |      9839 |
+----------------------+-----------+
1 row in set (0.00 sec)

由此可見是從庫的問題

從庫解決方法1：重新實現從庫

主庫資料量較大的話，這個方法恢復時間比較慢，而且有時候從庫也承擔一部分的查詢操作，不能貿然重建。

從庫解決方法2：使用percona-toolkit工具輔助

參考如下連結：https://www.cnblogs.com/feiren/p/7777218.html

從庫解決方法3：手動重建不一致的表

在從庫發現某幾張與主庫資料不一致，而這幾張表資料量也比較大，手工對比資料不現實，重做整個庫也比較慢，這個時候可以只重做這幾張表來修復主從不一致

這個方案缺點是在執行匯入期間需要暫時停止從庫複製

實現思路：

假設A,B,C這三張表主從資料不一致

1.停止從庫複製

2.在主庫上dump這三張表，並且記錄下同步的binlog和POS點

3.檢視A_B_C.sql檔案，找出記錄的binlog和POS點

4.把A_B_C.sql拷貝到slave機器上，並做指定複製到的位置