MySQL5.6 新特性之GTID

背景： 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需要启用这三个参数：#GTIDgtid_mode = onenforce_gtid_consistency = 1log_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-updates2015-08-09 02:33:57 6512 [ERROR] Aborting2015-08-09 02:39:58 9860 [ERROR] --gtid-mode=ON or UPGRADE_STEP_1 requires --enforce-gtid-consistency2015-08-09 02:39:58 9860 [ERROR] Aborting具体的方法可以参考官方文档。三个实例开启之后（3306、3307、3308），执行change的时候也要注意：各个实例的uuid：
3306:mysql> select @@server_uuid;+--------------------------------------+| @@server_uuid|+--------------------------------------+| 4e659069-3cd8-11e5-9a49-001c4270714e |+--------------------------------------+3307:mysql> select @@server_uuid;+--------------------------------------+| @@server_uuid|+--------------------------------------+| 041d0e65-3cde-11e5-9a6e-001c4270714e |+--------------------------------------+3308:mysql> select @@server_uuid;+--------------------------------------+| @@server_uuid|+--------------------------------------+| 081ccacf-3ce4-11e5-9a95-001c4270714e |+--------------------------------------+使用5.6之前的主从change：mysql> change master to master_host="127.0.0.1",master_user="rep",master_password="rep",master_log_file="mysql-bin3306.000001",master_log_pos=151,/*master_auto_position=1*/;报错：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.当使用 MASTER_AUTO_POSITION 参数的时候，MASTER_LOG_FILE，MASTER_LOG_POS参数不能使用。使用5.6之后的主从change：mysql> change master to master_host="127.0.0.1",master_user="rep",master_password="rep",master_port=3306,master_auto_position=1;在执行上面的命令的时候会报错2个warnings，主要的原因是复制账号安全的问题，相关的信息可以看这里 http://www.linuxidc.com/Linux/2015-08/121500.htm 。从总体上看来，由于要支持GTID，所以不需要手工确定主服务器的MASTER_LOG_FILE及MASTER_LOG_POS。要是不需要GTID则需要指定FILE和POS。在2个从上执行上面命令，到此主从环境搭建完成。GTID的主从完成之后可以通过show processlist查看：mysql> show processlistG;*************************** 1. row *************************** Id: 38 User: rep Host: localhost:52321 db: NULLCommand: Binlog Dump GTID #通过GTID复制 Time: 48State: Master has sent all binlog to slave; waiting for binlog to be updated Info: NULLRows_sent: 0Rows_examined: 0更多详情见请继续阅读下一页的精彩内容： http://www.linuxidc.com/Linux/2015-08/121499p2.htm

MongoDB升级用户授权数据到2.6格式关于MySQL密码你应该知道的那些事相关资讯 MySQL5.6 MySQL5.6新特性 GTID

CentOS 7下修改MySQL5.6编码方式（今 07:35）