MySQL 5.6 GTID新特性实践_Mysql

GTID简介

什么是GTID

GTID(Global Transaction ID)是对于一个已提交事务的编号，并且是一个全局唯一的编号。

GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。下面是一个GTID的具体形式

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

更详细的介绍可以参见：官方文档

GTID的作用

那么GTID功能的目的是什么呢？具体归纳主要有以下两点：

根据GTID可以知道事务最初是在哪个实例上提交的GTID的存在方便了Replication的Failover 这里详细解释下第二点。我们可以看下在MySQL 5.6的GTID出现以前replication failover的操作过程。假设我们有一个如下图的环境

此时，Server A的服务器宕机，需要将业务切换到Server B上。同时，我们又需要将Server C的复制源改成Server B。复制源修改的命令语法很简单即CHANGE MASTER TO MASTER_HOST='xxx', MASTER_LOG_FILE='xxx', MASTER_LOG_POS=nnnn。而难点在于，由于同一个事务在每台机器上所在的binlog名字和位置都不一样，那么怎么找到Server C当前同步停止点，对应Server B的master_log_file和master_log_pos是什么的时候就成为了难题。这也就是为什么M-S复制集群需要使用MMM,MHA这样的额外管理工具的一个重要原因。

这个问题在5.6的GTID出现后，就显得非常的简单。由于同一事务的GTID在所有节点上的值一致，那么根据Server C当前停止点的GTID就能唯一定位到Server B上的GTID。甚至由于MASTER_AUTO_POSITION功能的出现，我们都不需要知道GTID的具体值，直接使用CHANGE MASTER TO MASTER_HOST='xxx', MASTER_AUTO_POSITION命令就可以直接完成failover的工作。 So easy不是么?

基于GTID的主从复制简介

搭建

搭建使用了mysql_sandbox脚本为基础，先创建了一个一主三从的基于位置复制的环境。然后通过配置修改，将整个架构专为基于GTID的复制。

根据MySQL官方文档给出的GTID搭建建议。需要一次对主从节点做配置修改，并重启服务。这样的操作，显然在production环境进行升级时是不可接受的。Facebook,Booking.com,Percona都对此通过patch做了优化，做到了更优雅的升级。具体的操作方式会在以后的博文当中介绍到。这里我们就按照官方文档，进行一次实验性的升级。

主要的升级步骤会有以下几步：

确保主从同步在master上配置read_only，保证没有新数据写入修改master上的my.cnf，并重启服务修改slave上的my.cnf，并重启服务在slave上执行change master to并带上master_auto_position=1启用基于GTID的复制由于是实验环境，read_only和服务重启并无大碍。只要按照官方的GTID搭建建议做就能顺利完成升级，这里就不赘述详细过程了。下面列举了一些在升级过程中容易遇到的错误。

常见错误

gtid_mode=ON,log_slave_updates,enforce_gtid_consistency这三个参数一定要同时在my.cnf中配置。否则在mysql.err中会出现如下的报错

2016-10-08 20:11:08 32147 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates
2016-10-08 20:13:53 32570 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 requires --enforce-gtid-consistency

change master to 后的warnings

在按照文档的操作change master to后，会发现有两个warnings。其实是两个安全性警告，不影响正常的同步（有兴趣的读者可以看下关于该warning的具体介绍。warning的具体内容如下：

slave1 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.03 sec)
slave1 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave1 [localhost] {msandbox} ((none)) > show warnings;
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message |
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note | 1759 | Sending passwords in plain text without SSL/TLS is extremely insecure. |
| Note | 1760 | Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information. |
+-------+------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

实验一：如果slave所需要事务对应的GTID在master上已经被purge了

根据show global variables like '%gtid%'的命令结果我们可以看到，和GTID相关的变量中有一个gtid_purged。从字面意思以及官方文档可以知道该变量中记录的是本机上已经执行过，但是已经被purge binary logs to命令清理的gtid_set。
本节中我们就要试验下，如果master上把某些slave还没有fetch到的gtid event purge后会有什么样的结果。

以下指令在master上执行

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+----------------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+----------------------------------------+
7 rows in set (0.01 sec)
master [localhost] {msandbox} (test) > flush logs;create table gtid_test2 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.02 sec)
master [localhost] {msandbox} (test) > flush logs;create table gtid_test3 (ID int) engine=innodb;
Query OK, 0 rows affected (0.04 sec)
Query OK, 0 rows affected (0.04 sec)
master [localhost] {msandbox} (test) > show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000005 | 359 | | | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
master [localhost] {msandbox} (test) > purge binary logs to 'mysql-bin.000004';
Query OK, 0 rows affected (0.03 sec)
master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

在slave2上重新做一次主从，以下命令在slave2上执行

slave2 [localhost] {msandbox} ((none)) > change master to master_host='127.0.0.1',master_port =21288,master_user='rsandbox',master_password='rsandbox',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G
*************************** 1. row ***************************
......
Slave_IO_Running: No
Slave_SQL_Running: Yes
......
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 151
......
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Last_SQL_Errno: 0
Last_SQL_Error:
......
Auto_Position: 1
1 row in set (0.00 sec)

实验二：忽略purged的部分，强行同步

那么实际生产应用当中，偶尔会遇到这样的情况：某个slave从备份恢复后（或者load data infile）后，DBA可以人为保证该slave数据和master一致；或者即使不一致，这些差异也不会导致今后的主从异常（例如：所有master上只有insert没有update）。这样的前提下，我们又想使slave通过replication从master进行数据复制。此时我们就需要跳过master已经被purge的部分，那么实际该如何操作呢？

我们还是以实验一的情况为例：

先确认master上已经purge的部分。从下面的命令结果可以知道master上已经缺失24024e52-bd95-11e4-9c6d-926853670d0b:1这一条事务的相关日志

master [localhost] {msandbox} (test) > show global variables like '%gtid%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | 24024e52-bd95-11e4-9c6d-926853670d0b:1-3 |
| gtid_mode | ON |
| gtid_owned | |
| gtid_purged | 24024e52-bd95-11e4-9c6d-926853670d0b:1 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
7 rows in set (0.00 sec)

在slave上通过set global gtid_purged='xxxx'的方式，跳过已经purge的部分

slave2 [localhost] {msandbox} ((none)) > stop slave;
Query OK, 0 rows affected (0.04 sec)
slave2 [localhost] {msandbox} ((none)) > set global gtid_purged = '24024e52-bd95-11e4-9c6d-926853670d0b:1';
Query OK, 0 rows affected (0.05 sec)
slave2 [localhost] {msandbox} ((none)) > start slave;
Query OK, 0 rows affected (0.01 sec)
slave2 [localhost] {msandbox} ((none)) > show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
......
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 359
Relay_Log_File: mysql_sandbox21290-relay-bin.000004
Relay_Log_Pos: 569
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
......
Exec_Master_Log_Pos: 359
Relay_Log_Space: 873
......
Master_Server_Id: 1
Master_UUID: 24024e52-bd95-11e4-9c6d-926853670d0b
Master_Info_File: /data/mysql/rsandbox_mysql-5_6_23/node2/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
......
Retrieved_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:2-3
Executed_Gtid_Set: 24024e52-bd95-11e4-9c6d-926853670d0b:1-3
Auto_Position: 1
1 row in set (0.00 sec)

可以看到此时slave已经可以正常同步，并补齐了24024e52-bd95-11e4-9c6d-926853670d0b:2-3范围的binlog日志。

以上所述是小编给大家介绍的MySQL 5.6 GTID新特性实践，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对网站的支持！

以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索新特性
， mysql5.6
GTID
mysql 5.6 gtid、mysql 5.6 gtid 复制、mysql 5.6 gtid mha、mysql5.6切换gtid、mysql5.6新特性，以便于您获取更多的相关知识。

时间： 2024-10-31 19:35:04

MySQL 5.6 GTID新特性实践_Mysql的相关文章

MySQL 5.7版本新特性连载（四）

本文是基于MySQL-5.7.7-rc版本,未来可能 还会发生更多变化. 1.SQL MODE变化 a. 默认启用 STRICT_TRANS_TABLES 模式: b. 对 ONLY_FULL_GROUP_BY 模式实现了更复杂的特性支持,并且也被默认启用: c. 其他被默认启用的sql mode还有 NO_ENGINE_SUBSTITUTION: [iMySQL建议] 对广大MySQL使用者而言,以往不是那么严格的模式还是很方便的,在5.7版本下可能会觉得略为不适,慢慢习惯吧.比如向一个20字

知数堂《MySQL 5.7 Replication新特性》分享总结

2016.7.14,知数堂培训在线分享<MySQL 5.7 Replication新特性>获得了空前关注和好评,征得分享嘉宾同意后,PPT在此发布分享. 分享主题 <MySQL 5.7 Replication新特性> 嘉宾介绍 宋利兵,MySQL研发工程师.2009年加入MySQL全球研发团队,从事MySQL复制相关功能的开发. 主题介绍 主要分享在MySQL 5.7中,Replication(复制)相关的一些新特性,比如多源复制.增强半同步复制.并行复制等. Agenda GTI

【MySQL】MySQL5.6新特性之Index Condition Pushdown

一 概念介绍    Index Condition Pushdown (ICP)是MySQL 5.6 版本中的新特性,是一种在存储引擎层使用索引过滤数据的一种优化方式.a 当关闭ICP时,index 仅仅是data access 的一种访问方式,存储引擎通过索引回表获取的数据会传递到MySQL Server 层进行where条件过滤.b 当打开ICP时,如果部分where条件能使用索引中的字段,MySQL Server 会把这部分下推到引擎层,可以利用index过滤的where条件在存储引擎层进

【MySQL】5.7新特性之七

写在前面   本系列文章基于 5.7.12 版本讲述MySQL的新特性.从安装,文件结构,SQL ,优化 ,运维层面 复制,GITD等几个方面展开介绍 5.7 的新特性和功能.同时也建议大家跟踪官方blog和官方文档,以尽快知悉其新的变化.本文主要研究5.7 复制方面的改进和优化.7.1 Lock_log 锁优化  主从复制过程中,拉取主库的binlog 的时候有一把大锁 , 在 5.7.12 之前,dump thread读取binlog event事件的时候会持有锁,最严重的是client 的

【MySQL】5.7新特性之六

写在前面  本系列文章基于 5.7.12 版本讲述MySQL的新特性.从安装,文件结构,SQL ,优化 ,运维层面 复制,GITD等几个方面展开介绍 5.7 的新特性和功能.同时也建议大家跟踪官方blog和官方文档,以尽快知悉其新的变化.6.1  优化(工具方面)增强  5.7 版本中如果一个会话正在执行sql,且该sql 是支持explain的,那么我们可以通过指定会话id,查看该sql的执行计划. EXPLAIN [options] FOR CONNECTION connection_id

【MySQL】MySQL5.6新特性之crash-safe

一 介绍  MySQL 5.6 针对复制功能提供了新特性: slave支持crash-safe. 该功能可以解决之前版本中系统异常断电可能导致的SQL thread 信息不准确的问题.本文从原理方面对该特性进行介绍.二 原理  在了解crash-safe slave 之前,我们先分析一下MySQL 5.6 之前的版本出现 crash-unsafe 的原因.在slave上,复制包含两个线程:即replication中的IO thread和SQL thread.IO thread负责从master拷

【MySQL】5.7新特性之一

写在前面    MySQL 5.7版本于2015年10月份左右 GA,至今已经半年多了,但自己一直没有时间来follow MySQL 5.7 新的特性,作为MySQL DBA 实在汗颜,以后会花时间来研究5.7 版本的特性并针对部分优化功能做出压力测试.本系列基于5.7.12 版本来讲述MySQL的新特性,同时也建议大家跟踪官方blog和文档,以尽快知悉其新的变化. 一 安全性    MySQL 5.7 的目标是成为发布以来最安全的 MySQL 服务器,其在 SSL/TLS 和全面安全开发方面有

【MySQL】5.7新特性之四

写在前面  本系列文章基于5.7.12 版本讲述MySQL的新特性.从安装,文件结构,SQL ,优化 ,运维层面 复制,GITD等几个方面展开介绍5.7 的新特性和功能.同时也建议大家跟踪官方blog和官方文档,以尽快知悉其新的变化.前面写了一篇文章介绍 innodb 的特性,囿于相关知识点比较多 ,本文继续介绍5.7版本的innodb 新特性.4.1 innodb buffer dump 功能增强            5.7.5 新增加innodb_buffer_pool_dump_pct参

【MySQL】5.7新特性之五

一 写在前面   本系列文章基于 5.7.12 版本讲述MySQL的新特性.从安装,文件结构,SQL ,优化 ,运维层面 复制,GITD等几个方面展开介绍 5.7 的新特性和功能.同时也建议大家跟踪官方blog和官方文档,以尽快知悉其新的变化.本文将重点介绍新版本对JSON格式的支持.5.1  支持JSON   从MySQL 5.7.8 开始,MySQL支持原生的JSON格式,即有独立的json类型,用于存放 json格式的数据.JSON 格式的数据并不是以string格式存储于数据库而是以内部