MySQL主从配置-之GTID复制【第二篇】

学习本篇内容之前：建议先看一下windows中MySQL主从配置【第一篇】_Super乐的博客-CSDN博客windows中MySQL主从配置详细教程https://blog.csdn.net/wplblog/article/details/126935242?spm=1001.2014.3001.5502

        1、MySQL 5.6之前只支持传统复制，即 基于二进制日志文件和位置的复制，在5.6及之后的版本中，出现了基于GTID的复制。

       2、传统复制，也可以称为基于二进制日志文件和位置的复制，在从库中配置复制时，要求指定从库中获取的二进制日志文件(binlog file)和位置(binlog position),

以便从库中的复制线程启动时，能够以指定的二进制日志和位置为起点，持续读取主库中的二进制日志，并在从库中应用，从而达到数据库同步的目的。

       3、基于GTID的复制，是新的事务复制方法，利用GTID可以自动在主库寻找需要复制的二进制日志记录，因此不需要关心日志文件或位置，极大地简化了许多常见的复制任务。

        4、GTID（ Global Transaction Identifier）全局事务标识，由主库上生成的与事务绑定的唯一标识，这个标识不仅在主库上是唯一的，在MySQL集群内也是唯一的。

        5、GTID是 MySQL 5.6 版本引入的一个有关于主从复制的重大改进，相对于之前版本基于Binlog文件+Position的主从复制，基于GTID的主从复制，数据一致性更高，主从数据复制更健壮，主从切换、故障切换不易出错，很少需要人为介入处理。

        6、GTID之前的主从复制是基于文件+偏移的方式，建立主从复制，必须先知道主库的binlog文件和偏移位置（ MASTER_LOG_FILE 和 MASTER_LOG_POS）。

而使用基于GTID的主从复制，设置 MASTER_AUTO_POSITION =1，从库发送自身已经接收到的gtid给主库，主库将从库缺失的gtid及其对应的binlog文件发送给从库，也就是主库只发送从库没有接收到的事务。

        7、所有的信息由MySQL集群自动获取完成，不需要人为干预，大大简化了复制搭建过程。

MySQL 5.7.x 及之后的版本新增了一张InnoDB存储引擎的mysql.gtid_executed表来持久化GTID信息

第一步：修改主库配置，并重新启动MySQL服务

//在MySQL配置文件中添加
[mysqld]
#GTID复制
gtid-mode=on
#enforce-gtid-consistency打开导致的update更新失败
enforce-gtid-consistency=true

链接MySQL查看 master 的状态

1、未配置 GTID 之前，show master status 状态的结果，Executed_Gtid_Set: 是空的

2、 配置 GTID 以后，再次 show master status 状态的结果，Executed_Gtid_Set: 是有值的

 第二步：修改从库配置，并重启MySQL3服务

[mysql]
default-character-set=utf8

[mysqld]
port = 3307
basedir=D:\mysql5.7.39winx64
datadir=D:\mysql5.7.39winx64\data
max_connections=200
character-set-server=utf8
default-storage-engine=InnoDB
#服务的唯一编号
server-id=2
#开启mysql binlog功能
log-bin=mysql-bin
#binlog记录内容的方式，记录被操作的每一行
binlog_format=mixed
# 减少记录日志的内容，只记录受影响的列
binlog_row_image=minimal

replicate_wild_ignore_table=mysql.%
replicate_wild_ignore_table=performance_schema.%
replicate_wild_ignore_table=information_schema.%
#GTID复制
gtid_mode=on
#enforce-gtid-consistency打开导致的update更新失败
enforce-gtid-consistency=true

[client]
port=3307
default-character-set=utf8

 重点：主库和从库都需要下面两行的配置
#GTID复制
gtid_mode=on
#enforce-gtid-consistency打开导致的update更新失败
enforce-gtid-consistency=true

开启GTID后，就不在使用传统的复制方式了；GTID和传统复制方式的mysql实例是不能复制数据的，要么都是GTID，要么都是传统的复制方式；

在从库中执行一下SQL：

mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_HOST='127.0.0.1',MASTER_PORT=3306,MASTER_USER='root',MASTER_PASSWORD='root',master_auto_position=1;
mysql> start slave;
mysql> show slave status\G;

 参数说明：

master_host		        #主库IP
master_user			    #同步账号
master_password			#同步账号的密码
master_auto_position=1; #自动 position 号（偏移值）【不用填写binlog & position】

查看 slave 库状态，发现 Retrieved_Gtid_Set: 和  Executed_Gtid_Set: 都以有值了。

发现主库和从库的GTID是一致的就没问题

MySQL GTID复制模式有哪些限制

1.更新操作涉及非事务引擎

在同一个事务中，不能同时操作支持事务(InnoDB)和不支持事务(MyISAM)的引擎。

这是由于同时操作这两类引擎时可能导致将多个GTID被分配给同一个事务。

主从数据库Server中相同的表使用不同的存储引擎时(其中，一个Server使用事务表，另一个Server使用非事务表)，如果在非事务表上定义了触发器，可能导致事务与GTID之间一一对应关系被破坏。

2.CREATE TABLE .. SELECT 语句

使用GRID复制时，CREATE TABLE ...语句不允许同时使用SELECT语句。

当binlog_format设置statement时，CREATE TABLE ... SELECT语句是作为一个整体且只分配一个GTID的事务形式被记录在二进制日志中。

如果主库使用statement格式二进制日志，而从库使用row格式的二进制日志，则从库将无法正确处理事务。

3.临时表

使用GTID时(这里指的是系统变量enforce_gtid_consistency设置为ON时)，事务、存储过程、存储函数和触发器内不支持CREATE TEMPORARY TABLE和DROP TEMPORARY TABLE语句，

不过可以在这些对象之外执行CREATE TEMPORARY TABLE和DROP TEMPORARY TABLE语句，当需要使用autocommit = 1自动提交。

4.防止执行不受支持的语句

要防止执行会导致GTID复制失败的语句，则需要在启动GTID时，在整个复制拓扑的所有实例中启用系统变量enforce_gtid_consistency。

当启用此系统变量之后，上述可能会导致复制出现问题的语句将直接报错，不予执行。

5.关于跳过事务

使用GTID时不支持使用系统变量sql_slave_skip_counter来跳过事务。

6.忽略Server实例

使用GTID时，不推荐在CHANGE MASTER TO语句中使用IGNORE_SERVER_IDS选项来忽略某个Server实例的二进制日志变更，因为在GTID复制模式下，已经应用的事务会自动被忽略。

在启动GTID复制之前，请检查并清除该选项的设置。