GTID即全局事务ID (global transaction identifier), 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。GTID最初由google实现,官方MySQL在5.6才加入该功能。mysql主从结构在一主一从情况下对于GTID来说就没有优势了,而对于2台主以上的结构优势异常明显,可以在数据不丢失的情况下切换新主。使用GTID需要注意: 在构建主从复制之前,在一台将成为主的实例上进行一些操作(如数据清理等),通过GTID复制,这些在主从成立之前的操作也会被复制到从服务器上,引起复制失败。也就是说通过GTID复制都是从最先开始的事务日志开始,即使这些操作在复制之前执行。比如在server1上执行一些drop、delete的清理操作,接着在server2上执行change的操作,会使得server2也进行server1的清理操作。
GTID实际上是由UUID+TID (即transactionId)组成的。其中UUID(即server_uuid) 产生于auto.conf文件,是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增,所以GTID能够保证每个MySQL实例事务的执行(不会重复执行同一个事务,并且会补全没有执行的事务)。GTID在一组复制中,全局唯一。
mysql> show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000001 | 620 | | | ec4eca2c-10b5-11ed-b6b8-000c29fb2070:1-2 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
GTID:ec4eca2c-10b5-11ed-b6b8-000c29fb2070:1-2
UUID:ec4eca2c-10b5-11ed-b6b8-000c29fb2070
TID:1-2
在整个复制架构中GTID是不变化的,即使在多个连环主从中也不会变。
了解了GTID的格式,通过UUID可以知道这个事务在哪个实例上提交的。通过GTID可以极方便的进行复制结构上的故障转移,新主设置
假设现在有server1、server2、server3三台数据库,server1为主,server2、server3为从,如图
现在Server1(Master)崩溃,根据从库上show slave status获得Master_log_File/Read_Master_Log_Pos的值,Server2(Slave)已经和主库同步,Server3(Slave)没有和主库同步。这时要把Server2提升为主,Server3变成Server2的从。那在Server3上执行change的时候需要做一些计算。
这个问题在5.6的GTID出现后,就显得非常的简单。由于同一事务的GTID在所有节点上的值一致,那么根据Server3当前停止点的GTID就能定位到Server2上的GTID。甚至由于MASTER_AUTO_POSITION功能的出现,我们都不需要知道GTID的具体值,直接使用change master to master_host=‘xxx’,master_auto_position命令就可以直接完成failover的工作。
GTID和binlog的关系
binlog
|
---|
版本信息,binlog metadata,etc |
previous_gtid_log_event |
GTID event |
GTID event |
… |
Previous_gtid_log_event
Previous_gtid_log_event 在每个binlog 头部都会有,每次binlog rotate的时候存储在binlog头部,Previous-GTIDs在binlog中只会存储在这台机器上执行过的所有binlog,不包括手动设置gtid_purged值。
假设有4个binlog: bin.001,bin.002,bin.003,bin.004
bin.001 : Previous-GTIDs=empty; binlog_event有: 1-40
bin.002 : Previous-GTIDs=1-40; binlog_event有: 41-80
bin.003 : Previous-GTIDs=1-80; binlog_event有: 81-120
bin.004 : Previous-GTIDs=1-120; binlog_event有: 121-160
假设现在我们要找GTID=$A,那么MySQL的扫描顺序为从最后一个binlog也就是bin.004开始扫描
参数 | comment |
---|---|
gtid_executed | 执行过的所有GTID |
gtid_purged | 丢弃掉的GTID |
gtid_mode | GTID模式 |
gtid_next | session级别的变量,下一个gtid |
gtid_owned | 正在运行的GTID |
enforce_gtid_consistency | 保证GTID安全的参数 |
开启GTID的条件
gtid_mode=on (必选)
enforce-gtid-consistency=1 (必选)
log_bin=mysql-bin (可选) #高可用切换,最好开启该功能
log-slave-updates=1 (可选) #高可用切换,最好打开该功能
从服务器连接到主服务器之后,把自己执行过的GTID (Executed_Gtid_Set: 即已经执行的事务编码) 、获取到的GTID (Retrieved_Gtid_Set: 即从库已经接收到主库的事务编号) 发给主服务器,主服务器把从服务器缺少的GTID及对应的transactions发过去补全即可。当主服务器挂掉的时候,找出同步最成功的那台从服务器,直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主, 先change到同步最成功的那台从服务器, 等把GTID全部补全了,就可以把它提升为主了。
GTID是MySQL 5.6的新特性,可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时,MySQL Server在写binlog的时候,会先写一个特殊的Binlog Event,类型为GTID_Event,指定下一个事务的GTID,然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库,从库在执行的时候也是用同样的GTID写binlog,这样主从同步以后,就可通过GTID确定从库同步到的位置了。也就是说,无论是级联情况,还是一主多从情况,都可以通过GTID自动找点儿,而无需像之前那样通过File_name和File_position找点了。
工作流程
主数据库IP:192.168.159.100 mysql-5.7
从数据库IP:192.168.159.139 mysql-5.7
主库配置
[root@100 ~]# vim /etc/my.cnf //添加以下内容
log-bin=mysql-bin
server-id=10
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
[root@100 ~]# service mysqld restart
Shutting down MySQL.. SUCCESS!
Starting MySQL. SUCCESS!
从库配置
[root@139 ~]# vim /etc/my.cnf //添加以下内容
server-id=20
relay-log=mysql-relay
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
read_only=on
master-info-repository=TABLE
relay-log-info-repository=TABLE
[root@139 ~]# service mysqld restart
Shutting down MySQL.. SUCCESS!
Starting MySQL. SUCCESS!
在主库授权用户
mysql> grant replication slave on *.* to 'slave'@'192.168.159.139' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)
在从库设置要同步的主库信息
mysql> change master to master_host='192.168.159.100',master_user='slave',master_password='123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)
mysql> start slave;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.159.100
Master_User: slave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 452
Relay_Log_File: mysql-relay.000002
Relay_Log_Pos: 665
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes //此处要为yes
Slave_SQL_Running: Yes //此处要为yes
测试
//在主库进行一些操作
mysql> insert into test1(id,name,age) values(6,'six',21);
Query OK, 1 row affected (0.00 sec)
mysql> update test1 set age = 28 where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from test1;
+----+-------+------+
| id | name | age |
+----+-------+------+
| 1 | one | 28 |
| 2 | two | 22 |
| 3 | three | 25 |
| 4 | four | 23 |
| 5 | five | 26 |
| 6 | six | 21 |
+----+-------+------+
6 rows in set (0.00 sec)
//在从库查看是否同步
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select * from test1;
+----+-------+------+
| id | name | age |
+----+-------+------+
| 1 | one | 28 |
| 2 | two | 22 |
| 3 | three | 25 |
| 4 | four | 23 |
| 5 | five | 26 |
| 6 | six | 21 |
+----+-------+------+
6 rows in set (0.00 sec)