gtid

GTID的全称为 global transaction identifier,可以翻译为全局事务标示符,GTID在原始master上的事务提交时被创建。GTID需要在全局的主-备拓扑结构中保持唯一性,GTID由两部分组成:

GTID = source_id:transaction_id

source_id用于标示源服务器,用server_uuid来表示,这个值在第一次启动时生成,并写入到配置文件data/auto.cnf中

transaction_id则是根据在源服务器上第几个提交的事务来确定。

一个GTID的生命周期包括:

1.事务在主库上执行并提交

给事务分配一个gtid(由主库的uuid和该服务器上未使用的最小事务序列号),该GTID被写入到binlog中。

2.备库读取relaylog中的gtid,并设置session级别的gtid_next的值,以告诉备库下一个事务必须使用这个值

3.备库检查该gtid是否已经被其使用并记录到他自己的binlog中。slave需要担保之前的事务没有使用这个gtid,也要担保此时已分读取gtid,但未提交的事务也不恩呢过使用这个gtid.

4.由于gtid_next非空,slave不会去生成一个新的gtid,而是使用从主库获得的gtid。这可以保证在一个复制拓扑中的同一个事务gtid不变。

由于GTID在全局的唯一性,通过GTID,我们可以在自动切换时对一些复杂的复制拓扑很方便的提升新主库及新备库,例如通过指向特定的GTID来确定新备库复制坐标。

当然,使用GTID也有一些限制:

1.事务中的更新包含非事务性存储引擎,这可能导致多个GTID分配给同一个事务。

2. create table…select语句不被支持,因为该语句会被拆分成create table 和insert两个事务,并且这个两个事务被分配了同一个GTID,这会导致insert被备库忽略掉。

3.不支持CREATE/DROP临时表操作

时间: 2024-11-08 19:02:45

gtid的相关文章

Centos7-MariadbDB多实例基于GTID模式的主从配置

Mariadb GTID 全局事务ID(Global transaction ID,GTID)为每个Event Group (就是一系列 Event 组成的一个原子单元,要么一起提交要么都无法提交)引入了一个标识,因此 GTID 是标识"事务"的最佳方式(尽管 Event 里面还包含一些非事务的DML语句和DDL,它们可以作为一个单独的 Event Group ).每当一个 Event Group 从Master复制到Slave时,它的 GTID 也通过 GTID Event 被传到S

mariadb10.x启用gtid复制时提示mysql.gtid_slave_pos找不到的解决方案

mariadb10.x安装方式为yum时,当启用gtid复制方式后,一直提示mysql.gtid_slave_pos找不到的解决方案 造成的原因不详 解决方案:/usr/share/mysql/mysql_system_tables.sql是创建系统表的脚本 找到innodb_table_stats,innodb_index_stats,gtid_slave_pos表的创建方式 innodb_table_stats表的创建语句: SET FOREIGN_KEY_CHECKS=0; DROP TA

mysql主从复制--mysql-5.6基于GTID及多线程复制

GTID,Global Transaction Identifiers,全局事务标识符     由服务器的UUID和事务ID号组成一个唯一的标识.mysql 5.6后,事务首部会记录server UUID,追踪十分简单. UUID,Universally Unique Identifier,全局唯一标识符. A为master,B.C为slave,当A宕机时,B将成为New Master.C需将自己有的事务而B没有的事务复制给B,然后B才能成为Master. B和C双方事务的协商过程,由于GTID

mysql 5.6 的新特性:GTID 复制

mysql 5.6 的新特性: MySQL 5.6 包含了一个复制的新功能,enabling DevOps teams to reliably scale-out their MySQL infrastructure across commodity hardware, rel="nofollow">Global Transaction Identifiers (GTIDs)功能, 为了解决以下问题: -能够无缝的故障恢复和master与slave的切换 -能把slave指向新的

MySQL--------基于GTID半同步搭建主从

1. 背景 * GTID: 全局事物ID(Global Transaction ID),在整个事务架构中每一个事务ID号是全局唯一的,不止是在一个节点上而是整个主从复制架构中每任何两个事务的ID号都不会相同. * GTID就是由当前节点的UUID(一个128位的随机数)和为当前节点生成的自增数(TID)组成的. * GTID在分布式架构中可以保证数据的一致性.从而也实现了mysql的高可用性. * MySQL 5.6开始支持. GTID在复制中代替原有的binlog file和file posi

GTID的复制的搭建过程

1.什么是GTID? GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号; GTID实际上是由UUID+TID组成的.其中UUID是一个MySQL实例的唯一标识.TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增; #查看本数据库实例的uuid号: [email protected] [(none)]>select @@server_uuid; +--------------------------------------+

GTID模式复制异常处理

GTID区间有中断导致复制异常处理案例 昨天处理了一个MySQL 5.6版本下开启GTID模式复制异常案例,MASTER上的任何操作都无法在SLAVE上应用,SLAVE的RELAY LOG里有记录,但SLAVE的BINLOG却找不到蛛丝马迹. 由于开启了GTID,所以排查起来也简单,只需要在SLAVE上把RELAY LOG和BINLOG分别解析成文本文件,再直接搜索MASTER的UUID,就能找到SLAVE上是否应用了MASTER复制过来的事务. 排查过程中,曾经一度怀疑是因为设置了BINLOG

GTID复制环境搭建

基本环境 master slave mysql版本 mysql-5.7.14x86_64  mysql-5.7.14x86_64 ip 192.168.0.100 192.168.0.101 port 3306 3306 搭建注意事项 主库配置 #master gtid-mode=on enforce-gtid-consistency=1 binlog_format=row server-id=3306100 log-bin=/data/mysql/mysql3306/log/mysql-bin

切换-5.7-传统复制切换成GTID复制

1.基本环境:   Master Slave MySQL版本 MySQL-5.7.16-X86_64 MySQL-5.7.16-X86_64 IP 192.168.56.156 192.168.56.157 Port 3306 3306 2.在线切换 1.master和slave执行 mysql>set @@global.enforce_gtid_consistency = warn; mysql>set @@global.enforce_gtid_consistency = on; mysq

mysql change master导致gtid丢失

change master导致gtid丢失从innobackupex恢复导致binlog的拉取位置会导致主备gtid不一致.此类错误通过构造空事务方式无法修复.此时就需要change master 方式指向失败事件的下一个位点.然后按位点的方式(master_auto_position=0)来拉binlog. Slave_IO_State: Queueing master event to the relay log Master_Host: 10.1.1.111 Master_User: re