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 status\G
*************************** 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 status\G
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：