為什麼mysql會經常出現主從同步不一致的情況

1. MySQL資料庫主從同步延遲原理。

答：談到MySQL資料庫主從同步延遲原理，得從mysql的資料庫主從複製原理說起，mysql的主從複製都是單執行緒的操作，主庫對所有DDL和 DML產生binlog，binlog是順序寫，所以效率很高，slave的Slave_IO_Running執行緒到主庫取日誌，效率很比較高，下一步， 問題來了，slave的Slave_SQL_Running執行緒將主庫的DDL和DML操作在slave實施。DML和DDL的IO操作是隨即的，不是順 序的，成本高很多，還可能可slave上的其他查詢產生lock爭用，由於Slave_SQL_Running也是單執行緒的，所以一個DDL卡主了，需要 執行10分鐘，那麼所有之後的DDL會等待這個DDL執行完才會繼續執行，這就導致了延時。有朋友會問：“主庫上那個相同的DDL也需要執行10分，為什 麼slave會延時？”，答案是master可以併發，Slave_SQL_Running執行緒卻不可以。

2. MySQL資料庫主從同步延遲是怎麼產生的。

答：當主庫的TPS併發較高時，產生的DDL數量超過slave一個sql執行緒所能承受的範圍，那麼延時就產生了，當然還有就是可能與slave的大型query語句產生了鎖等待。

3. MySQL資料庫主從同步延遲解決方案

答：最簡單的減少slave同步延時的方案就是在架構上做最佳化，儘量讓主庫的DDL快速執行。還有就是主庫是寫，對資料安全性較高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設定，而slave則不需要這麼高的資料安全，完全可以講sync_binlog設定為0或者關閉binlog，innodb_flushlog也 可以設定為0來提高sql的執行效率。另外就是使用比主庫更好的硬體裝置作為slave。

mysql-5.6.3已經支援了多執行緒的主從複製。

GTID的概念

     普通的複製過程中，從庫透過記錄主庫的binlog檔名和偏移量來記錄和接收主庫binlog的事件工作進展。下次開始複製的時候告知主庫這些資訊，讓主庫可以從正確的位置開始傳送binlog的事件給從庫。但基於GTID的複製就不再需要告知這些事情，在執行  CHANGE  MASTER  TO 命令，也不需要指定MASTER_LOG_FILE 和 MASTER_LOG_POS引數。只需要指定MASTER_AUTO_POSTION = 1 就可以了，主庫會根據從庫傳送過來的一個GTID集合資訊來決定從哪裡開始傳送binlog事件。大大簡化了資料庫管理員在複製中的工作。

    GTID是在資料庫提交事務時建立的唯一的標示符。該標示符與事務是一一相關的。

    GTID有兩部分組成，如下所示：

    GTID = source_id：transaction_id 

    source_id 用於標識這個事務是在哪個資料庫例項上執行的。用的是uuid作為source_id 。

    transaction_id 是一個序列號，取決於該事務在資料庫上的提交順序。該序列號初始為1.

在MySQL5.6以前的版本，同步複製都是單執行緒的，只能一個一個執行。在5.6做到了多個庫多執行緒複製。

但是需要注意的是。一個庫只能由一個執行緒去複製。也就是說若複製的庫只有1個，那麼執行緒也只有一個。複製的庫有2個。那麼執行緒可以增加到兩個。

GTID的作用，具體歸納下來有以下兩點：

   1.根據GTID來確認事務最初的是在哪個例項上提交的

   2.GTID的存在方便了Replication和failover。