歡迎光臨
每天分享高質量文章

例證MySQL GTID與MariaDB GTID的不同之處

關註獲得更多內容

精彩預告:第八屆資料技術嘉年華大會將於2018年11月16日~17日北京市富力萬麗酒店盛大開啟。本次大會圍繞資料、智慧、鏈接組織前沿議題,倡導以智慧智慧演算法應用,發掘資料價值,以技術將企業鏈接到未來的戰略制高點


福利全場通票等你搶

點擊“原文鏈接”查看大會詳情。

GTID是全稱是Global Transaction Identifier,可簡化MySQL的主從切換以及Failover。GTID用於在binlog中唯一標識一個事務。當事務提交時,MySQL Server在寫binlog的時候,會先寫一個特殊的Binlog Event,型別為GTID_Event,指定下一個事務的GTID,然後再寫事務的Binlog。主從同步時GTID_Event和事務的Binlog都會傳遞到從庫,從庫在執行的時候也是用同樣的GTID寫binlog,這樣主從同步以後,就可通過GTID確定從庫同步到的位置了。


在MySQL 5.6 中,資料庫服務器上的每個事務都會被分配一個唯一的事務標示符,它是一個64位非零數值,根據事務提交的順序分配。GTID有兩部分。 第一部分是指服務器UUID。 此UUID是32個字符的隨機字串。 該值取自位於mysql資料目錄中的auto.cnf檔案。 第二部分是序列。

例如:

 


在從庫上,GTID是單個運算式:

fba30f4d-5815-11e8-9beb-000c2900351f:10

 

需要瞭解的是,如果事務從 master 複製到了 slave 端,事務的二進制位置會發生改變,這是由於在 slave 端需要將事務寫入到 slave 自己的二進制日誌裡面,那所寫位置是不一樣的,但是全域性事務識別符號是一樣的。

 

對於GTID的引數

 

  • l gtid_executed會記錄當前執行的GTID的 UUID,在MySQL 5.6中必須配置引數log_slave_updates的最重要原因在於當slave重啟後,無法得知當前slave已經運行到的GTID位置,因為變數gtid_executed是一個記憶體值。

  • l gtid_mode用於控制開啟/關閉GTID樣式。

  • l gtid_owned是一個只讀變數,其內容取決於它的範圍。 當與session會話級一起使用時,該串列包含此客戶端擁有的所有GTID; 當與global 級一起使用時,它包含所有GTID及其所有者的串列。

  • l gtid_purged,表示被purge掉的GTID集合

  

示例:

查看binlog

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!40019 SET @@session.max_insert_delayed_threads=0*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 4

#181009 23:02:36 server id 1  end_log_pos 120 CRC32 0x07eff3b3  Start: binlog v 4, server v 5.6.40-log created 181009 23:02:36 at startup

# Warning: this binlog is either in use or was not closed properly.

ROLLBACK/*!*/;

# at 120

#181009 23:02:36 server id 1  end_log_pos 151 CRC32 0xb62fd2d2  Previous-GTIDs

# [empty]

# at 151

#181010  4:37:11 server id 1  end_log_pos 199 CRC32 0x2f451f69  GTID [commit=yes]

SET @@SESSION.GTID_NEXT= ‘fba30f4d-5815-11e8-9beb-000c2900351f:1’/*!*/;

# at 199

#181010  4:37:11 server id 1  end_log_pos 271 CRC32 0xa6b6773e  Query   thread_id=5     exec_time=0     error_code=0

SET TIMESTAMP=1539160631/*!*/;

SET @@session.pseudo_thread_id=5/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1075838976/*!*/;

SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;

/*!\C utf8 *//*!*/;

SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET @@session.collation_database=DEFAULT/*!*/;

BEGIN

/*!*/;

# at 271

#181010  4:37:11 server id 1  end_log_pos 336 CRC32 0x0f828e75  Table_map: `test`.`tx_albert` mapped to number 75

# at 336

#181010  4:37:11 server id 1  end_log_pos 398 CRC32 0xd023df0a  Write_rows: table id 75 flags: STMT_END_F

### INSERT INTO `test`.`tx_albert`

### SET

###   @1=3

###   @2=’enmo’

###   @3=5

###   @4=’F’

###   @5=’BeiJing’

###   @6=’BJ’

# at 398

#181010  4:37:11 server id 1  end_log_pos 429 CRC32 0x7117fe15  Xid = 45

COMMIT/*!*/;

# at 429

#181010  4:38:24 server id 1  end_log_pos 477 CRC32 0x8b8da3af  GTID [commit=yes]

SET @@SESSION.GTID_NEXT= ‘fba30f4d-5815-11e8-9beb-000c2900351f:2’/*!*/;

# at 477

#181010  4:38:24 server id 1  end_log_pos 549 CRC32 0xe2c69fee  Query   thread_id=5     exec_time=0     error_code=0

SET TIMESTAMP=1539160704/*!*/;

BEGIN

/*!*/;

# at 549

#181010  4:38:24 server id 1  end_log_pos 614 CRC32 0xa52a4212  Table_map: `test`.`tx_albert` mapped to number 75

# at 614

#181010  4:38:24 server id 1  end_log_pos 676 CRC32 0x12c7c08f  Write_rows: table id 75 flags: STMT_END_F

### INSERT INTO `test`.`tx_albert`

### SET

###   @1=4

###   @2=’sed’

###   @3=34

###   @4=’M’

###   @5=’GuiYang’

###   @6=’DBA’

# at 676

#181010  4:38:24 server id 1  end_log_pos 707 CRC32 0xab6aa483  Xid = 46

COMMIT/*!*/;

SET @@SESSION.GTID_NEXT= ‘AUTOMATIC’ /* added by mysqlbinlog *//*!*/;

DELIMITER ;

# End of log file

 

SET @@SESSION.GTID_NEXT= ‘fba30f4d-5815-11e8-9beb-000c2900351f:1’/*!*/;

 

其中’fba30f4d-5815-11e8-9beb-000c2900351f’ 是server UUID,‘1’ 是sequence ,即提交的序列

 

#181010  4:37:11 server id 1  end_log_pos 429 CRC32 0x7117fe15  Xid = 45

 

Xid = 45 表示下一個sequence。

 

MySQL通過全域性變數gtid_mode控制開啟/關閉GTID樣式。但是gtid_mode是只讀的,可添加到配置檔案中,然後重啟mysqld來開啟GTID樣式。由於GTID需要寫入到二進制日誌,所以要使用了GTID,同時也需要把二進制日誌啟用。相關配置項如下:

 

MariaDB 資料庫作為是 MySQL 的一個分支,在某些特性上與 MySQL相同。MariaDB是完全兼容MySQL,包括API和命令列,同時在儲存引擎方面,它使用XtraDB作為MySQL InnoDB的替代品,而XtraDB 也能兼容著 InnoDB。

GTID複製是出現在MariaDB 10版中,它由The Domain ID,server ID,事務序列號組成。在MariaDB 10版中預設是開啟GTID複製樣式,每個 Event Group 寫到 Binlog 時會先收到一個GTID_EVENT,用MariaDB的 mysqlbinlog 工具或者 SHOW BINLOG EVENTS 命令可以看到這個Event。同時在MariaDB 10版無需設置GTID任何引數,更不需像MySQL 5.6 那樣,需要在slave上設置log_slave_updates=1(這樣會增加slave的I/O壓力)。


MariaDB 支持熱切換GTID,不像MySQL5.6/5.7 版本一樣,修改GTID 樣式需要修改相應的GTID 引數,並需要重啟。

示例:

CHANGE MASTER TO master_use_gtid = { slave_pos | current_pos | no }

  • l slave_pos,是將把Slave配置為使用 GTID 方式。當Slave連接到Master時,Master將從最後一個GTID開始給Slave複製 Binlog

  • l current_pos,該設置無需知道當前實體是否是Master還是Slave,但是對於slave來說,如果存在於複製無關的其他事務,可能會引起複制的錯誤。當然可以在slave 上設置@@GLOBAL.gtid_strict_mode=1,即開啟GTID嚴格樣式。

  • l no,也即是傳統的複製樣式

 

查看slave 複製情況:

MariaDB [(none)]> show slave status\G show processlist;

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

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.1.34

                  Master_User: repl

                  Master_Port: 3306

                Connect_Retry: 60

              Master_Log_File: mariadb-bin.000002

          Read_Master_Log_Pos: 993

               Relay_Log_File: mariadb-relay-bin.000002

                Relay_Log_Pos: 644

        Relay_Master_Log_File: mariadb-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:

                   Last_Errno: 0

                   Last_Error:

                 Skip_Counter: 0

          Exec_Master_Log_Pos: 993

              Relay_Log_Space: 944

              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: 1000

               Master_SSL_Crl:

           Master_SSL_Crlpath:

                   Using_Gtid: Slave_Pos

                  Gtid_IO_Pos: 0-1000-4

      Replicate_Do_Domain_Ids:

  Replicate_Ignore_Domain_Ids:

                Parallel_Mode: conservative

1 row in set (0.00 sec) 

 

可以看到當前slave使用的GTID 傳輸為Using_Gtid: Slave_Pos,獲取到的pos位置為0-1000-4。

“0”,第一位是Domain ID,這是一個32位的無符號整型;

“ 1000”,第二位是Server ID,這跟傳統的主備複製中 Server ID 的含義是一樣的,也是一個32位無符號整型。因此在一個複製拓撲中每個實體的Server ID必須是唯一的;

“4”,第三位是事務序列號(Sequence Number)。這是一個64位的無符號整型。每個新產生的 Event Group 記錄到Binlog時都會新生成一個單調遞增的序列號

 

備註:MariaDB 10.0/10.1的GTID複製與MySQL 5.6/5.7 不兼容。

 

參閱:https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibility

 


近期文章

刪了庫之後,不要著急跑路

一道面試題看資料庫性能和安全的方方面面

Percona發佈XtraBackup for MySQL 8.0

獨立發佈的Oracle嚴重CVE-2018-3110公告

Oracle宣佈在雲上正式上線 自治事務處理資料庫

為什麼看了那麼多災難,還是過不好備份這一關?

赞(0)

分享創造快樂