MySQL在5.6的版本推出了GTID复制，相比传统的复制，GTID复制对于运维更加友好，这个事务是谁产⽣，产⽣多少事务，⾮常直接的标识出来，当然GTID也有限制，对于什么是GTID可以参考我之前的文章：MySQL 5.6 GTID Replication，那么今天主要是想和同学们分享一下关于从库show slave status中的Retrieved_Gtid_Set和Executed_Gtid_Set。

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：

[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

搭建好主从以后如果没有数据写入，那么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条数据，那么是下面这样的：

[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]>

从库：

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再看看

# 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是执行的数据插入，我这里没写出来。

这也体现了文章开始提到的：这个事务是谁产⽣，产⽣多少事务，⾮常直接的标识出来

那么对于文章开头那个诡异的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;

MySQL GTID你知多少的更多相关文章

  1. MySQL GTID你知多少【转】

    MySQL在5.6的版本推出了GTID复制,相比传统的复制,GTID复制对于运维更加友好,这个事务是谁产⽣,产⽣多少事务,⾮常直接的标识出来,当然GTID也有限制,对于什么是GTID可以参考我之前的文 ...

  2. MySQL GTID 错误处理汇总

    MySQL GTID是在传统的mysql主从复制的基础之上演化而来的产物,即通过UUID加上事务ID的方式来确保每一个事物的唯一性.这样的操作方式使得我们不再需要关心所谓的log_file和log_P ...

  3. MySQL GTID （二）

    MySQL GTID 系列之二 三.在线将GTID转化为传统模式 环境见上篇系列文章 关闭GTID,不用停止服务,不影响线上业务 3.1 关闭GTID复制,调整为传统复制 #SLVAE实例上停止复制 ...

  4. MySQL GTID (一)

    MySQL GTID 系列之一 一.GTID相关概念 GTID:全局事务标识符,MySQL5.6版本开始在主从复制中推出的重量级特性. 每提交一个事务,当前执行线程都会拿到一个给定复制环境中唯一的GT ...

  5. mysql gtid 主从复制

    基于GTID环境搭建主从复制 1.环境 ----------------------------------------------------------| |mysql版本 | 5.7.14 | ...

  6. MYSQL GTID position

    MySQL5.6 新特性之GTID - jyzhou - 博客园 http://www.cnblogs.com/zhoujinyi/p/4717951.html MySQL · 答疑释惑 · GTID ...

  7. MySQL GTID复制Slave跳过错误事务Id以及复制排错问题总结

    GTID复制典型的复制错误有两种:1,数据对象级别的错误,包括主库上update的数据在从库上不存在,主从逐渐冲突,库表索引等对象的冲突等等,   如果是纯粹的跳过错误的话,这一类的错误需要跳过思路是 ...

  8. mysql GTID主从配置

    主数据库配置 [mysqld] server_id=1 gtid_mode=on enforce_gtid_consistency=on skip_slave_start=1log_bin=maste ...

  9. MySQL GTID复制错误处理之跳过错误

    某Slave报错信息: mysql> show slave status\G; mysql> show slave status\G; ************************** ...

随机推荐

  1. safari10.0以上版本出现默认小人头图标

    1.可能改input输入框外层有兄弟元素在input之前,将input元素位置放置在所有兄弟元素之前即可

  2. python中3个连续的单引号是什么意思?''' ... ''' 这样的引号是什么意思?

  3. IOS 设置视图半透明子控件不透明

    代码处理: UIColor *color = [[UIColor blackColor] colorWithAlphaComponent:0.6]; self.view.backgroundColor ...

  4. call和apply（学习笔记）

    call() call() 方法调用一个函数, 其具有一个指定的this值和分别地提供的参数(参数的列表). 语法: function.call(thisArg, arg1, arg2, ...) 参 ...

  5. Java中Json字符串直接转换为对象(包括多层List集合)

    使用到的类:net.sf.json.JSONObject 使用JSON时,除了要导入JSON网站上面下载的json-lib-2.2-jdk15.jar包之外,还必须有其它几个依赖包:commons-b ...

  6. 使用spring代码中控制事务

    1.首先需要在代码中注入事务管理器 @Autowired private PlatformTransactionManager transactionManager; 2.代码中使用如下 public ...

  7. PDF分享：国外优秀数学教材选评

    <国外优秀数学教材选评>推荐书目下载 具体内容请查看原内容: http://www.library.fudan.edu.cn/wjzx/list/373-1-20.htm 或者http:/ ...

  8. 20155205 郝博雅 Exp5 MSF基础应用

    20155205 郝博雅 Exp5 MSF基础应用 一.实验目标 本实践目标是掌握metasploit的基本应用方式,重点常用的三种攻击方式的思路.具体需要完成: 1.一个主动攻击实践,如ms08_0 ...

  9. Hive数据倾斜解决方案

    https://blog.csdn.net/yu0_zhang0/article/details/81776459 https://blog.csdn.net/lxpbs8851/article/de ...

  10. Windows 10 无法使用搜索栏，显示一片空白

    查看这个:https://blog.csdn.net/qq_41571056/article/details/82928919