歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

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

2018-10-22 分類：後端 閱讀(484) 評論(0)

關註獲得更多內容

精彩預告：第八屆資料技術嘉年華大會將於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)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂