mysql之 MySQL 主从基于 GTID 复制原理概述

一、 什么是GTID ( Global transaction identifiers ):
MySQL-5.6.2开始支持,MySQL-5.6.10后完善,GTID 分成两部分,一部分是服务的UUid,UUID保存在mysql数据目录的auto.cnf文件中,
这是一个非常重要的文件,不能删除,这一部分是不会变的。另外一部分就是事务ID了,随着事务的增加,值一次递增,如下图
+---------------+----------+--------------+------------------+--------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+--------------------------------------------+
| binlog.000029 | 23556 | | | 724afcc2-29d6-11e4-9902-000c290c0121:1-362 |
+---------------+----------+--------------+------------------+--------------------------------------------+
GTID:724afcc2-29d6-11e4-9902-000c290c0121:1-362
UUID:724afcc2-29d6-11e4-9902-000c290c0121
transactionId:1-362
在整个复制架构中GTID 是不变化的,即使在多个连环主从中也不会变。
例如:ServerA --->ServerB ---->ServerC
GTID从在ServerA ,ServerB,ServerC 中都是一样的。

二、 GTID的工作原理:
1、master更新数据时,会在事务前产生GTID,一同记录到binlog日志中。
2、slave端的i/o 线程将变更的binlog,写入到本地的relay log中。
3、sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录。
4、如果有记录,说明该GTID的事务已经执行,slave会忽略。
5、如果没有记录,slave就会从relay log中执行该GTID的事务,并记录到binlog。
6、在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描。

三、 GTID的优点:
1.一个事务对应一个唯一ID,一个GTID在一个服务器上只会执行一次
2.GTID是用来代替传统复制的方法,GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置
3.减少手工干预和降低服务故障时间,当主机挂了之后通过软件从众多的备机中提升一台备机为主机

那么GTID复制是怎么实现自动同步,自动对应位置的呢?
例如:ServerC <-----ServerA ----> ServerB
主机ServerA
备机:ServerB,ServerC
当主机ServerA 挂了之后 ,此时ServerB执行完了所有从ServerA 传过来的事务,
ServerC 延时一点。这个时候需要把 ServerB 提升为主机 ,Server C 继续为备机。
当ServerC 链接ServerC 之后,首先在自己的二进制文件中找到从ServerA 传过来的最新的GTID,
然后将这个GTID 发送到ServerB ,ServerB 获得这个GTID之后,就开始从这个GTID的下一个GTID
开始发送事务给ServerC。这种自我寻找复制位置的模式减少事务丢失的可能性以及故障恢复的时间。

四、 GTID的限制:
1.不支持非事务引擎
2.不支持create table ... select 语句复制(主库直接报错)
原理:( 会生成两个sql,一个是DDL创建表SQL,一个是insert into 插入数据的sql。
由于DDL会导致自动提交,所以这个sql至少需要两个GTID,但是GTID模式下,只能给这个sql生成一个GTID )
3.不允许一个SQL同时更新一个事务引擎表和非事务引擎表
4.在一个复制组中,必须要求统一开启GTID或者是关闭GTID
5.开启GTID需要重启(5.7除外)
6.开启GTID后,就不再使用原来的传统复制方式
7.对于create temporary table 和 drop temporary table语句不支持
8.不支持sql_slave_skip_counter

时间: 2024-10-10 17:57:10

mysql之 MySQL 主从基于 GTID 复制原理概述的相关文章

mysql之 mysql 5.6不停机主从搭建(一主一从基于GTID复制)

环境说明:版本 version 5.6.25-log 主库ip: 10.219.24.25从库ip:10.219.24.22os 版本: centos 6.7已安装热备软件:xtrabackup 防火墙已关 补充: 主从复制原理: http://blog.csdn.net/zhang123456456/article/details/72972701GTID 复制原理: http://blog.csdn.net/zhang123456456/article/details/73002216mys

MySQL主从复制&mdash;&mdash;MySQL-5.6基于GTID及多线程的复制

一.Mysql 5.6 新特性 .... 复制功能的改进 ⒈支持多线程复制,(slave-parallel-workers=0     0: 表示禁用多线程功能:)事实上是针对每个database开启相应的独立线程.即每个库有一个单独的(sql thread),如果线上业务中,只有一个database或者绝大多数压力集中在个别database的话,多线程并发复制特性就没有意义了. ⒉支持启用GTID,对运维人员来说应该是一件令人高兴的事情,在配置主从复制,传统的方式里,你需要找到binlog和P

深入MySQL复制(二):基于GTID复制

相比传统的MySQL复制,gtid复制无论是配置还是维护都要轻松的多.本文对gtid复制稍作介绍. MySQL基于GTID复制官方手册:https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html 1.gtid基本概念 传统的基于binlog position复制的方式有个严重的缺点:如果slave连接master时指定的binlog文件错误或者position错误,会造成遗漏或者重复,很多时候前后数据是有依赖性的,这样就会出错而导

MySQL 5.7基于GTID复制的常见问题和修复步骤(二)

[问题二] 有一个集群(MySQL5.7.23)切换后复制slave报1236,其实是不小心在slave上执行了事务导致 Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containin

MySQL主从复制--MySQL5.6基于GTID及多线程复制

大纲 一.系统环境 二.MySQL初始化安装过程 三.基于GTID的主从模式配置过程 一.系统环境 系统环境 CentOS5.8 x86_64 master.network.com    master    172.16.1.101 slave.network.com     slave     172.16.1.105 软件包 mysql-5.6.26-linux-glibc2.5-x86_64.tar.gz(二进制通用安装包) 拓扑图 二.MySQL初始化安装过程 1.时间同步 [[emai

腾讯云数据库备用-基于GTID复制的mysql作为CDB的从库

原因:腾讯云数据丢失,但是又有业务在腾讯云上,所以需要对数据库进行备份(自建从库,腾讯云的说法),做腾讯云数据库的从库基于mysql 5.7实现.1.首先用户通过在控制台创建一个用于复制的账户wjqrepl: 2.给wjqrepl用户赋予相应的权限 需要进入数据库命令行中, grant replication slave on *.* to 'xxxxx'@'%' identified by '1234567'; flush privileges; 3.导出云数据库中的业务库数据 4.确认自建从

高性能Mysql主从架构的复制原理及配置详解

1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收

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主从架构的复制原理及配置详解(转)

温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取