MySQL複製

MySQL非同步複製架構中傳統複製的原理闡述

MySQL傳統複製是基於MySQL二進位制檔案（mysql-bin.000001），加上對應日誌檔案中每個事件的偏移量位置點（postion）。

• 三個執行緒來實現：主庫Binlog Dump，從庫IO和SQL執行緒
• Master所有資料庫變更寫進Binary log, 主庫執行緒 binlog dump把Binary log內容傳送到從庫slave上（slave被動接受資料，不是主動去獲取）。
• Slave IO執行緒讀取Master上Binary log日誌資訊，把接受到的Binary log日誌寫到本地中繼日誌 Relay log
• Slave SQL執行緒讀取Ralay log日誌內容寫入本地資料庫例項

MySQL非同步複製架構中GTID複製的原理闡述

一、GTID的概述：

• 1、全域性事物標識：global transaction identifieds。
• 2、GTID事物是全域性唯一性的，且一個事務對應一個GTID。
• 3、一個GTID在一個伺服器上只執行一次，避免重複執行導致資料混亂或者主從不一致。
• 4、GTID用來代替classic的複製方法，不在使用binlog+pos開啟複製。而是使用master_auto_postion=1的方式自動匹配GTID斷點進行復制。
• 5、MySQL-5.6.5開始支援的，MySQL-5.6.10後開始完善。
• 6、在傳統的slave端，binlog是不用開啟的，但是在GTID中，slave端的binlog是必須開啟的，目的是記錄執行過的GTID（強制）；但是從5.7.5版本開始無需在GTID模式下啟用引數log_slave_updates

二、GTID的組成部分：

GTID = source_id:transaction_id 
source_id正常即是server_uuid，在第一次啟動時生成（函式generate_server_uuid），並持久化到DATADIR/auto.cnf檔案裡。 
transaction_id是順序化的序列號（sequence number），在每臺MySQL伺服器上都是從1開始自增長的序列，是事務的唯一標識。例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:23 
GTID 的集合（GTIDs）可以用source_id+transaction_id範圍表示，例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:1-18 
複雜一點的：如果這組 GTIDs 來自不同的 source_id，各組 source_id 之間用逗號分隔；如果事務序號有多個範圍區間，各組範圍之間用冒號分隔，例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5:11-18,2C256447-3F0D-431B-9A12-575BB20C1507:1-27

三、GTID如何產生

GTID的生成受gtid_next控制。 
在Master上，gtid_next是預設的AUTOMATIC,即GTID在每次事務提交時自動生成。它從當前已執行的GTID集合（即gtid_executed）中，找一個大於0的未使用的最小值作為下個事務GTID。同時將GTID寫入到binlog（set gtid_next記錄），在實際的更新事務記錄之前。 
在Slave上，從binlog先讀取到主庫的GTID(即set gtid_next記錄)，而後執行的事務採用該GTID。

四、GTID相關的變數

• GTID_EXECUTED 
  表示已經在該例項上執行過的事務； 執行RESET MASTER 會將該變數置空; 我們還可以通過設定GTID_NEXT在執行一個空事務，來影響GTID_EXECUTED
• GTID_PURGED 
  已經被刪除了binlog的事務，它是GTID_EXECUTED的子集，只有在GTID_EXECUTED為空時才能設定該變數，修改GTID_PURGED會同時更新GTID_EXECUTED和GTID_PURGED的值。
• GTID_OWNED 
  表示正在執行的事務的gtid以及對應的執行緒ID。
• GTID_NEXT 
  SESSION級別變數，表示下一個將被使用的GTID。

五、GTID比傳統複製的優勢與限制：

優勢

• 1、更簡單的實現failover，不用以前那樣在需要找log_file和log_Pos。
• 2、更簡單的搭建主從複製。
• 3、複製叢集有一個統一的方式識別複製位置，給叢集管理帶來了便利。
• 4、正常情況下，GTID是連續沒有空洞的，因此主從庫出現數據衝突時，可以用新增空事物的方式進行跳過。

GTID的限制

• 1、在一個事務裡面混合使用引擎如Innodb(支援事務)、MyISAM（不支援事務）， 造成多個GTIDs和同一個事務相關聯出錯
• 2、CREATE TABLE…..SELECT 不能使用，該語句產生的兩個event在某一情況 會使用同一個GTID（同一個GTID在slave只能被使用一次）
  • 1th event:建立表語句create table
  • 2th event:插入資料語句insert
• 3、CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE 不能在事務內使用 （啟用了--enforce-gtid-consistency引數)。

六、GTID的工作原理：

• 1、master更新資料時，會在事務前產生GTID，一同記錄到binlog日誌中。
• 2、slave端的i/o 執行緒將變更的binlog，寫入到本地的relay log中。
• 3、sql執行緒從relay log中獲取GTID，然後對比slave端的binlog是否有記錄。
• 4、如果有記錄，說明該GTID的事務已經執行，slave會忽略。
• 5、如果沒有記錄，slave就會從relay log中執行該GTID的事務，並記錄到binlog。
• 6、在解析過程中會判斷是否有主鍵，如果沒有就用二級索引，如果沒有就用全部掃描。