1、如何定义和生成GTIDs
唯一性:在所有主从库都是唯一的,由二元组构成
每个事务和GTIDs之间都有1:1映射
GTID = source_id:transaction_id
source_id标记主库的server_uuid
transaction_id是一个递增序列,从1开始,包含5个事务的GTID
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
START SLAVE对于GTIDs的支持:
START SALVE有SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS选项
1.1 server_uuid
获取server_uuid的方式
a、判断data_dir/auto.cnf文件是否存在,如果存在返回
b、不存在的话,自动产生一个新的UUID,并保存到data_dir/auto.cnf中
auto.cnf文件格式如下:
[auto]
server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562
auto.cnf文件是自动产生的,不要试图修改这个文件。
如果主库的server_uuid发生变化的话,需要重新change master to,故这个auto.cnf文件是只读的。
http://dev.mysql.com/doc/refman/5.6/en/replication-options.html#sysvar_server_uuid
1.2 GTID sets
gtid_set:
uuid_set [, uuid_set] ...
| ''
uuid_set:
uuid:interval[:interval]...
uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
h:
[0-9|A-F]
interval:
n[-n]
(n >= 1)
存在多种使用:
a、gtid_executed记录已经执行过的gtid,gtid_purged记录已经执行过的并且已经从binlog中删除的
mysql> show global variables like '%gti%';
+--------------------------+------------------------------------------------------------------------------------+
| Variable_name | Value |
+--------------------------+------------------------------------------------------------------------------------+
| enforce_gtid_consistency | ON |
| gtid_executed | 5f02986b-c5de-11e3-8d21-001e4f1ef3b7:1-8,
b9d59578-df02-11e3-b112-001e4f1f39cf:1-2 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 5f02986b-c5de-11e3-8d21-001e4f1ef3b7:1-8,
b9d59578-df02-11e3-b112-001e4f1f39cf:1-2 |
+--------------------------+------------------------------------------------------------------------------------+
b、GTID_SUBSET() 和GTID_SUBTRACT()函数
1.3 GTID产生过程
(1)事务执行完成,并在主库提交
使用主库的UUID以及最小的事务序列数,并将GTID记录到主库的binlog中
(2)当binlog的数据被从库接收后,并存储在relay log中,此时从库SQL线程读取GTID,并将其赋值给变量gitd_next
(3)从库检查GTID,确认没有执行过。如果这个GTID没有使用过,从库写入GTID,并回放这个事务。
slave需要确保两点:
a、GTID没有被之前的事务使用过
b、相关联的事务没有被提交
(4)因为gtid_next非空,slave不会尝试产生一个新GTID,而是将GTID保存在变量gtid_next中
2、如何设置基于GTIDs的同步
一主一从配置方式
先配置好主从异步复制,再次不赘述
2014-06-09 10:35:53 19208 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates
配置文件中设置:
gtid-mode = ON
enforce_gtid_consistency = 1
log-bin = mysql-bin
log-slave-updates = 1
http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html
设置同步:
mysql> CHANGE MASTER TO
> MASTER_HOST = host,
> MASTER_PORT = port,
> MASTER_USER = user,
> MASTER_PASSWORD = password,
> MASTER_AUTO_POSITION = 1;
不需要使用MASTER_LOG_FILE和MASTER_LOG_POS
如果使用上面两个参数,需要将MASTER_AUTO_POSITION设置为0
否则会出现以下错误提示:
ERROR 1776 (HY000): Parameters MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when MASTER_AUTO_POSITION is active.
3、使用GTIDs进行Failover和Scaleout
基于Gtids带来的一些优势:
(1)、简单复制(Simple replication)
无需找点,会基于Gtids自行找点以及过滤相同gtid的事务,不会存在重复执行的问题
红色标注的地方是和传统的binlog不同的地方,从库上记录每个事务的gtid,这样在主从切换的时候不需要再找点,只需要比较事务id即可
(2)、将数据和事务拷贝到从库(Copying data and transactions to the slave)
数据方式:通过mysqldump方式,需要设置两个选项--master-data和--set-gtid-purged,并且从库上需要设置--git-mode=ON
事务方式:通过mysqlbinlog,通过两个选项 --read-from-remote-server和--read-from-remote-master ,使用--raw选项生成SQL文件导入
(3)、注入空事务(Injecting empty transactions)
对这个地方没太理解
(4)、通过gtid_purged过滤事务(Excluding transactions with gtid_purged)
gtid_purged记录一些已经被执行完成的gtid,并且对应的binlog已经被清理
5.6.9以前的版本没有gtid_purged这个变量
4、使用GTIDs的一些建议
1、对于基于statement和row的复制都支持,建议使用基于row格式
5、使用GTIDs的限制
5.1更新涉及到非事务存储引擎
在同一个事务中提交包含对非事务存储引擎的修改,会对应不同的Gtids
主从一对一的Gtid被破坏
6、参考文献
http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html
http://qing.blog.sina.com.cn/1757661907/68c3cad333002qhe.html
http://qing.blog.sina.com.cn/1757661907/68c3cad333002qsk.html
http://qing.blog.sina.com.cn/1757661907/68c3cad333002s5l.html
http://code.openark.org/blog/mysql/thoughts-on-mysql-5-6-new-replication-features
http://www.mysqlsystems.com/2013/03/mysql-replication-gtid-notes.html