MySQL GTID你知多少

時間  2019-11-06
標籤 mysql gtid 多少 欄目 MySQL 简体版
原文   原文鏈接

MySQL在5.6的版本推出了GTID複製，相比傳統的複製，GTID複製對於運維更加友好，這個事務是誰產⽣，產⽣多少事務，⾮常直接的標識出來，固然GTID也有限制，對於什麼是GTID能夠參考我以前的文章：MySQL 5.6 GTID Replication，那麼今天主要是想和同窗們分享一下關於從庫show slave status中的Retrieved_Gtid_Set和Executed_Gtid_Set。html

Retrieved_Gtid_Set：從庫已經接收到主庫的事務編號
Executed_Gtid_Set：已經執行的事務編號
 
那麼下面截圖中的這個如何解釋？
 
 那麼下面慢慢和你們道來，莫慌。首先看看master和slave的server-uuid
master： 
[root@localhost][db1]> show variables like '%uuid%';       
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | 2a09ee6e-645d-11e7-a96c-000c2953a1cb |
+---------------+--------------------------------------+
1 row in set (0.00 sec)

[root@localhost][db1]>

slave：mysql

[root@localhost][(none)]> show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | 8ce853fc-6f8a-11e7-8940-000c29e3f5ab |
+---------------+--------------------------------------+
1 row in set (0.01 sec)

[root@localhost][(none)]>

其中主庫的server-id是10，從庫的server-id是20 sql

搭建好主從之後若是沒有數據寫入，那麼show slave status是下面這樣的：服務器

Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 10
                  Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
             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 more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version:

若是在主庫建立表，而且寫入2條數據，那麼是下面這樣的：session

[root@localhost][db1]> create table t2 ( id int);
Query OK, 0 rows affected (0.07 sec)

[root@localhost][db1]> insert into t2 select 1;
Query OK, 1 row affected (0.07 sec)
Records: 1  Duplicates: 0  Warnings: 0

[root@localhost][db1]> insert into t2 select 2;
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0

[root@localhost][db1]>

從庫：app

Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 10
                  Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
             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 more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
            Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
                Auto_Position: 1

主庫：運維

[root@localhost][db1]> show master status;
+------------------+----------+--------------+------------------+------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000001 |      912 |              |                  | 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)

其中主庫的Executed_Gtid_Set爲2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3測試

能夠看見Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3，Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3，也就是說主庫產生了3個事務，從庫接受到了來自主庫的3個事務，而且都已經執行。
其中2a09ee6e-645d-11e7-a96c-000c2953a1cb是主庫的server-uuid。那麼咱們能夠解析從庫的binlog再看看ui

# at 154
#170823  0:38:38 server id 10  end_log_pos 219 CRC32 0x6268641f         GTID    last_committed=0        sequence_number=1
SET @@SESSION.GTID_NEXT= '2a09ee6e-645d-11e7-a96c-000c2953a1cb:1'/*!*/;
# at 219
#170823  0:38:38 server id 10  end_log_pos 316 CRC32 0x6c837618         Query   thread_id=103   exec_time=0     error_code=0
use `db1`/*!*/;
SET TIMESTAMP=1503419918/*!*/;
SET @@session.pseudo_thread_id=103/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
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=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
create table t2 ( id int)
/*!*/;

能夠看見server-id爲10，gtid-next爲2a09ee6e-645d-11e7-a96c-000c2953a1cb:1，執行了建表。剩下的2-3是執行的數據插入，我這裏沒寫出來。spa

這也體現了文章開始提到的：這個事務是誰產⽣，產⽣多少事務，⾮常直接的標識出來

那麼對於文章開頭那個詭異的gtid是怎麼出來的呢？先說說已經執行的事務：

Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1

這裏的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33確定很好理解，就是已經執行主庫的1-33的事務，那麼8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1呢？這個其實也簡單，有兩種狀況：

第一種狀況：從庫有數據寫入( 從庫插入數據 )

[root@localhost][db1]> insert into t2 select 1;
Query OK, 1 row affected (0.03 sec)
Records: 1  Duplicates: 0  Warnings: 0

show slave status

Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 10
                  Master_UUID: 2a09ee6e-645d-11e7-a96c-000c2953a1cb
             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 more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
            Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
                Auto_Position: 1
         Replicate_Rewrite_DB:

能夠看見已經執行的事務有來自主庫的2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3，也有從庫剛本身寫入的數據：8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1。咱們能夠解析binlog看看。

mysqlbinlog -vv mysql-bin.000001 --include-gtids='8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1'
# at 896
#170823  0:59:19 server id 20  end_log_pos 961 CRC32 0x0492528a         GTID    last_committed=3        sequence_number=4
SET @@SESSION.GTID_NEXT= '8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1'/*!*/;
# at 961
#170823  0:59:19 server id 20  end_log_pos 1032 CRC32 0xbf545cca        Query   thread_id=25    exec_time=0     error_code=0
SET TIMESTAMP=1503421159/*!*/;
SET @@session.pseudo_thread_id=25/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
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=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 1032
#170823  0:59:19 server id 20  end_log_pos 1079 CRC32 0x2f2de3ec        Rows_query
# insert into t2 select 1
# at 1079
#170823  0:59:19 server id 20  end_log_pos 1123 CRC32 0x18fe1c5c        Table_map: `db1`.`t2` mapped to number 109
# at 1123
#170823  0:59:19 server id 20  end_log_pos 1163 CRC32 0x163a708e        Write_rows: table id 109 flags: STMT_END_F

BINLOG '
52KcWR0UAAAALwAAADcEAACAABdpbnNlcnQgaW50byB0MiBzZWxlY3QgMezjLS8=
52KcWRMUAAAALAAAAGMEAAAAAG0AAAAAAAEAA2RiMQACdDIAAQMAAVwc/hg=
52KcWR4UAAAAKAAAAIsEAAAAAG0AAAAAAAEAAgAB//4BAAAAjnA6Fg==
'/*!*/;
### INSERT INTO `db1`.`t2`
### SET
###   @1=1 /* INT meta=0 nullable=1 is_null=0 */
# at 1163
#170823  0:59:19 server id 20  end_log_pos 1194 CRC32 0xe3347ac1        Xid = 68
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;

從binlog中能夠清楚的看到是從庫進行了寫入。下面說第二組狀況
第二種狀況：主從切換（我這裏使用MHA切換主從）

             Master_Server_Id: 20
                  Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab
             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 more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
            Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1
                Auto_Position: 1

能夠看到在切換之後主庫的server-id是20。這裏的意思是接收到主庫8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1，而且已經執行這個事務，那麼這個事務其實就是以前在從庫寫入的那條數據。對於2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3這個是以前做爲主庫執行。若是此時在主庫再插入1條數據，那麼又會變化以下：

  Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2
            Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-2

下面說說文章開頭提到的gtid不連續的問題，相似2a09ee6e-645d-11e7-a96c-000c2953a1cb:37-45，這個是因爲binlog被清理之後致使的，咱們能夠測試一下。而後查看gtid_purged變量。
binlog不可能永遠駐留在服務上，須要按期進行清理(經過expire_logs_days能夠控制按期清理間隔)，不然早晚它會把磁盤用盡。gtid_purged用於記錄已經被清除了的binlog事務集合，它是gtid_executed的子集。只有gtid_executed爲空時才能手動設置該變量，此時會同時更新gtid_executed爲和gtid_purged相同的值。gtid_executed爲空意味着要麼以前沒有啓動過基於GTID的複製，要麼執行過RESET MASTER。執行RESET MASTER時一樣也會把gtid_purged置空，即始終保持gtid_purged是gtid_executed的子集。

從庫：

[root@localhost][db1]> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |      3530 |
+------------------+-----------+
1 row in set (0.00 sec)

[root@localhost][db1]> flush logs;
Query OK, 0 rows affected (0.05 sec)

[root@localhost][db1]> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 |      3577 |
| mysql-bin.000002 |       234 |
+------------------+-----------+
2 rows in set (0.00 sec)

[root@localhost][db1]> PURGE BINARY LOGS TO 'mysql-bin.000002';
Query OK, 0 rows affected (0.01 sec)

[root@localhost][db1]> show master logs;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000002 |       234 |
+------------------+-----------+
1 row in set (0.00 sec)

而後只要從庫有從新啓動，纔會讀取。MySQL服務器啓動時，經過讀binlog文件，初始化gtid_executed和gtid_purged,使它們的值能和上次MySQL運行時一致。

gtid_executed被設置爲最新的binlog文件中Previous_gtids_log_event和全部Gtid_log_event的並集。
gtid_purged爲最老的binlog文件中Previous_gtids_log_event。

沒啓動前：

 Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9
            Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9

重啓之後而且插入數據：

            Master_Server_Id: 20
                  Master_UUID: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab
             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 more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 8ce853fc-6f8a-11e7-8940-000c29e3f5ab:10
            Executed_Gtid_Set: 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-10
                Auto_Position: 1
[root@localhost][(none)]> show variables like 'gtid_purged'; 
+---------------+------------------------------------------------------------------------------------+
| Variable_name | Value                                                                              |
+---------------+------------------------------------------------------------------------------------+
| gtid_purged   | 2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,
8ce853fc-6f8a-11e7-8940-000c29e3f5ab:1-9 |
+---------------+------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

到這裏相信聰明的你必定看懂了。最後順道說說gtid跳過複製錯誤的方法，對於跳過一個錯誤，找到沒法執行事務的編號，好比是2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-10，那麼操做以下：

stop slave;
set gtid_next='2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-10';
begin;
commit;
set gtid_next='AUTOMATIC';
start slave;

上面方法只能跳過一個事務，那麼對於一批如何跳過？在主庫執行show master status，看主庫執行到了哪裏，好比：2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33，那麼操做以下：

stop slave;
reset master;
set global gtid_purged='2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-33';
start slave;
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程