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

這篇文章將為大家詳細講解有關 MySQL 中怎樣實現主從同步，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

(1) statement：記錄每一條更改數據的 sql;

優點：binlog 文件較小，節約 I /O，性能較高。

缺點：不是所有的數據更改都會寫入 binlog 文件中，尤其是使用 MySQL 中的一些特殊函數 (如 LOAD_FILE()、UUID() 等)和一些不確定的語句操作，從而導致主從數據無法復制的問題。

(2) row：不記錄 sql，只記錄每行數據的更改細節

優點：詳細的記錄了每一行數據的更改細節，這也意味著不會由于使用一些特殊函數或其他情況導致不能復制的問題。

缺點：由于 row 格式記錄了每一行數據的更改細節，會產生大量的 binlog 日志內容，性能不佳，并且會增大主從同步延遲出現的幾率。

(3)  mixed：一般的語句修改使用 statment 格式保存 binlog，如一些函數，statement 無法完成主從復制的操作，則采用 row 格式保存 binlog，MySQL 會根據執行的每一條具體的 sql 語句來區分對待記錄的日志形式，也就是在 Statement 和 Row 之間選擇一種。

(二)binlog 日志內容

mysqlbinlog 命令查看的內容如下：

根據事件類型查看的 binlog 內容：

(三)binlog 事件類型

MySQL  binlog 記錄的所有操作實際上都有對應的事件類型的，譬如 STATEMENT 格式中的 DML 操作對應的是 QUERY_EVENT 類型，ROW 格式下的 DML 操作對應的是 ROWS_EVENT 類型，如果想了解更多請參考官方文檔，有關 binlog 日志內容不在這里過多贅述，簡單介紹一下是為了更好的理解主從復制的細節，下面我們進入正題。

四、MySQL 主從復制原理

mysql 主從復制需要三個線程，master(binlog dump thread)、slave(I/O thread、SQL thread)。

master

(1)binlog  dump 線程：當主庫中有數據更新時，那么主庫就會根據按照設置的 binlog 格式，將此次更新的事件類型寫入到主庫的 binlog 文件中，此時主庫會創建 log  dump 線程通知 slave 有數據更新，當 I / O 線程請求日志內容時，會將此時的 binlog 名稱和當前更新的位置同時傳給 slave 的 I / O 線程。

slave

(2)I/ O 線程：該線程會連接到 master，向 log dump 線程請求一份指定 binlog 文件位置的副本，并將請求回來的 binlog 存到本地的 relay  log 中，relay log 和 binlog 日志一樣也是記錄了數據更新的事件，它也是按照遞增后綴名的方式，產生多個 relay log( host_name-relay-bin.000001)文件，slave 會使用一個 index 文件 ( host_name-relay-bin.index) 來追蹤當前正在使用的 relay log 文件。

(3)SQL 線程：該線程檢測到 relay  log 有更新后，會讀取并在本地做 redo 操作，將發生在主庫的事件在本地重新執行一遍，來保證主從數據同步。此外，如果一個 relay  log 文件中的全部事件都執行完畢，那么 SQL 線程會自動將該 relay log 文件刪除掉。

下面是整個復制過程的原理圖：

四、主從同步延遲

mysql 的主從復制都是單線程的操作，主庫對所有 DDL 和 DML 產生 binlog，binlog 是順序寫，所以效率很高，slave 的 I / O 線程到主庫取日志，效率也比較高，但是，slave 的 SQL 線程將主庫的 DDL 和 DML 操作在 slave 實施。DML 和 DDL 的 IO 操作是隨即的，不是順序的，成本高很多，還可能存在 slave 上的其他查詢產生 lock 爭用的情況，由于 SQL 也是單線程的，所以一個 DDL 卡住了，需要執行很長一段事件，后續的 DDL 線程會等待這個 DDL 執行完畢之后才執行，這就導致了延時。當主庫的 TPS 并發較高時，產生的 DDL 數量超過 slave 一個 sql 線程所能承受的范圍，延時就產生了，除此之外，還有可能與 slave 的大型 query 語句產生了鎖等待導致。

由于主從同步延遲是客觀存在的，我們只能從我們自己的架構上進行設計，盡量讓主庫的 DDL 快速執行。下面列出幾種常見的解決方案：

業務的持久化層的實現采用分庫架構，mysql 服務可平行擴展，分散壓力。

服務的基礎架構在業務和 mysql 之間加入 memcache 或者 Redis 的 cache 層。降低 mysql 的讀壓力;

使用比主庫更好的硬件設備作為 slave;

sync_binlog 在 slave 端設置為 0;

ndash;logs-slave-updates 從服務器從主服務器接收到的更新不記入它的二進制日志。

禁用 slave 的 binlog

關于 MySQL 中怎樣實現主從同步就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。