基於GTID的復制
簡介
基於GTID的復制是MySQL 5.6后新增的復制方式.
GTID (global transaction identifier) 即全局事務ID, 保證了在每個在主庫上提交的事務在集群中有一個唯一的ID。
在原來基於日志的復制中, 從庫需要告知主庫要從哪個偏移量進行增量同步, 如果指定錯誤會造成數據的遺漏, 從而造成數據的不一致.
而基於GTID的復制中, 從庫會告知主庫已經執行的事務的GTID的值, 然后主庫會將所有未執行的事務的GTID的列表返回給從庫. 並且可以保證同一個事務只在指定的從庫執行一次。
GTID開啟配置如下:
SHOW VARIABLES LIKE '%GTID%';
結果:

實戰
1、在主庫上建立復制賬戶並授予權限
基於GTID的復制會自動地將沒有在從庫執行的事務重放, 所以不要在其他從庫上建立相同的賬號. 如果建立了相同的賬戶, 有可能造成復制鏈路的錯誤.
注意在生產上的密碼必須依照相關規范以達到一定的密碼強度, 並且規定在從庫上的特定網段上才能訪問主庫.
查看用戶
查看授權
2、配置主庫服務器
NOTE: 把日志與數據分開是個好習慣, 最好能放到不同的數據分區
enforce_gtid_consistency 強制GTID一致性, 啟用后以下命令無法再使用:
1、create table ... select ...
因為實際上是兩個獨立事件, 所以只能將其拆分先建立表, 然后再把數據插入到表中。
2、事務內部不能創建臨時表create temporary table
mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> create temporary table dept(id int); 錯誤代碼: 1787 When @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1, the statements CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can be executed in a non-transactional context only,
and require that AUTOCOMMIT = 1. These statements are also not allowed in a function or trigger because functions and triggers are also considered to be multi-statement transactions.
上面的錯誤中提到,當事務是自動提交的,是可以執行的,如下:

同一事務中更新事務表與非事務表(MyISAM)
mysql> CREATE TABLE `dept_innodb` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT); Query OK, 0 rows affected (0.04 sec) mysql> CREATE TABLE `dept_myisam` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT) ENGINE = `MyISAM`; Query OK, 0 rows affected (0.03 sec) mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> insert into dept_innodb(id) value(1); Query OK, 1 row affected (0.00 sec) mysql> insert into dept_myisam(id) value(1); ERROR 1785 (HY000): Statement violates GTID consistency: Updates to non-transactional tables can only be done in either autocommitted statements or single-statement transactions, and never in the same statement as updates to transactional tables.
所以建議選擇Innodb作為默認的數據庫引擎。
log_slave_updates 該選項在MySQL 5.6版本時基於GTID的復制是必須的, 但是其增大了從服務器的IO負載, 而在MySQL 5.7中該選項已經不是必須項。
3、配置從庫服務器
master_info_repository 與relay_log_info_repository
在MySQL 5.6.2之前, slave記錄的master信息以及slave應用binlog的信息存放在文件中, 即master.info與relay-log.info. 在5.6.2版本之后, 允許記錄到table中. 對應的表分別為mysql.slave_master_info與mysql.slave_relay_log_info, 且這兩個表均為innodb引擎表.
4、從庫數據初始化 - [optional]
先在主庫上備份數據
mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases --events -u root -p > backup.sql
—master-data=2 該選項將當前服務器的binlog的位置和文件名追加到輸出文件中(show master status). 如果為1, 將偏移量拼接到CHANGE MASTER 命令. 如果為2, 輸出的偏移量信息將會被注釋。
--all-databases 因為基於GTID的復制會記錄全部的事務, 所以要構建一個完整的dump這個選項是推薦的
常見錯誤
當從庫導入SQL的時候出現
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
此時進入從庫的MySQL Command Line, 使用reset master即可
5、啟動基於GTID的復制
現有master@172.20.0.2和slave@172.20.0.3, 並且已經通過mysqldump將數據同步至從庫slave中. 現在在從服務器slave上配置復制鏈路
啟動復制
啟動成功后查看slave的狀態
當Slave_IO_Running, Slave_SQL_Running為YES,
且Slave_SQL_Running_State 為Slave has read all relay log; waiting for more updates時表示成功構建復制鏈路。
6、總結
優點
- 因為不用手工設置日志偏移量, 可以很方便地進行故障轉移
- 如果啟用log_slave_updates那么從庫不會丟失主庫上的任何修改
缺點
- 對執行的SQL有一定限制
- 僅支持MySQL 5.6之后的版本, 而且不建議使用早期5.6版本
