MySQL基於Gtid的主從複製

MySQL基於gtid主從複製

1、Gtid概念

從 MySQL 5.6.5 開始新增了一種基於 GTID 的複製方式。經過 GTID保證了每一個在主庫上提交的事務在集羣中有一個惟一的ID。 這種方式強化了數據庫的主備一致性，故障恢復以及容錯能力。

在原來基於二進制日誌的複製中，從庫須要告知主庫要從哪一個偏移量進行增量同步，若是指定錯誤會形成數據的遺漏，從而形成數據的不一致。藉助GTID，在發生主備切換的狀況下，MySQL的其它從庫能夠自動在新主庫上找到正確的複製位置，這大大簡化了複雜複製拓撲下集羣的維護，也減小了人爲設置複製位置發生誤操做的風險。另外，基於GTID的複製能夠忽略已經執行過的事務，減小了數據發生不一致的風險。

2、什麼是Gitd

GTID (Global Transaction ID) 是對於一個已提交事務的編號，而且是一個全局惟一的編號。 G**TID 實際上 是由
UUID+TID 組成的 。其中 UUID 是一個 MySQL 實例的惟一標識。TID表明了該實例上已經提交的事務數量，而且隨着事務提交單調遞增**。

下面是一個GTID的具體形式：3E11FA47-71CA-11E1-9E33-C80AA9429562:23，冒號分割前邊爲uuid，後邊爲TID。

GTID 集合能夠包含來自多個 MySQL 實例的事務，它們之間用逗號分隔。

若是來自同一MySQL實例的事務序號有多個範圍區間，各組範圍之間用冒號分隔。例如： e6954592-8dba-11e6-af0e-fa163e1cf111:1-5:11-18,e6954592-8dba-11e6-af0e-fa163e1cf3f2:1-27 可使用show master status實時查看當前事務執行數

3、Gtid的做用

Gtid採用了新的複製協議，舊協議是，首先從服務器上在一個特定的偏移量位置鏈接到主服務器上一個給定的二進制日誌文件，而後主服務器再從給定的鏈接點開始發送全部的事件。

新協議有所不一樣，支持以全局統一事務ID (GTID)爲基礎的複製。當在主庫上提交事務或者被從庫應用時，能夠定位和追蹤每個事務。GTID複製是所有以事務爲基礎，使得檢查主從一致性變得很是簡單。若是全部主庫上提交的事務也一樣提交到從庫上，一致性就獲得了保證。

4、Gtid的工做原理

①當一個事務在主庫端執行並提交時，產生GTID，一同記錄到binlog日誌中。
②binlog傳輸到slave,並存儲到slave的relaylog後，讀取這個GTID的這個值設置gtid_next變量，即告訴Slave，下一個要執行的GTID值。
③sql線程從relay log中獲取GTID，而後對比slave端的binlog是否有該GTID。
④若是有記錄，說明該GTID的事務已經執行，slave會忽略。
⑤若是沒有記錄，slave就會執行該GTID事務，並記錄該GTID到自身的binlog，
在讀取執行事務前會先檢查其餘session持有該GTID，確保不被重複執行。
⑥在解析過程當中會判斷是否有主鍵，若是沒有就用二級索引，若是沒有就用所有掃描。

5、配置Gtid

環境：

master主機192.168.1.10
slave主機192.168.1.12

步驟：
①master主配文件

[mysqld]
basedir = /usr/local/mysql
datadir = /usr/local/mysql/data
port = 3306
server_id = 1    #服務器id
socket = /usr/local/mysql/mysql.sock
log-error = /usr/local/mysql/data/mysqld.err
gtid_mode = on    #開啓gtid模式
enforce_gtid_consistency = on    #強制gtid一致性，開啓後對特定的create table不被支持
log-bin = mysql-bin    #開啓二進制日誌
binlog_format = row    #默認爲mixed混合模式，更改爲row複製，爲了數據一致性
log-slave-updates = 1    #從庫binlog纔會記錄主庫同步的操做日誌
skip_slave_start=1    #跳過slave複製線程

②slave主配文件

[mysqld]
basedir = /usr/local/mysql
datadir = /usr/local/mysql/data
port = 3306
server_id = 2
socket = /usr/local/mysql/mysql.sock
log-error=/usr/local/mysql/data/mysqld.err
log-bin = mysql-bin
binlog_format = row
log-slave-updates = 1
gtid_mode = on
enforce_gtid_consistency = on
skip_slave_start=1

③配置slave主機

檢查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

mysql>
CHANGE MASTER TO MASTER_HOST='192.168.1.10',MASTER_USER='myslave',MASTER_PASSWORD='123.com',MASTER_AUTO_POSITION=1;

mysql> show slave status \G;

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.10
                  Master_User: myslave
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 437
               Relay_Log_File: 192-relay-bin.000002
                Relay_Log_Pos: 650
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......

④驗證主從複製
master主機：
mysql> create database test;
Query OK, 1 row affected (0.00 sec)

mysql> use test;
Database changed
mysql> create table tb (id int);
Query OK, 0 rows affected (0.02 sec)

mysql> insert into tb values(1);
Query OK, 1 row affected (0.00 sec)

slave主機：
[root@192 ~]# cd /usr/local/mysql/data/
[root@192 data]# mysqlbinlog mysql-bin.000001 -vv

......
#180411 21:17:50 server id 1  end_log_pos 1216 CRC32 0x9c90f8e6     Write_rows: table id 219 flags: STMT_END_F

BINLOG '
/grOWhMBAAAALQAAAJgEAAAAANsAAAAAAAEABHRlc3QAAnRiAAEDAAGRo2sS
/grOWh4BAAAAKAAAAMAEAAAAANsAAAAAAAEAAgAB//4CAAAA5viQnA==
'/*!*/;
### INSERT INTO `test`.`tb`
### SET
###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
.......

發現master主機插入的數據，已經在slave主機進行了同步，而且啓用了log-bin-updates，在slave主機中的二進制日誌記錄了master主機操做。