Mysql 5.6 GTID-主從搭建

時間 2019-11-11

標籤 mysql 5.6 gtid 主從搭建欄目 MySQL 简体版

原文原文鏈接

GTID做爲mysql5.6帶來的新特性，在搭建replicate過程當中，能夠更快速方便，感受上更加‘自動化’。 #1、修改配置文件mysql

###1.修改主服務器配置文件my.cnf，添加下面的幾行：linux

binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log-events=1
server-id=1
report-port=3306
port=3306
log-bin=black-bin.log
report-host=black
innodb_flush_log_at_trx_commit=1
sync_binlog=1

###2.修改從服務器配置文件，添加下面幾行：sql

binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log-events=1
server-id=2
report-port=3307
port=3307
log-bin=blue-bin.log
report-host=blue
innodb_flush_log_at_trx_commit=1
sync_binlog=1

能夠看到主與從的配置文件基本上是相同的，這樣也便於在主服務器掛掉的時候，不用修改配置文件便可把從服務器提高爲主。數據庫

#2、在master上建立用戶安全

mysql> create user 'rep'@'%' identified by 'rep';
mysql> grant replication slave on *.* to 'rep'@'%';

#3、從master導出數據服務器

###1.master中設置全部表只讀：網絡

mysql> FLUSH TABLES WITH READ LOCK;

###2.用mysqldump導出所有數據：多線程

->/usr/local/mysql/bin/mysqldump -uroot -p -h192.168.1.10 -P3306 --all-databases --triggers --routines --events >all.sql

###3.解鎖表格：併發

mysql> UNLOCK TABLES;

###4.slave導入數據異步

-> mysql -uroot -p -h192.168.1.11 -P3307 < all.sql

###5.change master mysql > CHANGE MASTER TO MASTER_HOST='192.168.1.9', MASTER_PORT=3306, MASTER_USER='rep',MASTER_PASSWORD='rep', master_auto_position=1; mysql > SHOW warnings; +-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Level | Code |Message | +-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Note | 1759 | Sending passwords IN plain text WITHOUT SSL/TLS IS extremely insecure. | | Note | 1760 | Storing MySQL USER name OR password information IN the master.info repository IS NOT secure AND IS therefore NOT recommended. Please see the MySQL Manual FOR more about this issue AND possible alternatives. | +-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 2 ROWS IN SET (0.00 sec)

這裏保存的是明文密碼，存在密碼泄露的風險。

mysql > SELECT * FROM mysql.slave_master_info \G； 
mysql > SELECT * FROM mysql.slave_relay_log_info \G；

mysql > START slave;
mysql  > SHOW warnings;
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                                                                                               |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note  | 1753 | slave_transaction_retries IS NOT supported IN multi-threaded slave mode. IN the event OF a transient failure, the slave will NOT retry the TRANSACTION AND will stop. |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 ROW IN SET (0.00 sec)

多線程模式掉線不重連。

從服務器上看一下狀態：

mysql > SHOW slave STATUS \G;
*************************** 1. ROW ***************************
               Slave_IO_State: Waiting FOR master TO send event
                  Master_Host: 127.0.0.1
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: black-bin.000001
          Read_Master_Log_Pos: 1770
               Relay_Log_File: mysql_sandbox5611-relay-bin.000002
                Relay_Log_Pos: 1980
        Relay_Master_Log_File: black-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: 1770
              Relay_Log_Space: 2196
              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: 1
                  Master_UUID: 05b47d41-7b10-11e2-9fff-00241db92e69
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has READ ALL relay log; waiting FOR the slave I/O thread TO UPDATE it
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 05b47d41-7b10-11e2-9fff-00241db92e69:1-6
            Executed_Gtid_Set: 05b47d41-7b10-11e2-9fff-00241db92e69:1-6
                Auto_Position: 1
1 ROW IN SET (0.00 sec)

主服務器上面也能夠看到一些信息：

mysql > SHOW master STATUS;
+------------------+----------+--------------+------------------+------------------------------------------+
| File             | POSITION | Binlog_Do_DB | Binlog_Ignore_DB |     Executed_Gtid_Set                        |
    +------------------+----------+--------------+------------------+------------------------------------------+
| black-bin.000001 |     1770 |              |                  | 05b47d41-7b10-11e2-9fff-00241db92e69:1-6 |
    +------------------+----------+--------------+------------------+------------------------------------------+
1 ROW IN SET (0.00 sec)


mysql  > SHOW slave hosts;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID                           |
+-----------+------+------+-----------+--------------------------------------+
|         2 | blue | 3306 |         1 | 1d1e71e7-7b10-11e2-9fff-00241db92e69 |
+-----------+------+------+-----------+--------------------------------------+
1 ROW IN SET (0.00 sec)

#4、配置文件參數含義：

###1.binlog-format：

採用了row-based，聽說5.6對row-based replication作了優化。

###2.gtid-mode與enforce-gtid-consistency：

傳統方式下，主從是基於master binary logfile 與 binary logfile postition的， 當主服務器掛掉，須要把某個從服務器提高爲主的時候，須要作不少工做， 主要緣由仍是在於主從複製實際上是異步的， 致使多臺從服務器間的數據不一致，有的同步速度快，有的速度慢, 頗有可能每一臺從服務器上面的Read_Master_Log_Pos都是不一樣的。 首先要根據Read_Master_Log_Pos來肯定每臺從服務器缺乏binlog中的哪些transactions(events)，幫它們補充完以後， 從服務器間的數據徹底一致了，而後才能把任意一臺從服務器提高爲主。 這個過程，人工作起來實在是比較痛苦，還好有一些開源的第三方程序能夠自動作到，好比MHA。爲了從根本上解決這個問題，gtid(Global Transaction ID)就被開發了出來。mysql爲每個transactions都生成了獨一無二的ID，由二部分構成：
    1) mysql服務器的128bit的UUID
    2) 自增的一個int變量。 此服務器的第一個transaction的id就是1，第二個就是2…
好比： 22096C54-FE03-4B44-95E7-BD3C4400AF21:4711這樣GTID就能夠在全局範圍內惟一標識一個transaction。GTID也會寫入binary log，而後被傳輸到從服務器。有了GTID，主從複製也再也不基於master的binary logfile和logfile postition，從服務器鏈接到主服務器以後，把本身執行過的GTID(Executed_Gtid_Set) 曾經獲取到的GTID(Retrieved_Gtid_Set)發給主服務器，主服務器把從服務器缺乏的GTID及對應的transactions發過去便可。當主服務器掛掉的時候，能夠任意選擇一臺從服務器直接提高爲主，而後其它從服務器鏈接到新的主服務器以後，首先把自已已經執行過的GTID發給新主服務器，新主根據這些GTID，判斷本身缺乏哪些transactions，先把本身補全，而後再把從服務器缺乏的GTID及對應的transactions發給從服務器。另外，gtid與myisam的關係，也不是很明確。master-info-repository與relay-log-info-repository都設置爲TABLE， 默認值是FILE, 好比master info就保存在master.info文件中，relay log info保存在relay-log.info文件中，若是服務器意外關閉，正確的relay info 沒有來得及更新到 relay-log.info文件中，那就比較悲劇了。

###3.mysql.slave_master_info與 mysql.slave_relay_log_info：

這二個table都是innodb類型的， 天生就支持事務，比寫文件靠譜多了。

###4.sync-master-info：

若是這個值大於0的話，複製中的slave機器就會在每次sync_master_info事件完成後同步它的master.info信息到對應的磁盤文件中。

###5.slave-parallel-workers：

5.6之前的從服務器，有一個io線程負責接收binary log，還有一個sql線程負責執行binary log中的sql語句。若是主服務器的數據更新至關頻繁，而從服務器通常來講硬件性能要低於主服務器，若是隻有一個sql線程的話，萬一某條語句執行速度過慢，就卡在這裏了，會致使從服務器落後比較長的時間。採用多個sql線程，每一個sql線程處理不一樣的database，提升了併發性能，即便某database的某條語句暫時卡住，也不會影響到後續對其它的database進行操做。
ps:若是隻有一個database要同步，那麼多個sql線程也沒有什麼意義。
ps2: show slave status裏面的Exec_Master_Log_Pos，在多個sql線程的狀況下，變爲一個低水位線標識，並不是表示最近執行到的pos。
ps3: START SLAVE UNTIL SQL_AFTER_MTS_GAPS; 能夠保證sql thread執行完relay log中所有的語句，而後自動stop slave。若是要把slave-parallel-workers的值從非0改成0(切換回單sql線程)，須要這樣作：
START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.slave_parallel_workers = 0;
START SLAVE SQL_THREAD;

###6.binlog-checksum=CRC32，master-verify-checksum=1，slave-sql-verify-checksum=1：

這也是新特性，有了checksum, 若是binlog文件在master上損壞，或者在網絡傳輸時損壞，或者保存到slave的時候損壞，都能自動檢測出來。

###7.binlog-rows-query-log-events：

只對row-based binlog有效。enable以後，會向binlog中寫入更多的調試信息，好比sql語句自身都會被寫進去。 mysqlbinlog -vv 能夠看到。

###8.innodb_flush_log_at_trx_commit=1 與 sync_binlog=1：

這兩個參數在mysql數據庫調優中有着很重要的做用，當你的mysql數據庫性能不好時，你應該在排除完硬件問題後，首先檢查這兩個參數設置的是否合適。

innodb_flush_log_at_trx_commit分別能夠設置成三個數值：0、一、2。
值爲0表示每一秒鐘將內存中的數據寫入log_buff中，操做系統每秒鐘將buffer中的數據寫入硬盤中，這樣作讀寫性能最優，可是安全性最差。
值爲1表示每次事務提交時，將內存中的數據寫入log_buffer中同時將數據實時落盤即寫入硬盤中，這樣數據安全性最高，可是性能最差。
值爲2表示內存中的數據在每次提交後，被寫入log_buffer中，而操做系統每隔一秒中，將buffer中數據寫入硬盤，這中作法能夠看做是安全和性能的折中選擇。當機器宕機或者掉電後，若是你的raid卡是帶電池的話，最後一秒鐘的buffer數據是不會丟失的。

mysql中這個默認值爲1.

sync_binlog能夠設置爲0、1或者N三種數值。
值爲0，表示不主動作log刷盤動做，即由文件系統決定什麼時候將binlog_cache中的數據寫入硬盤中，或者只有在binlog_cache滿了以後纔會寫入磁盤。0爲默認值。
值爲1，表示每次事務提交後，就將cache中的日誌數據寫入文件中，這樣安全性最高，可是性能最差。
值爲N,表示沒N次事務提交後，進行數據刷盤動做。N的值能夠根據本身的業務狀況進行選擇。

參考文章：http://www.linuxidc.com/Linux/2013-04/82712.htm