一、什麼是GTID？
GTID(Global Transaction Identifiers)是全局事務標識
當使用GTIDS時，在主上提交的每一個事務都會被識別和跟蹤，並且運用到所有從MySQL，而且配置主從或者主從切換時不再需要指定 master_log_files和master_log_pos；由於GTID-base複製是完全基於事務的，所以能很簡單的決定主從複製的一致性；官方建議Binlog採用Row格式
二、GTID的表示方式
source_id：transaction_id
source_id：表示執行事務的主庫的UUID(server_uuid:Mysql5.6的data目錄下啓動時會生成auto.cnf文件記錄了uuid，重啓後uuid不變，刪除文件後會重新生成新的uuid)；
transaction_id：是一個從1開始自增的計數，表示在這個主庫上執行的第n個事務；
由於每臺Mysql的uuid是全球唯一的，transaction_id自身唯一，就保證了GTID全局唯一性
| mysql> show variables like 'server_uuid'; +---------------+--------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------+ | server_uuid | 4468c0e8-ef6f-11e3-9c2c-0200c0a80ad8 | +---------------+--------------------------------------+ 1 row in set (0.00 sec) |
三、基於GTID的複製配置
master：192.168.10.216
slave ：192.168.10.217
步驟：
修改主從my.cnf增加GTID支持—>主只讀—>拷貝數據到從數據目錄—>重啓主從—>在從上進行配置
1.修改主從my.cnf增加GTID支持
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
主Mysql配置：
server-id=216
binlog-format=ROW
gtid-mode=on
enforce-gtid-consistency=true
log-bin=mysql-bin
log-slave-updates=true
slave更新是否記入日誌
從Mysql配置：
server-id=217
同一個複製拓撲中的所有服務器的id號必須惟一
binlog-format=ROW
gtid-mode=on 啓用gtid類型，否則就是普通的複製架構
enforce-gtid-consistency=true
強制GTID的一致性
log-bin=mysql-bin
log-slave-updates=true
slave更新是否記入日誌
只從庫配置：
slave-paralles-workers
設定從服務器的SQL線程數；0表示關閉多線程複製功能；
|
2.主只讀
| mysql> SET @@global.read_only = ON; |
拷貝主數據到從目錄
3.重啓主從Mysql
4.在從上配置基於GTID的複製
|
|
mysql>
CHANGE
MASTER
TO
>
MASTER_HOST
=
‘192.168.10.216’,
>
MASTER_PORT
=
3306,
>
MASTER_USER
=
'rep',
>
MASTER_PASSWORD
=
'geekwolf',
>
MASTER_AUTO_POSITION
=
1;
|
5.啓動從庫
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 | mysql> start slave; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.10.216 Master_User: rep Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 41921904 Relay_Log_File: relay-bin.000002 Relay_Log_Pos: 64520 Relay_Master_Log_File: mysql-bin.000002 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: mysql.% Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 41921904 Relay_Log_Space: 64718 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: 216 Master_UUID: 21ad8db5-f038-11e3-a14a-0200c0a80ad8 Master_Info_File: /usr/local/mysql/data/master.info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Reading event from the relay log Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 21ad8db5-f038-11e3-a14a-0200c0a80ad8:76793-77026 Executed_Gtid_Set: 21ad8db5-f038-11e3-a14a-0200c0a80ad8:1-77025 Auto_Position: 1 1 row in set (0.00 sec) |
注：
兩個Yes代表複製正常
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
基於GTID複製的新特性：
Retrieved_Gtid_Set: 21ad8db5-f038-11e3-a14a-0200c0a80ad8:76793-77026
Executed_Gtid_Set: 21ad8db5-f038-11e3-a14a-0200c0a80ad8:1-77025
Retrieved_Gtid_Set項：記錄了relay日誌從Master獲取了binlog日誌的位置
Executed_Gtid_Set項：記錄本機執行的binlog日誌位置（如果是從機，包括Master的binlog日誌位置和slave本身的binlog日誌位置）
四、基於GTID複製增加新的slave
備份主MySQL數據，記錄主gtid_executed—>將備份數據恢復到從數據目錄—>設置從gtid_purged的值爲主的gtid_executed值—>啓動複製即可
1.使用mysqldump備份主數據
mysqldump —all-databases —single-transaction —triggers —routines —host=127.0.0.1 —port=3306 —user=root —password=geekwolf > backup.sql
亦可以使用xtrabackup也支持GTID：
請參考:http://www.mysqlperformanceblog.com/2013/05/09/how-to-create-a-new-or-repair-a-broken-gtid-based-slave-with-percona-xtrabackup/
2.傳到從MySQL，恢復數據
由於新版本msqldump會記錄並設置GTID_PURGED的值等於主的GTID_EXECUTED，所以只需要將sql導入到從庫即可
3.啓動主從複製
|
|
從庫執行
mysql
>
CHANGE
MASTER
TO
MASTER_HOST='127.0.0.1',
MASTER_USER='root',
MASTER_PASSWORD=geekwolf',
MASTER_PORT=3306,
MASTER_AUTO_POSITION
=
1;
mysql
>
START
SLAVE;
|
五、基於GTID複製出錯的解決辦法
問題:
| Slave_IO_Running: No Slave_SQL_Running: Yes Last_IO_Error: 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.' |
解決思路:
從複製跳過已經丟失的binlog，繼續複製或者重新做主從（可以參考上面的操作）
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
主MySQL：
mysql>
show
global
variables
like
'%gtid_executed%';
+---------------+-----------------------------------------------+
|
Variable_name
|
Value
|
+---------------+-----------------------------------------------+
|
gtid_executed
|
21ad8db5-f038-11e3-a14a-0200c0a80ad8:1-223937
|
+---------------+-----------------------------------------------+
1
row
in
set
(0.00
sec)
從MySQL：
mysql>
set
global
GTID_PURGED="21ad8db5-f038-11e3-a14a-0200c0a80ad8:1-223937";
ERROR
1840
(HY000):
@@GLOBAL.GTID_PURGED
can
only
be
set
when
@@GLOBAL.GTID_EXECUTED
is
empty.
mysql>
reset
master;
Query
OK,
0
rows
affected
(0.19
sec)
mysql>
show
global
variables
like
'GTID_EXECUTED';
+---------------+-----------------------------------------------+
|
Variable_name
|
Value
|
+---------------+-----------------------------------------------+
|
gtid_executed
| |
+---------------+-----------------------------------------------+
1
row
in
set
(0.00
sec)
mysql>
stop
slave;
Query
OK,
0
rows
affected,
1
warning
(0.00
sec)
mysql>
set
global
GTID_PURGED="21ad8db5-f038-11e3-a14a-0200c0a80ad8:1-223937";
Query
OK,
0
rows
affected
(0.13
sec)
mysql>
start
slave;
Query
OK,
0
rows
affected
(0.04
sec)
mysql>
show
slave
status\G
[...]
Slave_IO_Running:
Yes
Slave_SQL_Running:
Yes
[...]
|
注意事項：
使用基於GTID複製時，不需要再關心master_log_file和master_log_pos，替代的是隻需要知道master上的GTID，並且配置在從上即可；
記錄GTID的有兩個全局變量：gtid_executed和gtid_purged
與GTID複製相關的參數：
![gtid]()
GTID_EXECUTED ：表示已經在該實例上執行過的事務；執行RESET MASTER可以置空該參數；也可以設置GTID_NEXT執行一個空事務來影響GTID_EXECUTED
GTID_NEXT ：是SESSION級別參數，表示下一個事務被執行使用的GTID（show variables like ‘gtid_%’;）
GTID_PURGED ：表示被刪除的binlog事務GTID，它是GTID_EXCUTED的子集，MySQL5.6.9，該參數無法被設置
GTID_OWENED ：表示正在執行的事務的GTID以及對應的線程ID
如果設置MASTER_AUTO_POSITION = 1表示主從複製連接使用基於GTID的方式複製
| CHANGE MASTER TO MASTER_HOST='192.168.10.216',MASTER_USER='rep',MASTER_PASSWORD='geekwolf',MASTER_AUTO_POSITION=1; |
如果在GTID複製模式下想要使用基於文件的複製協議需要MASTER_AUTO_POSITION=0（至少指定其中MASTER_LOG_FILE、MASTER_LOG_POSITION一個）
|
|
CHANGE
MASTER
TO
MASTER_HOST='192.168.10.216',MASTER_USER='rep',MASTER_PASSWORD='geekwolf',MASTER_LOG_FILE='mysql-bin.000002',MASTER_LOG_POS=120,MASTER_AUTO_POSITION=0;
|
參考文檔：
MYSQL 5.6 GTID-based Replication
MYSQL 5.6 GTID模式下手工刪除日誌導致備庫數據丟失
How
to create a new (or repair a broken) GTID based slave with Percona XtraBackup
