MySQL傳統主從複製（第二彈）

0、引言

 

GTID是MySQL 5.6 的新特性之一，全稱global transaction identifier全局事務標誌符。GTID官方定義是：

GTID = source_id:transaction_id

source_id：源服務器標識（通常是server_uuid），數據保存在auto.cnf 文件

transaction_id：是一個從 1 開始的自增計數，表示在這個主庫上執行的第 n 個事務，MySQL 會保證事務與 GTID 之間的 1 : 1 映射。

 

server_uuid: mysql 使用128位的server_uuid 替代原先32位的server_id 的大部分功能。 由於server_id依賴於my.cnf的配置，容易產生衝突。自動產生的128位的uuid算法能夠保證全部的uuid都不衝突。首次啓動mysql 會調用generate_server_uuid()函數自動生成一個server_uuid ,並保存到auto.cnf文件中，刪除這個文件，實例下次從新的時候會從新生成。

 

 

1、MySQLGTID複製簡介

 

一、GTID是一個事務一一對應，而且全局惟一ID。

二、一個GTID在一個服務器上只執行一次，避免重複執行致使數據混亂或者主從不一致。

三、它用來代替傳統複製方法，再也不使用MASTER_LOG_FILE+MASTER_LOG_POS開啓複製。而是使用MASTER_AUTO_POSTION=1的方式開始複製。

四、它在MySQL-5.6.5開始支持的，MySQL-5.6.10後開始完善。

五、在傳統的slave端，binlog是不用開啓的，可是在GTID中slave端的binlog是必須開啓的，目的是記錄執行過的GTID（強制）。

六、GTID將主從複製變得簡單化，不須要再找MASTER_LOG_FILE、MASTER_LOG_POS，並且比傳統複製更加安全，由於GTID是連續的，在保證數據一致性方面表現優異

 

 

2、MySQLGTID實現主從同步的原理

 

 

 

一、master上執行和提交一個事務，這個事務被分配一個GTID，這個GTID會放在事務的前面，一同寫入BINLOG

二、當binlog傳輸到slave,並存儲到slave的relay log之後，slave獲取GTID，而後設置到gtid_next變量中.也就是告訴Master,下一個要執行的事務的GTID必定是這個變量中的值.

三、SQL thread從relay log中獲取GTID，並對比slave 的binlog中是否有該GTID，保證GTID在一個服務器上只執行一次，而且禁止多個線程同時執行一個GTID。若是沒有，slave會執行這個GTID，而且將這個GTID和事務一塊兒寫到本身的binlog中。若是有，忽略。

四、若是gtid_next沒有設置，那麼就會自動生成一個新的GTID,這就是爲何GTID要寫在事務的前面

 

 

 

3、MySQLGTID的配置

 

對於想要搭建基於GTID主從的童鞋們，使用mysql-5.6.5以上版本，建議使用最新版本

一、主：

[mysqld]

#GTID:

server_id=135              #服務器id

gtid_mode=on              #開啓gtid模式

enforce_gtid_consistency=on  #強制gtid一致性，開啓後對於特定create table不被支持

在mysql-5.6.9以前,enforce-gtid-consistency對應的是--disable-gtid-unsafe-statements參數.

詳細見：http://dev.mysql.com/doc/refman/5.6/en/replication-options-gtids.html


#binlog

log_bin=mysql-bin

log-slave-updates=1   

binlog_format=row            #強烈建議，其餘格式可能形成數據不一致


#relay log

skip_slave_start=1  

 

二、從：

[mysqld]

#GTID:

gtid_mode=on

enforce_gtid_consistency=on

server_id=143



#binlog

log-bin=slave-binlog

log-slave-updates=1

binlog_format=row      #強烈建議，其餘格式可能形成數據不一致



#relay log

skip_slave_start=1

 

 

4、MySQLGTID主從模式配置

 

1、在新配置的服務器上搭建GTID主從

啓動之後先不要運行事務，而是先change master後，再運行事務

(root@localhost) [(none)]> CHANGE MASTER TO 

    ->  MASTER_HOST='xxxxx',   

    ->  MASTER_USER='xxxx',   

    ->  MASTER_PASSWORD='xxx',   

    ->  MASTER_PORT=xxxx,   

    ->  MASTER_AUTO_POSITION = 1;     

Query OK, 0 rows affected, 2 warnings (0.01 sec)



change master to master_host='10.0.0.6', master_user='root', master_password='123456', master_port=3306, master_auto_position=1;



(root@localhost) [(none)]> start slave;

Query OK, 0 rows affected (0.01 sec)



(root@localhost) [(none)]> show slave status \G ###能夠看到複製工做已經開始且正常

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                 ……

……

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

 

2、基於傳統複製的MySQL轉向GTID複製

a、按本文描述配置參數文件；

b、必定先關閉master的寫入,保證全部的slave都已經和master數據同步。而後在重啓,全部slave須要加上skip_slave_start的配置參數,避免啓勱之後仍是使用老的複製協議.全部服務器設置global.read_only參數，等待主從服務器同步完畢；

mysql> SET @@global.read_only = ON;

c、依次重啓主從服務器；

d、使用change master 更新主從配置；

mysql> CHANGE MASTER TO

     > MASTER_HOST = xxxx,

     > MASTER_PORT = xxxx,

     > MASTER_USER = xxxx,

     > MASTER_PASSWORD = xxxx,

     > MASTER_AUTO_POSITION = 1;

 

e、從庫開啓複製

mysql> START SLAVE;

f、驗證主從複製

 

 

5、搭建基於MySQL GTID的從庫

 

兩種方式：

一、若是你的master全部的binlog還在,能夠選擇相似於剛纔的方法,安裝slave後,直接change master到master。原理是直接獲取master全部的gtid並執行。

優勢：是簡單

缺點：是若是binlog太多,數據徹底同步須要的時間較長,而且master一開始就啓用了GTID

總結：適用於master也是新建不久的狀況。

 

二、經過master或者其餘slave的備份搭建新的slave.

原理：獲取master的數據,和這些數據對應的GTID範圍,而後經過在slave設置@@GLOBAL.GTID_PURGED從而跳過備份包含的GTID

優勢：是能夠避免第一種方法中的不足

缺點：是相對來講會複雜一點點

總結：適用於擁有較大數據集的狀況

 

三、經過mysqldump搭建基於GTID的從庫

 

 

l  備份從庫

[root@bogon ~]# mysqldump -h10.0.0.7 -uroot -p123456 --master-data=2 --triggers --routines --events --single-transaction --all-databases >all.sql

若是主從不是一個版本，從master上備份到salve，啓動實例後，應該再執行mysql_upgrade升級相關表結構performance_schema、information_schema以及mysql等系統表結構。

此時報錯

[root@bogon ~]# mysql <all.sql

ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

l  在slave上執行

root@localhost [(none)]>show variables like 'gtid_purged';

+---------------+--------------------------------------------+

| Variable_name | Value                                      |

+---------------+--------------------------------------------+

| gtid_purged   | 60b08d3b-9c23-11e6-81c2-000c29d40ed7:1-605 |

+---------------+--------------------------------------------+

1 row in set (0.00 sec)

l  在master上執行

root@localhost [(none)]>show master status;

+------------------+----------+--------------+------------------+--------------------------------------------+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                          |

+------------------+----------+--------------+------------------+--------------------------------------------+

| mysql-bin.000001 |  7527969 |              |                  | 60b08d3b-9c23-11e6-81c2-000c29d40ed7:1-605 |

+------------------+----------+--------------+------------------+--------------------------------------------+

(END)

l  在新的slave上執行

root@localhost [(none)]>reset master;

Query OK, 0 rows affected (0.01 sec)



root@localhost [(none)]>SET GLOBAL gtid_purged='60b08d3b-9c23-11e6-81c2-000c29d40ed7:1-605';

Query OK, 0 rows affected (0.01 sec)

l  鏈接到主

root@localhost [(none)]>change master to master_host='10.0.0.6', master_user='root', master_password='123456', master_port=3306, master_auto_position=1;

Query OK, 0 rows affected, 2 warnings (0.13 sec)



root@localhost [(none)]>start slave;

Query OK, 0 rows affected (0.01 sec)



root@localhost [(none)]>show slave status\G

l  校驗數據一致性

 

四、用xtrabackup搭建基於GTID的從庫

l  在主上作：

[root@bogon ~]# innobackupex --user=root --password=123456 --defaults-file=/data/etc/my.cnf --socket=/home/work/mysql/tmp/mysql.sock /home/dbbackup/        

l  在從上作：

[root@bogon ~]# innobackupex --copy-back --user=root --password=123456 /data/test/test/2016-12-13_23-05-52/

l  重啓slave reset master;

如果在slave作xtrabackup，要注意GTID範圍

l  從新鏈接

change master to master_host='10.0.0.6', master_user='root', master_password='123456', master_port=3306, master_auto_position=1;

l  校驗數據一致性

 

 

PS：很是抱歉，本文是做者前面整理的，當時沒有記錄參考文檔，再次向原創做者說聲抱歉。

爲了方便你們交流，本人開通了微信公衆號，和QQ羣291519319。喜歡技術的一塊兒來交流吧