mysql gtid视图_MySQL GTID你知多少

最新推荐文章于 2023-05-09 18:25:42 发布
最新推荐文章于 2023-05-09 18:25:42 发布
阅读量107 收藏
点赞数
文章标签： mysql gtid视图
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_31834087/article/details/113591630
版权

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

slave：

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

其中主库的server-id是10，从库的server-id是20

搭建好主从以后如果没有数据写入，那么show slave status是下面这样的：

48304ba5e6f9fe08f3fa1abda7d326ab.png

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:

48304ba5e6f9fe08f3fa1abda7d326ab.png

如果在主库创建表，并且写入2条数据，那么是下面这样的：

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

从库：

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

主库：

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

其中主库的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再看看

48304ba5e6f9fe08f3fa1abda7d326ab.png

# 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)

/*!*/;

48304ba5e6f9fe08f3fa1abda7d326ab.png

可以看见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

48304ba5e6f9fe08f3fa1abda7d326ab.png

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:

48304ba5e6f9fe08f3fa1abda7d326ab.png

可以看见已经执行的事务有来自主库的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'

48304ba5e6f9fe08f3fa1abda7d326ab.png

# 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 */ /*!*/;

48304ba5e6f9fe08f3fa1abda7d326ab.png

从binlog中可以清楚的看到是从库进行了写入。下面说第二组情况

第二种情况：主从切换(我这里使用MHA切换主从)

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

可以看到在切换以后主库的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的子集。

从库：

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

然后只要从库有重新启动，才会读取。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

重启以后并且插入数据：

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

48304ba5e6f9fe08f3fa1abda7d326ab.png

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

48304ba5e6f9fe08f3fa1abda7d326ab.png

到这里相信聪明的你一定看懂了。最后顺道说说gtid跳过复制错误的方法，对于跳过一个错误，找到无法执行事务的编号，比如是2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-10，那么操作如下：

48304ba5e6f9fe08f3fa1abda7d326ab.png

stop slave;

set gtid_next='2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-10';

begin;

commit;

set gtid_next='AUTOMATIC';

start slave;

48304ba5e6f9fe08f3fa1abda7d326ab.png

上面方法只能跳过一个事务，那么对于一批如何跳过？在主库执行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;

寿灵羽
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysql 查看gitd命令_详解mysql数据库全局事务ID—GTID三个系统参数及常用命令总结...
weixin_34901508的博客
01-30 1165
概述今天主要介绍一下mysql数据库GITD涉及的三个系统参数以及常用的一些命令~一、系统参数gtid_next和gtid_purged以及gtid_executed1、gtid_next当gtid_next设为AUTOMATIC(默认)时，每个事务被提交时都会分配一个自增的GTID(这里主要是说master)，如果事务被回滚那么GTID不会被分配。如果将gtid_next设为一个合法的GTID值...
mysql gtid setup_MySQL GTID详解
weixin_39646412的博客
01-18 84
MySQL在5.6版本推出了GTID复制，相比传统的复制，GTID复制对于运维更加友好，这个事物是谁产生，产生多少事物，非常直接的标识出来。今天将讨论一下 关于从库show slave status 中的Retrieved_Gtid_Set 和 Executed_Gtid_Set.Retrieved_Gtid_Set : 从库已经接收到主库的事务编号Executed_Gtid_Set : 从库自身...
mysql gtid
喝醉酒的小白
05-09 2157
GTID（Global Transaction ID）是MySQL 5.6及以上版本中的一个特性，它是一个全局事务标识符，用于标识MySQL的事务。其中，d1f2d04e-1b0b-11ec-8f18-0242ac110002是source_id，12345是transaction_id，1是sequence_number。注意：如果主备库的gtid_executed值不一致，可能是由于主备库上的数据不一致导致的，需要进行数据同步。
MySQL GTID的管理模式
杨建荣的学习笔记
05-08 266
这是学习笔记的第1973篇文章从MySQL5.6.5开始新增了一种基于GTID的复制方式。通过GTID保证了每个在主库上提交的事务在集群中有一个唯一的ID...
mysql数据库管理-GTID详解
oradbm的博客
01-24 4584
GTID是MYSQL5.6新增的特性，GTID（Global Transaction Identifier）全称为全局事务标示符,用以数据库实例事务唯一标识，其组成主要是source_id和transaction_id 即GTID = source_id:transaction_id。其中source_id是数据库启动自动生成的数据库实例唯一标识，保存在auto.cnf中，而transaction_id则是事务执行的序列号。
mysql5.7_el7.zip
07-30
MySQL 5.7改进了复制延迟，引入了GTID（全局事务标识符）复制，可以实现无冲突的跨服务器复制，并且简化了复制设置和故障恢复。半同步复制也得到了加强，确保了主服务器上的事务在被复制到从服务器之前完成。 5. ...
银河麒麟V10 MySQL数据库安装包
11-11
5. **改进的系统架构**：MySQL 8.0的存储过程、触发器、视图等对象现在存储在系统表中，便于管理和维护。 在银河麒麟V10上安装MySQL 8.0.34的步骤通常包括： 1. **解压安装包**：首先，需要将`mysql-8.0.34-linux-...
mysql源码（mysql-8.1.0.zip）
最新发布
12-15
另外，MySQL 8.1.0可能在性能监控和调优方面也做了升级，例如提供更丰富的性能视图、查询分析工具和性能 Schema。这些工具可以帮助管理员监控数据库的运行状态，定位性能瓶颈，并进行针对性的优化。 最后，MySQL的...
mysql45讲.zip
04-20
19. **MySQL最新特性**：介绍MySQL的新版本带来的新功能，如GTID（全局事务ID）和半同步复制等。 20. **高可用与容灾**：讨论MySQL的高可用架构，如Multi-Master、Percona XtraDB Cluster等。 每个主题都可能包含...
mysql-8.0.31-winx64.zip
10-14
7. **GTID（全局事务标识符）复制**：MySQL 8.0的复制机制使用GTIDs，使得复制更加可靠且易于管理，因为GTIDs可以唯一地标识每个已提交的事务。 8. **原子DDL（数据定义语言）**：在8.0版本中，DDL操作变得原子化，...
如何查看mysql的gtid_汇总丨MySQL GTID技术点，看这一篇就够了！
weixin_34969621的博客
01-27 7087
mysql> SELECT * FROM mysql.gtid_executed;mysql.gtid_executed表是由MySQL服务器提供给内部使用的。它允许副本在副本上禁用二进制日志记录时使用GTIDs，并允许在二进制日志丢失时保留GTID状态。RESET MASTER命令，gtid_executed表将被清除。服务意外停止的情况下，当前二进制日志文件中的gtid集不会保存在gti...
如何查看mysql的gtid_MySQL GTID (三)
weixin_34125509的博客
01-27 2509
五.如何跳过一个GTID环境见系列一5.1 创建表,模拟数据#主机上create table t_test (id int primary key ,name varchar(10));insert into t_test values(1,'aa'),(2,'bb'),(3,'cc');#备机上插入一条,模拟冲突insert into t_test values(4,'dd');5.2 模拟冲突...
MySql GTID主从复制
花飘万家雪
04-21 5251
目录 1.GTID介绍 1.1GTID是什么 1.2 GTID Replication介绍 1.3 GTID的组成 1.4GTID的作用 1.5为什么要用GTID 1.6GTID比传统复制的优势 1.7GTID复制实现的工作原理 2 主从复制 2.1 一主一从 2.1.1部署数据库可查看 2.1.2 授权一个用户，用于主从复制主从> 2.1.3 修改master主配文件 2.1.4 slave主配文件 2.1.5 配置slave主机，授权从数据库 2.1.6 验证主...
只读实例（slave主从）延迟排查
weixin_33682790的博客
03-03 1万+
实为吾之愚见,望诸君酌之!闻过则喜，与君共勉 以下方法适用于实时查看只读延迟(主从延迟)，即需要在延迟发生的时候查看才能确认问题，历史延迟不适用，以下环境已经开启并行复制。 第一章：如何判断无延迟 第一步：主实例信息获取 主实例(主节点)高权限账户执行: 1,show processlist 2,show master status\G ...
Mysql GTID
一条大河
07-26 4412
GTID是什么？ GTID 全称A global transaction identifier 全局事物id，是MASTER创建的和事物相匹配的ID号； 它不仅在本机上是唯一的，而且在其他服务器上也是唯一的； gitd与事物一一对应 master每次commit事物的时候就会自动创建gtid gitd格式是 GTID = source_id:transaction_id...
MySQL GTID详解
热门推荐
woailyoo0000的博客
04-02 1万+
MySQL在5.6版本推出了GTID复制，相比传统的复制，GTID复制对于运维更加友好，这个事物是谁产生，产生多少事物，非常直接的标识出来。 今天将讨论一下 关于从库show slave status 中的Retrieved_Gtid_Set 和 Executed_Gtid_Set. Retrieved_Gtid_Set : 从库已经接收到主库的事务编号 Executed_Gtid_Set ...
与MySQL传统复制相比，GTID有哪些独特的复制姿势？
weixin_33806914的博客
12-19 627
本文为DBA+社群的投稿文章：http://dbaplus.cn/news-11-857-1.html 与MySQL传统复制相比，GTID有哪些独特的复制姿势？ 前言 GTID(Global Transaction ID)是MySQL5.6引入的功能，可以在集群全局范围标识事务，用于取代过去通过binlog文件偏...
MySQL 8 复制（四）——GTID与复制
wzy0623的专栏
06-06 9120
目录 一、GTID简介 1. 什么是GTID 2. GTID的格式与存储 二、GTID生命周期 1. 典型事务的GTID生命周期 2. GTID分配 3. gtid_next系统变量 4. gtid_purged系统变量 三、GTID自动定位 MySQL复制中使用的事务类型有以下两种： GTID事务：在二进制日志中每个GTID事务始终都以Gtid_log_ev...
mysql8配置主从数据库_mysql8 数据库主从详细配置
weixin_34979632的博客
01-18 325
注意：数据库要保持一直如果不会安装，请查看安装步骤centos8 离线安装mysql8，详细安装步骤1、主节(Master)点配置修改 Master 的配置文件/etc/my.cnf在my.cnf文件中加入如下配置内容[mysqld]log-bin=mysql-binserver-id=12、从节点(Slave)配置修改 Slave 的配置文件/etc/my.cnf在my.cnf文件中加入如下配...
mysql gtid binlog_MySQL binlog中at position、gtid、sequence_number、last_committed、xid的区别...
05-13
这些都是 MySQL 中与 binlog 和 GTID（全局事务标识符）有关的概念。它们之间的区别如下： - GTID：全局事务标识符，是一个全局唯一的标识符，用于标识 MySQL 中的每个事务。GTID 由三个部分组成：server_uuid、...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值