mysql(3)基于GTID的主从复制（异步复制）

1.基于gtid的主从复制的基础知识

1.在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。
2.基于GTID则不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行。
3.和基于position的主从复制的不同之处在于：它是以一整个事件为单位进行复制的，pos是局部的复制，所以
（1）如果是基于position的主从复制：将一个事件拆开来复制，如果一个事件进行的过程中出现问题，那么复制也会出现问题
（2）如果是基于gtid的主从复制：一个以事件为单位进行复制，如果一个事件进行的过程中出现问题，那么复制也不会出现问题
4.开启GTID，无需找到binlog和POS点，直接change master to master_auto_postion=1即可，它会自动寻找同步
5.通过GDIT保证每个主库上提交的事务在集群中有一个唯一的ID.这种方式强化了数据库的主备一致性，故障恢复以及容错能力。

2.基于GTID复制实现的工作原理：

**
什么是GTID：
GTID实际上是由UUID+TID (即transactionId)组成的。其中UUID(即server_uuid) 产生于auto.conf文件(cat /data/mysql/data/auto.cnf)，是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增，所以GTID能够保证每个MySQL实例事务的执行（不会重复执行同一个事务，并且会补全没有执行的事务）。**

GTID在一组复制中，全局唯一。通过GDIT保证每个主库上提交的事务在集群中有一个唯一的ID.这种方式强化了数据库的主备一致性，故障恢复以及容错能力。

** 步骤
 1. 主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中。
2.从节点的I/O线程将变更的bin log，写入到本地的relay log中。
3.SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）。如果有记录，说明该GTID的事务已经执行，从节点会忽略。如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。**

3.实验

这个是基于上个position的环境做的

由官网可知，要先去修改配置文件
/etc/my.cnf加入
加入：开启gtid的信息
gtid_mode=ON
enforce-gtid-consistency=true

重启数据库

可以在mysql表里面找到GTID
看看server1的uuid

修改server2的配置文件

和server2一样

重启server2的数据库

mysql -uroot -pGaojia+123
show databases;
stop slave;
change master to master_host='172.25.62.1',master_user='repl',master_password='Gaojia+123',master_auto_position=1;从第一件事情开始跟踪
start slave;
show slave status\G；

停止从复制，之后设置GTID复制

现在没有插入数据时Gtid_set的参数后面没有

server1上插入数据

后面就有参数了

server2上也有gtid_excuted插件

可以看见server2里面gtid_excuted与之前看的server1的uuid相同