共計 1666 個字符，預計需要花費 5 分鐘才能閱讀完成。

本篇內容主要講解“mysql 出現主從同步不一致的情況分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“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。

到此，相信大家對“mysql 出現主從同步不一致的情況分析”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！