mysql replication之GTID

 原理

5.6引入，在整個複製拓撲結構內，每個事務擁有自己全域性唯一標識，,每個GTID對應一個事務;。

GTID包含兩個部分，一部分是例項的UUID，另一部分是例項內遞增的整數，GTID = server_uuid:transaction_id,。

注：第一次啟動mysql會生成server_uuid並存於資料目錄的auto.cnf；

一旦GTID對應的事務被執行,會加入當前例項的gtid_executed集合,後續相同GTID的事務則直接被忽略;

流程

1 主庫執行事務，分配GTID並記入binlog；

2 slave解析binlog，將GTID賦給gtid_next並於下一個事務使用此GTID，gtid_next位於session context；

3 slave使用GTID前先做檢查，確保其既沒有被使用過(gtid_executed)， 也沒有被其他session正在使用(gtid_owned)，多個客戶端不可併發執行同一個事務；

配置引數

主備都要宣告 gtid-mode = ON & enforce-gtid-consistency = ON；

Gtid_executed：例項已執行的所有GTID集合；伺服器啟動時，讀取最新的binlog，賦予union(previous_gtids_log_event, gtid_log_event)；

Gtid_purged：已清除的binlog中包含的GTID集合；伺服器啟動時，讀取最舊binlog的previous_gtid_log_event並將其賦值；每purge一個binlog，則重置一次；reset master會將其重置為空；

注：任意時刻，例項當前binlog中可以找到的事務範圍為GTID_SUBTRACT(@@global.gtid_executed, @@global.gtid_purged)；

Gtid_owned：只讀變數，分別描述session和global當前擁有的gtid集合；

Gtid_next：

指定下一個GTID獲取的方式，有3種選項

1 automatic，使用下一個自動產生的GTID；

2 anonymous，不使用GTID；

3 GTID(格式為UUID:NUMBER)，即下一個事務採用此GTID；

轉化replication

對已有的replication，將其轉化為GTID模式；

1 將主備都設定為read-only，並確保slave與master同步；

2 master和slave，開啟GTID，binlog和log-slave-updates(備庫)；

3 將slave以auto-positioning方式連線到master；

4 去除master和slave的read-only限制；

具體步驟

1

主備均執行SET @@global.read_only = ON;

2

重啟master

mysqld_safe --gtid_mode=ON --log-bin --log-slave-updates --enforce-gtid-consistency &

重啟slave，禁止啟動IO和SQL thread

mysqld_safe --gtid_mode=ON --log-bin --log-slave-updates  --skip-slave-start --enforce-gtid-consistency &

注: --gtid_mode為列舉而非布林型別，故只能宣告on或者off,賦值0或1會出現問題；--enforce-gtid-consistency則是禁止gtid unsafe語句執行;

3 slave指向master

mysql> CHANGE MASTER TO

     >     MASTER_HOST = host,

     >     MASTER_PORT = port,

     >     MASTER_USER = user,

     >     MASTER_PASSWORD = password,

     >     MASTER_AUTO_POSITION = 1;

注：若要使用file+position模式,須將MASTER_AUTO_POSITION = 0

開啟slave IO和SQL執行緒,

mysql> START SLAVE;

4 去除master和slave的read-only限制

SET @@global.read_only = OFF;

除此之外還有其他方法http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-failover.html

限制

GTID依附於事務，

1 更新非事務引擎

非事務引擎單條DML被視為一個事務，倘若在一個事務中和innodb混合使用，可能導致單條事務生成多個GTID；

2 create table … select

若採用row-based，該sql常常被分解成兩個獨立事件：a 建立表；b 插入資料；

事務可能會為這兩個事件分配同一個GTID，導致slave把後面的insert忽略；

3 臨時表

手工建立的臨時表應該獨立於任何事務之外(autocommit = 1)；

4 不支援sql_slave_skip_counter

slave若要跳過事務，需設定gtid_executed或gtid_next；

5 mysql_upgrade

其會更新系統表(MyISAM)，因此使用時須設定—gtid-mode=off，或者—write-binlog=off(5.6.7預設開啟)；

GTID的開銷

1  previous_gtid_log_event

位於binlog開頭，記錄此binlog之前的GTID列表(對應@@gtid_purged )，外加40位元組 * number_of_masters；

2  Gtid_log_event

44位元組，位於每個事務之前；

https://blogs.oracle.com/MySQL/entry/deep_dive_into_gtids_and