以下哪一个不是mysql5.6的新特性之一 支持gtid
发布网友
发布时间：2022-04-08 08:23
共1个回答
热心网友
时间：2022-04-08 09:52
MySQL5.6在5.5的基础上增加了一些改进，本文章先对其中一个一个比较大的改进"GTID"进行说明。
概念：
GTID即全局事务ID（global transaction identifier），GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。下面是一个GTID的具体形式：
4e659069-3cd8-11e5-9a49-001c4270714e:1-77
更具体的说明见官方说明。
GTID意义：
引入GTID的意义是什么？
1)因为清楚了GTID的格式，所以通过UUID可以知道这个事务在哪个实例上提交的。
2)通过GUID可以极方便的进行复制结构上的故障转移，新主设置。很好的解决了下面这个图（图来自高性能MySQL第10章）的问题。
上面图的意思是：Server1(Master)崩溃，根据从上show slave status获得Master_log_File/Read_Master_Log_Pos的值，Server2(Slave)已经跟上了主，Server3(Slave)没有跟上主。这时要是把Server2提升为主，Server3变成Server2的从。这时在Server3上执行change的时候需要做一些计算，这里就不做说明了，具体的说明见高性能MySQL第10章，相对来说是比较麻烦的。
这个问题在5.6的GTID出现后，就显得非常的简单。由于同一事务的GTID在所有节点上的值一致，那么根据Server3当前停止点的GTID就能定位到Server2上的GTID。甚至由于MASTER_AUTO_POSITION功能的出现，我们都不需要知道GTID的具体值，直接使用CHANGE MASTER TO MASTER_HOST='xxx'， MASTER_AUTO_POSITION命令就可以直接完成failover的工作。
测试：
1）复制环境的搭建：具体的复制搭建的步骤可以在网上搜索
因为支持GTID，所以5.6多了几个参数：
mysql> show variables like '%gtid%';
+---------------------------------+-----------+
| Variable_name | Value |
+---------------------------------+-----------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | OFF |
| gtid_deployment_step | OFF |
| gtid_executed | |
| gtid_mode | OFF |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+-----------+
主从环境的搭建和5.5没有什么区别，唯一需要注意的是：开启GTID需要启用这三个参数：
#GTID
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates = 1
任意一个参数不开启则都会报错：
2015-08-09 02:33:57 6512 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 or UPGRADE_STEP_2 requires --log-bin and --log-slave-updates
2015-08-09 02:33:57 6512 [ERROR] Aborting
2015-08-09 02:39:58 9860 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 requires --enforce-gtid-consistency
2015-08-09 02:39:58 9860 [ERROR] Aborting
具体的方法可以参考官方文档。
