MySQL基于Gtid的主从复制

MySQL基于gtid主从复制

一、Gtid概念

从 MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID保证了每个在主库上提交的事务在集群中有一个唯一的ID。 这种方式强化了数据库的主备一致性，故障恢复以及容错能力。

在原来基于二进制日志的复制中，从库需要告知主库要从哪个偏移量进行增量同步，如果指定错误会造成数据的遗漏，从而造成数据的不一致。借助GTID，在发生主备切换的情况下，MySQL的其它从库可以自动在新主库上找到正确的复制位置，这大大简化了复杂复制拓扑下集群的维护，也减少了人为设置复制位置发生误操作的风险。另外，基于GTID的复制可以忽略已经执行过的事务，减少了数据发生不一致的风险。

二、什么是Gitd

GTID (Global Transaction ID) 是对于一个已提交事务的编号，并且是一个全局唯一的编号。 G**TID 实际上 是由
UUID+TID 组成的 。其中 UUID 是一个 MySQL 实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增**。

下面是一个GTID的具体形式：3E11FA47-71CA-11E1-9E33-C80AA9429562:23，冒号分割前边为uuid，后边为TID。

GTID 集合可以包含来自多个 MySQL 实例的事务，它们之间用逗号分隔。

如果来自同一MySQL实例的事务序号有多个范围区间，各组范围之间用冒号分隔。例如： e6954592-8dba-11e6-af0e-fa163e1cf111:1-5:11-18,e6954592-8dba-11e6-af0e-fa163e1cf3f2:1-27 可以使用show master status实时查看当前事务执行数

三、Gtid的作用

Gtid采用了新的复制协议，旧协议是，首先从服务器上在一个特定的偏移量位置连接到主服务器上一个给定的二进制日志文件，然后主服务器再从给定的连接点开始发送所有的事件。

新协议有所不同，支持以全局统一事务ID (GTID)为基础的复制。当在主库上提交事务或者被从库应用时，可以定位和追踪每一个事务。GTID复制是全部以事务为基础，使得检查主从一致性变得非常简单。如果所有主库上提交的事务也同样提交到从库上，一致性就得到了保证。

四、Gtid的工作原理

①当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
②binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
③sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
④如果有记录，说明该GTID的事务已经执行，slave会忽略。
⑤如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，
在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
⑥在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

五、配置Gtid

环境：

master主机192.168.1.10
slave主机192.168.1.12

步骤：
①master主配文件

[mysqld]
basedir = /usr/local/mysql
datadir = /usr/local/mysql/data
port = 3306
server_id = 1    #服务器id
socket = /usr/local/mysql/mysql.sock
log-error = /usr/local/mysql/data/mysqld.err
gtid_mode = on    #开启gtid模式
enforce_gtid_consistency = on    #强制gtid一致性，开启后对特定的create table不被支持
log-bin = mysql-bin    #开启二进制日志
binlog_format = row    #默认为mixed混合模式，更改成row复制，为了数据一致性
log-slave-updates = 1    #从库binlog才会记录主库同步的操作日志
skip_slave_start=1    #跳过slave复制线程

②slave主配文件

[mysqld]
basedir = /usr/local/mysql
datadir = /usr/local/mysql/data
port = 3306
server_id = 2
socket = /usr/local/mysql/mysql.sock
log-error=/usr/local/mysql/data/mysqld.err
log-bin = mysql-bin
binlog_format = row
log-slave-updates = 1
gtid_mode = on
enforce_gtid_consistency = on
skip_slave_start=1

③配置slave主机

检查gtid模式状态

mysql> show variables like '%gtid%';

Variable_name	Value
binlog_gtid_simple_recovery	ON
enforce_gtid_consistency	ON
gtid_executed_compression_period	1000
gtid_mode	ON
gtid_next	AUTOMATIC
gtid_owned
gtid_purged
session_track_gtids	OFF

mysql>
CHANGE MASTER TO MASTER_HOST='192.168.1.10',MASTER_USER='myslave',MASTER_PASSWORD='123.com',MASTER_AUTO_POSITION=1;

mysql> show slave status \G;

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.10
                  Master_User: myslave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 437
               Relay_Log_File: 192-relay-bin.000002
                Relay_Log_Pos: 650
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......

④验证主从复制
master主机：
mysql> create database test;
Query OK, 1 row affected (0.00 sec)

mysql> use test;
Database changed
mysql> create table tb (id int);
Query OK, 0 rows affected (0.02 sec)

mysql> insert into tb values(1);
Query OK, 1 row affected (0.00 sec)

slave主机：
[root@192 ~]# cd /usr/local/mysql/data/
[root@192 data]# mysqlbinlog mysql-bin.000001 -vv

......
#180411 21:17:50 server id 1  end_log_pos 1216 CRC32 0x9c90f8e6     Write_rows: table id 219 flags: STMT_END_F

BINLOG '
/grOWhMBAAAALQAAAJgEAAAAANsAAAAAAAEABHRlc3QAAnRiAAEDAAGRo2sS
/grOWh4BAAAAKAAAAMAEAAAAANsAAAAAAAEAAgAB//4CAAAA5viQnA==
'/*!*/;
### INSERT INTO `test`.`tb`
### SET
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
.......

发现master主机插入的数据，已经在slave主机进行了同步，并且启用了log-bin-updates，在slave主机中的二进制日志记录了master主机操作。