mariadb10 GTID 研究筆記.md

Mysql 5.6的GTID沒有深刻研究，初步看了下，mariadb10的GTID複製使用起來，相比5.6的要簡單，傳統模式複製改GTID複製，只須要CHANGE MASTER master_use_gtid=current_pos 就能夠了。

本文是在mariadb 10關於GTID複製的官方文檔 https://mariadb.com/kb/en/mariadb/mariadb-documentation/replication-cluster-multi-master/replication/global-transaction-id/

寫的筆記和知識點，有些理解可能不徹底正確，建議看官方文檔。

Markdown 格式寫的，新手，排版比較醜：）

From version 10.0.2, MariaDB supports global transaction IDs for replication.

Benefits

1. Easy to change a slave server to connect to and replicate from a different master server.
2. The state of the slave is recorded in a crash-safe way.

缺點

1. mariadb 10的GTID實現和mysql 5.6的不同，目前二者不兼容，也就是說mysql 5.6 master 啓用GTID後，mysql 5.6的binlog event沒法複製到mariadb，目前無解，官方解釋以下。Mysql 5.6之後，非官方的mysql版本（percona和mariadb）和官方mysql版本差別愈來愈大，選擇mysql版本，就要慎重了。。。

實現：

• GTID位置信息存放在mysql.gtid_slave_pos表，在更新數據的同一事務中更新此表的最新位置信息。老版的複製，使用relay-log.info文件，和實際的數據更新是非依賴關係，crash時容易出問題。
• 使用GTID，不須要特別的設置，只須要slave change master使用新的語法，默認是舊的複製機制。

GTID組成

0-1-10

• The first number 0 is the domain ID, which is specific for global transaction ID (more on this below). It is a 32-bit unsigned integer.

  因爲Mariadb 特有的多源複製，須要特別的加domain ID，經過domain id來區分多個源。單master的環境下， domain id能夠忽略，以默認值0來表示。

• The second number is the server ID, the same as is also used in old-style replication. It is a 32-bit unsigned integer.

• The third number is the sequence number. This is a 64-bit unsigned integer that is monotonically increasing for each new event group logged into the binlog

使用GTID

• From MariaDB 10.0.2, global transaction ID is enabled automatically. 默認自動啓用GTID。

• SHOW BINLOG EVENTS的結果以下：

  +------------------+------+-------------------+-----------+-------------+------------------------------------------------+

  | Log_name | Pos | Event_type | Server_id | End_log_pos | Info |

  +------------------+------+-------------------+----------->>> +-------------+------------------------------------------------+

  | mysql-bin.000041 | 4 | Format_desc | 862413307 | 248 | Server ver: 10.0.10-MariaDB-log, Binlog ver: 4 |

  | mysql-bin.000041 | 248 | Gtid_list | 862413307 | 287 | [0-862413307-5445551]

  能夠看出新增長的binlog evnet "Gtid_list" = 0-862413307-5445551 ，862413307 是server id

• 查看從庫的當前GTID 值，使用命令 SELECT @@GLOBAL.gtid_slave_pos,主庫上返回空值。

• 即便使用舊的複製方式，slave上的gtid_slave_pos，也是一直記錄着。但若主庫是5.5，則slave上的gtid_slave_pos則是空值，由於主庫的5.5.*版本尚未gtid模式。

• 查看master的當前gtid值，使用命令 select @@global.gtid_current_pos;

  +---------------------------+

  | @@global.gtid_current_pos |

  +---------------------------+

  | 0-862413307-7175755 |

  +---------------------------+

• 從庫採用gtid的複製，語法爲：CHANGE MASTER TO master_use_gtid = { slave_pos | current_pos | no }

• 通常使用slave_pos，當A->B，A掛掉，B當master，而後A好了，想要作B的slave狀況下，使用current_pos,由於B之前是主庫，沒有slave_pos這個值

• GTID的限制：slave的本地寫入，須要注意，由於跟master不是同一個GTID範圍，寫入binlog的值，複製到後續從庫，容易fail，須要使用set sql_log_bin=0，來禁止binlog的寫入。

  When GTID strict mode is enabled (by setting @@GLOBAL.gtid_strict_mode to 1), it is normally best to use current_pos. In strict mode, extra transactions on the master are disallowed.

  If a slave is configured with the binlog disabled, current_pos and slave_pos are equivalent.

• 位置信息存儲在 mysql.gtid_slave_pos 表

  In order to be crash-safe, this table must use a transactional storage engine such as InnoDB

  After upgrading a server to 10.0, it is necessary to run mysql_upgrade (as always) to get the table created.

• 老版本升級到10.0系列，必須用mysql_upgrade命令來生成此表。不要直接修改此表，而應該使用命令 SET GLOBAL gtid_slave_pos = '0-1-1'

Setting up a new slave server with global transaction ID

• Setting up from backup

  XtraBackup and mysqldump 備份獲得master位置，而後BINLOG_GTID_POS函數轉換爲gtid位置：
  SELECT BINLOG_GTID_POS("master-bin.000001", 600);
  From version 10.0.13, mysqldump 使用--master-data時，就自動包含了gtid位置。
  獲得位置後，使用以下命令，change master：

  SET GLOBAL gtid_slave_pos = "0-1-2"; -- BINLOG_GTID_POS 函數獲得的位置
      CHANGE MASTER TO master_host="127.0.0.1", master_port=3310, master_user="root", master_use_gtid=slave_pos;
      START SLAVE;

  From version 10.0.13, mysqldump can automatically include these commands in the output if the --gtid option is used with --master-data or --dump-slave 。混合使用--master-data和--gtid ，就自動包含上述change master命令.

• Switching an existing old-style slave to use GTID.

  很簡單，只要主庫是支持gtid的（10.0.2 之後 ），slave內部已經在binlog記錄了gtid位置，因此切換很簡單，使用以下命令:

  STOP SLAVE;
      CHANGE MASTER TO master_host="127.0.0.1", master_port=3310, master_user="root", master_use_gtid=current_pos;
      START SLAVE;

• Changing a slave to replicate from a different master

  因爲GTID是全局統一的，只須要指向新的IP和新的端口便可

  STOP SLAVE;
      CHANGE MASTER TO master_host='127.0.0.1', master_port=3312;
      START SLAVE;

gtid_strict_mode

set @@GLOBAL.gtid_strict_mode to 1 禁止slave上單獨的操做。
遇到錯誤時，能夠關閉嚴格模式，使用 START SLAVE UNTIL master_gtid_pos=XXX 來跳過

START SLAVE UNTIL master_gtid_pos = <GTID position>

If multiple GTIDs are specified, then they must be with distinct replication domain ID, for example:

START SLAVE UNTIL master_gtid_pos = "1-11-100,2-21-50"

MASTER_GTID_WAIT(gtid-list[, timeout)

GTID有關的三個全局變量

select @@global.gtid_slave_pos, @@global.gtid_binlog_pos,@@global.gtid_current_pos;

• gtid_slave_pos：

This variable is the GTID of the last event group replicated on a slave server, for each replication domain.

• gtid_binlog_pos:

This variable is the GTID of the last event group written to the binary log, for each replication domain.

• gtid_current_pos:

This variable is the GTID of the last change to the database for each replication domain. Such changes can either be master events (ie. local changes made by user or application), or replicated events originating from another master server.

測試過程詳見 http://blog.segmentfault.com/alading/1190000000601849