一、主从复制
1.）普通主从复制：
普通主从复制主要是基于二进制日志文件位置的复制，因此主必须启动二进制日志记录并建立唯一的服务器ID，复制组中的每个服务器都必须配置唯一的服务器ID。如果您省略server-id（或者明确地将其设置为其默认值0），则主设备将拒绝来自从设备的任何连接。
2.） GTID 主从：
（1.）基本概念
MySQL 5.6 的新特性之一，全局事务标识符（GTID）是创建的唯一标识符，并与在源（主）服务器上提交的每个事务相关联。此标识符不但是唯一的，而且在给定复制设置中的所有服务器上都是唯一的。所有交易和所有GTID之间都有一对一的映射关系 。它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
一个GTID被表示为一对坐标，用冒号（:）分隔，如下所示：GTID = source_id:transaction_id，source_id标识的源服务器。通常情况下，服务器 server_uuid用于这个目的。这transaction_id是一个序列号，由在此服务器上提交事务的顺序决定 .
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
在传统的主从复制slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。GTID用来代替classic的复制方法，不在使用binlog+pos开启复制。而是使用master_auto_postion=1的方式自动匹配GTID断点进行复制。
mysql的主从复制是十分经典的一个应用，但是主从之间总会有数据一致性（data consistency ）的问题，一般情况从库会落后主库几个小时，而且在传统一主多从(mysql5.6之前)的模型中当master down掉后，我们不只是需要将一个slave提成master就可以，还要将其他slave的同步目的地从以前的master改成现在master，而且bin-log的序号和偏移量也要去查看，这是十分不方便和耗时的，但mysql5.6引入gtid之后解决了这个问题。
红色代表GTID，绿色代表传统主从：
（2.）GTID的工作原理：
1、当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。 2、binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。 3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。 4、如果有记录，说明该GTID的事务已经执行，slave会忽略。 5、如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog， 在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。 6、在解析过程中会判断是否有主键，如果有就用二级索引，如果没有就用全部扫描。
二、GTID参数配置
1、主master：
[mysqld] #GTID: server_id=1 #服务器id gtid_mode=on #开启gtid模式 log_slave_updates ## 表示即可以当从也可以当主 enforce_gtid_consistency=on #强制gtid一致性，开启后对于特定create table不被支持 #binlog log_bin=master-binlog
#log-bin=/data/mysql/mysql-bin.log //binlog日志文件,(文件名如果是绝对路径,必须指定索引文件)
#log_bin_index = /var/lib/mysql/mysql-bin.index //是binlog文件的索引文件，这个文件管理了所有的binlog文件的目录
log-slave-updates=1
binlog_format=row #binlog日志格式，强烈建议，其他格式可能造成数据不一致
expire_logs_days=7 //binlog过期清理时间
#relay logskip_slave_start=1
2、从slave：
与主的配置没有区别，仅仅只是server_id不一致。
三、配置主从
1.）master:
创建并授权salve远程访问的用户：
GRANT REPLICATION SLAVE ON *.* TO root@192.168.50.28 IDENTIFIED BY '123456';
flush privileges;
查看授权slave用户表：
show grants for user@localhost;
查看binlog信息：show master status;
2.）GTID—slave;（注意：GTID主从必须启用MASTER_AUTO_POSITION而且不能跟bin与pos同时配置。）
CHANGE MASTER TO MASTER_HOST='192.168.50.116',MASTER_PORT=3306,MASTER_USER='root',MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
start slave;
show slave statusG;
#MASTER_AUTO_POSITION： （mysql5.6.5及其后续版本）进行change master to时使用MASTER_AUTO_POSITION = 1，slave连接master将使用基于
GTID的复制协议。等于0则恢复到老的文件复制协议。
3.）传统复制—slave配置;（这里的bin与pos根据实际情况更换）
CHANGE MASTER TO MASTER_HOST='192.168.50.116',MASTER_PORT=3306,MASTER_USER='root',MASTER_PASSWORD='123456', master_log_file='mysql-bin.000003',master_log_pos=308;
start slave;
show slave statusG;
关键：在配置文件中启用GTID的情况下，change语句才是决定启用GTID还是传统主从的关键。
进行主备切换的时候，一般都会先对主库进行只读操作(on)，然后主备同步完成后，再把备库置为可读写(off)。这样可以避免切换的过程中双写引起脏数据。：set global read_only=on/off
四、特殊情况下，需要重置主从
stop slave;
reset slave all; #重置全部的从信息
reset master; #重置主
五、事物跳过（传统与GTID的跳过方法不同）
1.传统
set global sql_slave_skip_counter = 1;
#可以忽略N个事件（event），通常一个SQL是一个事件。
2.GTID跳过事务冲突
首先，我们需要先查看当前SLAVE复制的进度：SHOW SLAVE STATUSG
Retrieved_Gtid_Set:aaa-bbb-ccc-ddd:N （表示收到的事务）
Executed_Gtid_Set:aaa-bbb-ccc-ddd:N （表示已经执行完的事务）
看Executed_Gtid_Set 到了31这个事务GTID位置，在这下一个位置（32）上发生错误。这时候，我们需要手工调整SLAVE已清除的GTID列表 GTID_PURGED，人为通知SLAVE哪些事务已经被清除了，后续可以忽略：
STOP SLAVE; RESET MASTER; SET @@GLOBAL.GTID_PURGED = “3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-32”; START SLAVE;
上面这些命令的用意是，忽略 f2b6c829-9c87-11e4-84e8-deadeb54b599:32 这个GTID事务，下一次事务接着从 33 这个GTID开始，即可跳过上述错误。
从服务器上负责同步的有二类线程: 1) IO thread 2) SQL thread
Slave_IO_Running:从服务器正从主服务器上读取BINLOG日志,并写入从服务器的中继日志.
Slave_SQL_Running:进程正在读取从服务器的BINLOG中继日志，并转化为SQL执行
IO thread 决定了Retrieved_Gtid_Set
SQL thread 决定了Executed_Gtid_Set
IO thread负责获取master上的binary log, 然后多个sql threads负责执行。由于IO thread先于SQL thread，Retrieved_Gtid_Set可能会略多于Executed_Gtid_Set。比如： SHOW slave STATUS G
....... ....... Retrieved_Gtid_Set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-9 Executed_Gtid_Set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-7 Auto_Position: 1
1.）注入空事务：
stop slave; SET GTID_NEXT='aaa-bbb-ccc-ddd:N'; #要想跳过错误的GTID或则是想要跳过的GTID，就需要指定下一个事物的执行版本 BEGIN; COMMIT; #注入一个空事务 SET GTID_NEXT='AUTOMATIC'; #自动寻找GTID事务 一旦所有事务标识符以这种方式使用空事务恢复后，您必须刷新并清除从属服务器的二进制日志，如下所示，其中 N是当前二进制日志文件名称 的非零后缀；或者reset slave; FLUSH LOGS; PURGE BINARY LOGS TO 'master-bin.00000N'; start slave;
2.）重置master方法跳过错误
mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> SET @@GLOBAL.GTID_PURGED ='8f9e146f-0a18-11e7-810a-0050568833c8:1-4'
mysql> START SLAVE;
注意：在GTID主从的建立初期，slave的数据一定要是从master mysqldump过去的并且更加--all-databases参数。否则手动补齐的数据会出现slave_sql_running为NO的情况，这是因为主的操作记录会保存在GTID与binlog中，然后slave会同步主的GTID与binlog并进行相应的操作，这时两边的数据虽然是一致的，但是同步过来master的GTID中包含了主做过的一些sql操作，而此时slave的环境不满足sql语句的执行就会冲突。解决办法是：1.）不断的执行跳过事务的操作直到没有报错。2.）刷新master的GTID“reset master”然后重新再slave执行change同步。
六、报错案例：
1.）
2017-10-12T09:59:27.660287Z 4 [ERROR] Slave I/O for channel '': Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work. Error_code: 1593
解决方法：
如果是copy的data目录可能会出现这个错，将data目录里auto.cnf 文件中的uuid改为与master不一样的即可。
2.）传统主从
2017-10-12T10:09:15.365312Z 4 [ERROR] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file', Error_code: 1236
解决办法：
是因为找不到master的二进制文件，查看master的binlog二进制文件、pos位置是否与slave相同，不相同关闭salve并在slave执行CHANGE MASTER TO MASTER_LOG_FILE='mysqld-bin.000011',MASTER_LOG_POS=106;更改，然后开启start slave;并进行查看show slave statusG
3.） GTID主从
Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
解决办法：忽略purged的部分，强行同步
master确认已经purge的部分：show global variables like '%gtid%';
stop slave，在slave上通过set global gtid_purged='xxxx'的方式，跳过已经purge的部分
4.）
主从不同步，但slave显示双yes，日志无报错问题。
这个解决方法是下下策，我不知道不同步的原因是什么，如果有知道的T友，请评论告知。
重置主从：reset master reset slave
备份主的全库到slave：
mysqldump -h 192.168.50.116 -uroot -p123456 --all-databases --skip-lock-tables --set-gtid-purged=off > qk.sql
然后从导入：mysql -uroot -p123456 <aaa.sql
导入时若提示：ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.则在本地执行reset master即可。导入成功后重新开启slave同步，如若slave需要重新挂载在master端，则执行命令change时忽略MASTER_AUTO_POSITION即可。
注意：
开启主从复制之后，就不可以在从的上面进行操作，否则会出现slave_sql_running为NO的提示。
当已经在从库进行删除或则添加数据时，挽救的方法就是关闭slave，然后将删除的数据创建回来或将添加的数据删除，目的是为了与master一致，然后开启slave。最好是将从库设置为只读模式，但是无法对super的用户起效。
5.）
Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
解决办法：
这类报错往往是因为master清除了相关的GTID事务导致无法同步的。通常是因为从库因为某些原因需要重新接受master的GTID事务，比如像slave导入备份重新指向master。这时就需要在master执行：show global variables like '%gtid%'; 找出被purged的条目，然后再slave执行本文中 “GTID跳过事务冲突”的步骤即可。
优秀文章分享：
http://www.cnblogs.com/luckcs/articles/6295992.html
http://blog.csdn.net/leshami/article/details/50630691