MySQL5.7配置GTID主从---搭建GTID主从
准备说明：
master：192.168.10.100
slave：192.168.10.101
一、配置GTID参数
配置文件均为/etc/my.cnf
Master参数配置：
gtid-mode = ON
enforce-gtid-consistency = ON
server-id =100
binlog_format = ROW
log-bin = mysql-bin
Slave上参数配置：
gtid-mode = ON
enforce-gtid-consistency = ON
server-id =200
binlog_format = ROW
log-bin = mysql-bin
log_slave_updates = ON
skip-slave-start = 1
二、配置同步账号：
mysql> grant replication slave on *.* to 'sunfei'@'192.168.10.%' identified by 'sunfei';
mysql> flush privileges;
192.168.10.%是同步的主机IP，建议末尾采用%，这样以后内网在添加slave的可以直接同步。
三、备份主库数据
mysqldump -uroot -p --master-data=2 --single-transaction -R --triggers --events -A > master.sql
新库的可以免去此操作，直接配置同步即可
备份参数说明：
-h, --host=name 要导出的目标数据库所在主机，默认是localhost
-u, --user=name 链接目标数据库的数据库用户名
-p, --password[=name] 链接目标数据库的数据库密码
-P, --port=# 链接目标数据库的端口
--add-drop-database 在使用--databases或--all-databases参数时在每个create database命令前都加上drop database命令
--add-drop-table 在每个create table命令前加上drop table命令
--default-character-set=name 指定默认的字符集，默认是UTF8
--replace 使用该命令插入数据而不是使用insert命令
--set-charset 将set names default_character_set命令写入到导出备份文件中，默认是开启状态
--dump-slave[=#] 表示从复制的slave从库导出备份，且其中包含了change master 通语句。value参数如果不写或=-1的情况下，则change master to语句写入dump文件中，设置为2则表示也写入dump文件中，只是会注释掉
--master-data[=#] 表示从复制的主库上导出备份。value参数与--dump-slave相同。使用该参数会自动打开lock-all-table参数，除非同时使用--single-transaction参数
-T, --tab=name 表示将备份文件以文本文件的方式生成，并指定存放文件路径，每个表会生成两个文件，一个是.sql文件保存表结构，一个是.txt文件保存表数据信息
-A, --all-databases 导出所有数据库里的所有表
-B, --databases 导出指定的一个或多个数据库
--ignore-table=name 代表导出过程中忽略某个指定表的导出，如果要忽略多个表则这个参数使用多次
-d, --no-data 代表只导出表结构
-R, --routines 代表导出时也要把存储过程和函数也导出来
--triggers 代表导出时也将触发器导出来
-w, --where=name 代表导出符合条件的数据
-x, --lock-all-tables 代表在导出过程中对每个数据库的每个表加上一个只读锁
--no-autocommit 代表对每个表的数据导出内容用set autocommit=0和commit两个语句包裹
--single-transaction 代表将事务隔离级别设置为可重复读并在导出开始执行start transaction开启一个新事务，在dump执行过程中也不会阻止任何读写操
四、配置从库同步
1、导入Master备份的数据
mysql -uroot -p < master.sql
2、配置同步
mysql> CHANGE MASTER TO
MASTER_HOST='192.168.10.100',
MASTER_USER='sunfei',
MASTER_PASSWORD='sunfei',
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;
3、开启同步并查看同步状态
mysql> start slave；
mysql> show slave statusG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.100
Master_User: sunfei
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 918
Relay_Log_File: Client-relay-bin.000004
Relay_Log_Pos: 454
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 918
Relay_Log_Space: 962
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1003306
Master_UUID: b3f31135-4851-11e8-b758-000c29148b03
Master_Info_File: master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: b3f31135-4851-11e8-b758-000c29148b03:1-4
Executed_Gtid_Set: 25d36cbf-485a-11e8-a621-000c292c6f36:1-3,
b3f31135-4851-11e8-b758-000c29148b03:1-4
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec
参数说明：
Retrieved_Gtid_Set: b3f31135-4851-11e8-b758-000c29148b03:1-4 #表示收到的事务数
Executed_Gtid_Set: 25d36cbf-485a-11e8-a621-000c292c6f36:1-3,b3f31135-4851-11e8-b758-000c29148b03:1-4 #表示执行完的事务数
当出现主从故障的时候，可以从这里观察具体卡在哪个事务。
跳过事务：
假如主从复制出现错误
当在 slave 上执行 show slave statusG
Retrieved_Gtid_Set: UUID:1-5
Executed_Gtid_Set: UUID:1-4
此时 Slave_SQL_Running: No
上面的信息表明：
slave 收到了 UUID:1-5 个事务，执行成功 UUID:1-4，1-4 表示已经执行完成了。在这里出现了错误，也就是说执行 UUID:1-5时出现了错误。所以我们应该要跳过下一个事务即 5；
解决方法：
按照下列步骤执行
mysql> stop slave;
mysql> set gtid_next='UUID:5';
mysql> begin;
mysql> commit;
mysql> set gtid_next='automatic';
mysql> start slave;
在跳过之前，分析一下 Binlog 并且记录下来，分析是否可以跳过。跳过之后，看一下主从数据是否一致，是否需要修复数据等等。总之，需要具体问题具体分析，请谨慎操作。
五、GTID参数介绍
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 |
+----------------------------------+-----------+
8 rows in set (0.01 sec)
相关参数说明：
gtid_mode:
- ON: 产生 GTID，slave 只接受带 GTID 的事务
- ON_PERMISSIVE: 产生 GTID，slave 接受不带 GTID 事务也接受带 GTID 的事务
- OFF : 不产生 GTID，slave 只接受不带参 GTID 的事务
- OFF_PERMISSIVE: 不产生 GTID，slave 接受不带 GTID 事务也接受带 GTID 的事务
enforce-gtid-consistency
- ON: 当发现语句/事务不支持 GTID 时，返回错误信息
- WARN: 当发现不支持语句/事务，返回警告，并在日志中记录警告信息
- OFF: 不检查是否有 GTID 不支持的语句/事务
gtid_executed_compression_period #这个参数是控制表压缩率
gtid_next:automatic #gtid获取下一个事务的方式，automatic为自动获取，当出现slave故障需要跳过某事务的时候，这里可以指定事务的ID
gtid_owned： #表示正在执行的事务的gtid以及对应的线程ID
gtid_purged： #已经被删除的binlog的事务，它是GTID_EXECUTED的子集，从MySQL5.6.9开始，该变量无法被设置
session_track_gtids：