GDIT的用法
从 MYSQL 的主从复制讲起
在Mysql中, 我们部署一个数据库的时候往往会有多个服务器, 我们称之为服务器的拓朴结构. 在主从复制(Replication)环境中, 通常主服务器(Master)负责处理写操作以及事务的生成与提交. 主服务器会将对服务器的操作记录到binlog中, 当事务开始执行的时候, MYSQL会在内存中暂存事务的操作, 这些操作不会写入binlog中, 只有事务完成所有操作并提交后, MySQL会将该事务的所有变更记录写入binlog.
在主从复制的数据库拓扑结构中, 主服务器(Master)写入binlog, 从服务器(Slave)根据主服务器记录的binlog重放事务, 也就说对主服务器所作的操作都在从服务器上回放一遍.
下图是MYSQL主从服务器复制的原理:
- 对主服务器提交的一个事务, 在事务开始执行时会生成事务的全局ID, 也就是
GDIT - 事务执行完之后, 事务commit之后, 会将事务的操作写入binlog文件中, 格式为SQL语言.
- 主服务器(Master)的
logdump Thread线程会不断地将数据从主服务器发送方到从服务器(Slave). - 从服务器(Slave)的
I/O thread线程会将收到的binlog信息写入到中继日志Relay Log文件中. - 从数据库端(Slave)的SQL线程从中继日志中获取GTID号, 然后对比从数据库本地的Binlog查看其是否有记录. 如果有记录, 则说明该GTID的事务已经执行, 此时从数据库会忽略.
- 如果没有记录, 则从数据库就会从中继日志中获取数据并执行该GTID的事务, 并记录到binlog中. 根据GTID号可以知道事务最初是在哪个数据库上提交的, GTID的存在方便了主从复制的宕机切换(failover).
MYSQL官方网站对GDIT的介绍如下:
A global transaction identifier (GTID) is a unique identifier created and associated with each transaction committed on the server of origin (the source). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication topology.
所以简单来说GDIT可以看做是事务的唯一 identifier, 在数据库的拓扑结构中仍然保持唯一.
当一个事务执行完后, 被提交到主服务器的时候, 只要事务被写入二进制日志(binlog)该事务会被分配一个GDIT, GDIT分配时保连续递增.
不会分配GDIT的情况:
- 一个事务没有被写入binlog文件, 例如读事务, 或者该事务被筛选掉了.
主从复制的复制事务使用与主服务器上相同的GDIT. 从服务器(Slave) 通常不会写binlog,虽然它有自己的binlog文件, 即使会写binlog, 从服务器仍然会使用和主服务器相同的GDIT.
标签：总结,binlog,事务,数据库,用法,GTID,服务器,GDIT From： https://www.cnblogs.com/wevolf/p/18348897