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