一、基于GTID的异步复制（一主一从）无数据/少数据搭建
二、基于GTID的无损半同步复制（一主一从）（mysql5.7）基于大数据量的初始化
正文：
零、概念
【0.1】GTID（Global Transaction Identifiers）概念
GTID 复制（mysql 在 5.6.2 及之后开始支持GTID）
（1）对于一个已提交事务的编号，事务的唯一编号，并且是一个全局唯一的编号。GTID和事务会记录到binlog中，用来标识事务。
（2）GTID是用来替代以前，传统复制方法（binlog+position），mysql 5.6.2开始支持GTID。
（3）mysql支持GTID后，一个事务在集群中就不再孤单，在每一个节点中，如果存在具相同标识符的情况，可以避免同一个事务，在同一个节点出现多次的情况。
（可以初步理解成row模式的，和statement的区别，前者记得是具体做了什么事，后者记录的是位置）
（4）GTID的出现最直接的效果就是，每一个事物在集群中具有了唯一性的意义，相对于行复制来讲数据安全性更高，故障切换更简单。
【0.2】简单案例解释概念
比如，当我们一主2从，主出故障后切换到从DB1上去了，那么另外2台机器，需要重新手动构建主从；
具体为：
-- 使用传统方式构建的主库宕机重新搭建 -- 麻烦点：每台机器的Binlog名字和Postion位置点都不一样，需要重新定位文件在哪里，位置在哪里 change master to master_host='xxx', master_user='xxx', master_password='xxx', master_port='xxx', master_log_file='xxx', master_log_pos='xxx'; -- 使用GTID方式的主库宕机重新搭建 -- 优势点：每台机器上的GTID都是一样的，不需要管文件是哪个，位置在哪里，可以自动根据GTID定位 change master to master_host='xxx', master_user='xxx', master_password='xxx', master_port='xxx', master_auto_postion=1;
【0.3】GTID的组成
GTID 是由 server_uuid：Sequence_Number 组成；
（1）server_uuid：是一个mysql实例的全局唯一表示；存放在 ${datadir}/auto.cnf
（2）Sequence_Number：是mysql内部的一个事务的标号，一个mysql实例不会重复的序列号（保证服务器内唯一），也表示在该实例上已经提交事务的数量，并且随着事务提交而递增。
（3）根据GTID可以知道事务最初是在哪个实例上提交的，方便故障排查和切换
【0.4】GTID的限制
（1）不支持非事务引擎（从库报错，stopslave; start slave; 忽略）
（2）不支持create table … select 语句复制（主库直接报错，原因是该语句其实是一个DDL+DML）
（3）不允许在一个SQL同时更新一个事务引擎和非事务引擎的表
（4）在一个复制组中，必须要求统一开启GTID或是关闭GTID
（5）开启GTID需要重启（5.7中可能不需要）
（6）开启GTID后，就不在使用原来的传统的复制方式
（7）对于createtemporary table 和drop temporary table语句不支持
（8）不支持sql_slave_skip_counter
一、基于GTID的异步复制（一主一从）无数据/少数据搭建
【1】环境
操作系统：CentOS linux 7.5
数据库版本：5.7.24
数据库架构：主从复制，主库用于生产，从库用于数据容灾和主库备机，采用默认传统的异步复制。
主库IP：192.168.1.203 端口：3306
从库IP：192.168.1.204 端口：3306
【2】安装 mysql utilities（本文借助该工具进行安装）
cd /download
wget https://cdn.mysql.com/archives/mysql-utilities/mysql-utilities-1.6.5.tar.gz
tar xvf mysql-utilities-1.6.5.tar.gz
cd mysql-utilities-1.6.5
python setup.py build
python setup.py install
mysqldiff --version
没网的话去官网下载，在 download=》Archives=》左边导航栏里有MySQL Utilities
【3】开始配置
#核心语句：mysqlreplicate --master=root@localhost:3306 --slave=root@localhost:3306 --rpl-user=rpl:passwd
#【3.1】在主库上 准备复制账户
create user 'rpl'@'192.168.1.%' identified by '123456';
grant replication slave on *.* to 'rpl'@'192.168.1.%';
flush privileges;
select user,host from mysql.user;
#【3.2】参数配置（主从都配）
#replication_new log_bin=/mysql/log/3306/binlog/mysql-bin #开启binlog log_bin_index=/mysql/log/3306/mysql-bin.index binlog_format=row binlog_rows_query_log_events=on max_binlog_size=2048 bind-address=0.0.0.0 server_id=2013306 #注意，这里从库的server_id和主库一定不能一样 expire_logs_days=7 #超过7天的binlog清理 innodb_support_xa=1 binlog_cache_size=1M log_bin_trust_function_creators=1 #同步存储过程、函数、触发器 innodb_flush_log_at_trx_commit=1 sync_binlog=1 transaction-isolation=read-committed
#slave replication relay_log=/mysql/log/3306/relaylog/mysql-relay.log log-slave-updates=1 read_only=1 slave-parallel-type=LOGICAL_CLOCK slave-parallel-workers=4
master_info_repository=table #master_info 会记录到 mysql.slave_master_info relay_log_info_repository=table #relay_log 会记录到，mysql.slave_relay_log_info relay_log_recovery=1 slave_skip_errors=ddl_exist_errors slave_preserve_commit_order=1
#增加的GTID参数
gtid_mode=on
enforce_gtid_consistency=1 #on：当发现语句/事务不支持GTID时，返回错误信息
log-slave-updates=1
binlog_gtid_simple-recovery=1 #5.7.6以下默认为off，5.7.6以上默认为on
#【3.3】重启两台mysql
service mysql restart
#【3.4】主库上查看binlog
mysql -uroot -p123456
show master stauts; -- 记录下file_name 和 file_pos
#【3.5.1】使用mysqlreplicate(mysql utilities工具)命令配置
在从库上使 slave 与 master 建立连接，从而同步
#（1）从库配置（但是在主库上跑就好，这样多个从库都只需要在主库上跑即可）
mysqlreplicate --master=root:123456@192.168.1.203:3306 --slave=root:123456@192.168.1.204:3306 --rpl-user=rpl:123456 -b
#（2）测试
#测试test库是否一致（主库运行）
mysqlreplicate --master=root:123456@192.168.1.203:3306 --slave=root:123456@192.168.1.204:3306 --rpl-user=rpl:123456 --test-db=testdb
#检查复制（主从均可以运行，检查从库）
mysqlrplcheck --master=root:123456@192.168.1.203:3306 --slave=root:123456@192.168.1.204:3306 -s
#检查复制数据一致性
mysqlrplsync --master=root:123456@192.168.1.203:3306 --slave=root:123456@192.168.1.204:3306
#【3.5.2】使用传统方式配置
-- 使用GTID方式的主库宕机重新搭建 -- 优势点：每台机器上的GTID都是一样的，不需要管文件是哪个，位置在哪里，可以自动根据GTID定位 change master to master_host='xxx', master_user='xxx', master_password='xxx', master_port='xxx', master_auto_position=1;
#【3.6】主从数据测试（在主库上跑）
create database test1;
use test1;
create table test1(id int);
insert into test1 values(1),(2),(3);
commit;
select * from test1;
主库
从库
同步成功！
【4】我的其他文章
【4.1】mysql GTID复制实践：https://www.cnblogs.com/gered/p/11417019.html
【5】核验
【5.1】show slave statusG 查看是否有误
OK。两个线程启动了，Error字样的字段也没有任何问题。
【5.2】核验之前创建的用户是否有同步过来
OK，没有问题。
【5.3】在主库创建测试数据库与测试表查看同步情况
#创建test2库，以及test2.test1表 create database test2; create table test2.test1(id int); insert into test2.test1 values(1);
commit; select * from test2.test1;
从库查看
select * from test2.test1;
OK 核验完成。
【5.4】show global variables like '%gtid%' ; 查看GTID信息
可以查看是否开启，图中框出来的是最新事务的GTID，可以在主从上对照查看事务是否同步。
【5.5】查看gtid执行情况（系统表 mysql.gtid_executed）
看，正好执行了3个事务
二、基于GTID的无损半同步复制（一主一从）（mysql5.7）基于大数据量的初始化
【1】基于大数据量备份初始化从库的核心代码
-- 从库：利用备份初始化核心代码
reset master;
reset slave; set @TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN; set @@SESSION.SQL_LOG_BIN = 0; set @@GLOBAL.GTID_PURGED = 'backup infomation's GTID'; -- 核心 set @@SESSION.SQL_LOG_BIN = @TEMP_LOG_BIN;
-- 为了避免报错：@@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. 必须要加上reset master;
-- 5.7增强半同步额外参数
plugin_dir=/mysql/app/mysql/lib/plugin/ plugin_load=rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so #如果是5.7，参数前面加上loose_，如下列，如果是5.6 则直接使用 rpl_semi_sync_master_enabled=1 之类的就好了。 #我这里是5.7就直接做增强半同步了（loseless Semisynchronous ） loose_rpl_semi_sync_master_enabled=1 #MySQL开启主的半同步复制（rpl_semi_sync_master_enabled） loose_rpl_semi_sync_slave_enabled=1 #MySQL5.6开启从的半同步复制 loose_rpl_semi_sync_master_timeout=5000 #超时5秒，切回异步 rpl_semi_sync_master_wait_for_slave_count=1 #至少收到1个slave发会的ack rpl_semi_sync_master_wait_point=AFTER_SYNC #MySQL 5.7的方法，AFTER_SYNC（default，增强半同步） & AFTER_COMMIT（传统半同步）
【2】mysqldump备份恢复实现
【2.1】mysqldump备份与查看
mysqldump的方式： 1、在备份的时候指定--master-data=2（来保存binlog的文件号和位置的命令）。 2、使用mysqldump的命令在dump文件里可以看到下面两个信息： SET @@SESSION.SQL_LOG_BIN=0; SET @@GLOBAL.GTID_PURGED='7800a22c-95ae-11e4-983d-080027de205a:1-8'; 3、将备份还原到slave后，使用change master to命令挂载master端。
备份命令示例：
mysqldump -A -uroot -p123456 --single-transaction --master-data=2 --flush-privileges --routines --flush-logs >/mysql/backup/fulldb.bak
产生警告：告诉我们，数据会转储成GTID模式，如果想要拿一个完整的备份，请加上参数 --set-gtid-purged=OFF..这里我们不必理会
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database.
If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.
查阅mysqldump出来的文件，发现里面有设置GTID 的gtid_purged的配置，无需我们操心
【2.2】查看GTID配置参数
【2.3】开始5.7基于GTID的增强半同步配置
-- 在主库上 create user 'rpl'@'192.168.1.%' identified by '123456'; grant replication slave on *.* to 'rpl'@'192.168.1.%'; flush privileges; select user,host from mysql.user;
-- 在从库上
stop slave;
reset slave;
change master to master_host='192.168.1.201', master_user='rpl', master_password='123456', master_port=3306, master_auto_position=1;
start slave;
【2.4】核验
利用【一】中的【5】核验
利用【5.5】查看gtid执行情况（系统表 mysql.gtid_executed）
看，正好创建用户、授权、刷盘，一共执行了3个事务
【2.5】查看半同步情况
左边主库，右边从库，都开起来了。
但从no_tx参数中，发现有3个事务是没有通过半同步传输复制的（如果没有通过半同步就会通过异步）
原因是为什么呢，很简单，因为我们操作的三个事务，都是属于DDL的
然后我们再在主库插入一条DML试试。
果然，已经出来了，并且使用半同步复制过去的。
【3】xtrabackup备份恢复实现
【3.1】核心思路
1、Xtrabackup_binlog_info文件中，包含global.gtid_purged='XXXXXX:XXXX'的信息。 2、然后到slave去手工的 SET GLOBAL.GTID_PURGED='XXXXXX:XXXX'。
3、恢复备份，开启change master to 命令。
【3.2】查看备份
innobackupex --defaults-file=/etc/my.cnf -uroot -p123456 --no-timestamp /mysql/backup/xtra_full/
【3.3】手动设置主从
stop slave;
reset slave;
reset master;
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0; set global gtid_purged='de853101-b165-11e9-900a-000c291f4171:1-7';
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN ；
change master to
master_host='192.168.1.201',
master_user='rpl',
master_password='123456',
master_port=3306,
master_auto_position=1;
start slave;
-- 参考思路
若是你用xtrabackup备份的话：
开启gtid情况下：
innobackupex --apply-log
innobackupex --defaults-file=/etc/my.cnf --copy-back /backup
chown -R mysql.mysql datadir
service mysqld start
cat xtrabackup_info
show master status G
reset master;
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
SET @@GLOBAL.GTID_PURGED='c9c73c70-c089-11e7-8544-00163e0ad76e:1-107089934'; --xtrabackup_info中的gtid信息
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
change master to master_host='主IP',master_port=端口号,master_user='repl',master_password='repl',MASTER_AUTO_POSITION = 1;
start slave ;
【3.4】核验
请查看【一】【5】
三、故障处理
（5.11）mysql高可用系列——复制中常见的SQL与IO线程故障
参考文档：
GTID详解：https://blog.csdn.net/wmq880204/article/details/53160078
GTID详解：https://blog.csdn.net/thundermeng/article/details/50401150