MySQL 傳統複製與 GTID 複製原理及操作詳解

MySQL 複製在業界裡有叫：mysql 同步，ab 複製等。專業名稱就是叫：複製。

複製是單向的，只能從 master 複製到 slave 上，延時基本上是毫秒級別的。

一組複製結構中可以有多個 slave，對於 master 一般場景推薦只有一個。

master 使用者寫入資料，生成 event 記到 binary log 中 slave 接收 master 上傳來的 binlog，然後按順序應用，重現 master 上的使用者操作。

記錄最小的單位是一個 event，日誌前 4 個位元組是一個 magic number, 接下來 19 個位元組記錄 formatt desc event:FDE

MySQL 5.6 增加了 GTID 複製

1、classic 主從配置

核心配置

新增一個新的從庫，獲取主庫上一個帶 binlog 及 pos 偏移量的備份

在從庫上恢復後執行

啟動 slave，並檢視狀態

如果遇到錯誤，可以跳過：

2、複製配置

一個事務對應一個唯一 ID，一個 GTID 在一個伺服器上只會執行一次，GTID 是用來替代以前 classic 的複製方法，mysql 5.62 支援，mysql 5.6.10 後完善

優點：

相對於行復制來講資料安全性更高，故障切換更簡單

配置 GTID

GTID 新增從庫有兩種方法：

1、如果 master 所有的 binlog 還在，安裝 slave 後，直接 changemaster 到 master，原理是直接獲取 master 所有的 gtid 並執行，優點是簡單。缺點是如果 binlog 太多，資料完全同步需要的時間較長，並且需要 master 一開始就啟用了 GTID。

總結：適用於 master 也是新建不久的情況

2、通過 master 或者其它 slave 的備份搭建新的 slave，原理：獲取 master 的資料和這些資料對應的 GTID 範圍，然後通過在 slave 設定 @@GLOBAL.GTID_PURGED 從而跳過備份包含的 GTID，優點是可以避免第一種方法中的不足，缺點操作相對複雜。

總結：適用於擁有較大資料集的情況

GTID 新增從庫：

1、用 mysqldump 工具，在備份的時候需要指定 --master-data

匯出的語句中包括：set @@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497'; 恢復時，需要先在 slave 上執行一個 reset master，再執行 change master to

2、用 percona xtrabackup 工具

xtrabackup_binlog_info 包含了 GTID 在資訊

做從庫恢復後，需要手工設定：

恢復後，執行

錯誤跳過

GTID 的限制：

1、不支援非事務引擎（從庫報錯，stopslave; start slave; 忽略）

2、不支援 create table … select 語句複製（主庫直接報錯）

3、不允許在一個 SQL 同時更新一個事務引擎和非事務引擎的表

4、在一個複製組中，必須要求統一開啟 CTID 或是關閉 GTID

5、開啟 DTID 需要重啟（5.7 中可能不需要）

6、開啟 DTID 後，就不在使用原來的傳統的複製方式

7、對於 createtemporary table 和 drop temporary table 語句不支援

8、不支援 sql_slave_skip_counter

MySQL 複製預設是非同步複製，Master 將事件寫入 binlog，但並不知道 Slave 是否或何時已經接收且已處理。在非同步複製的機制的情況下，如果 Master 當機，事務在 Master 上已提交，但很可能這些事務沒有傳到任何的 Slave 上。假設有 Master->Salve 故障轉移的機制，此時 Slave 也可能會丟失事務。

官方半同步複製的概念：

1. 當 Slave 主機連線到 Master 時，能夠檢視其是否處於半同步複製的機制。

2. 當 Master 上開啟半同步複製的功能時，至少應該有一個 Slave 開啟其功能。此時，一個執行緒在 Master 上提交事務將受到阻塞，直到得知一個已開啟半同步複製功能的 Slave 已收到此事務的所有事件，或等待超時。

3. 當一個事務的事件都已寫入其 relay-log 中且已重新整理到磁碟上，Slave 才會告知已收到。

4. 如果等待超時，也就是 Master 沒被告知已收到，此時 Master 會自動轉換為非同步複製的機制。當至少一個半同步的 Slave 趕上了，Master 與其 Slave 自動轉換為半同步複製的機制。

5. 半同步複製的功能要在 Master，Slave 都開啟，半同步複製才會起作用；否則，只開啟一邊，它依然為非同步複製。

同步（社群增強半同步），非同步，半同步複製的比較：

同步複製：Master 提交事務，直到事務在所有的 Slave 都已提交，此時才會返回客戶端，事務執行完畢。缺點：完成一個事務可能會有很大的延遲。

非同步複製：當 Slave 準備好才會向 Master 請求 binlog。缺點：不能保證一些事件都能夠被所有的 Slave 所接收。

半同步複製：半同步複製工作的機制處於同步和非同步之間，Master 的事務提交阻塞，只要一個 Slave 已收到該事務的事件且已記錄。它不會等待所有的 Slave 都告知已收到，且它只是接收，並不用等其完全執行且提交。

半同步，開啟後嚴重影響效能

解決主庫不關心日誌是否被從庫讀到半同步配置，在 master 和 slave 上都配置：

複製引數

>>>>閱讀全文