MySQL基于Gtid的主从复制

MySQL基于gtid主从复制

1、Gtid概念

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

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

2、什么是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实时查看当前事务执行数

3、Gtid的做用

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

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

4、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，确保不被重复执行。
⑥在解析过程当中会判断是否有主键，若是没有就用二级索引，若是没有就用所有扫描。

5、配置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主机操做。