Linux----------mysql主从复制和基于GTID主从复制

目录

  • 一、 传统mysql主从复制
  • 二、 基于GTID主从复制
  • 三、GTID主从复制和传统主从复制相比
  • 四、基于GTID主从复制的配置

一、 传统mysql主从复制

主从复制步骤:
主库将所有的写操作记录到binlog日志中并生成一个log dump线程,将binlog日志传给从库的I/O线程
从库生成两个线程,一个I/O线程,一个SQL线程
I/O线程去请求主库的binlog,并将得到的binlog日志写到relay log(中继日志) 文件中
SQL线程,会读取relay log文件中的日志,并解析成具体操作,来实现主从的操作一致,达到最终数据一致的目的

二、 基于GTID主从复制

基于GTID的复制是从Mysql5.6开始支持的一种新的复制方式,此方式与传统基于日志的方式存在很大的差异,在原来的基于日志的复制中,从服务器连接到主服务器并告诉主服务器要从哪个二进制日志的偏移量开始执行增量同步,这时我们如果指定的日志偏移量不对,这与可能造成主从数据的不一致,而基于GTID的复制会避免。
在基于GTID的复制中,首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值,然后主库会有把所有没有在从库上执行的事务,发送到从库上进行执行,并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次,这样可以避免由于偏移量的问题造成数据不一致。
什么是GTID,也就是全局事务ID,其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。
一个GITD由两部分组成的,分别是source_id 和transaction_id,GTID=source_id:transaction_id,其中source_id就是执行事务的主库的server-uuid值,server-uuid值是在mysql服务首次启动生成的,保存在数据库的数据目录中,在数据目录中有一个auto.conf文件,这个文件保存了server-uuid值(唯一的)。而事务ID则是从1开始自增的序列,表示这个事务是在主库上执行的第几个事务,Mysql会保证这个事务和GTID是一比一的关系。

配置主数据库服务器需要做的大概和传统的主从配置差不多,需要起码的在主服务器上建立复制账号,还要配置数据库日志文件的目录,这是必须的启动bin_log日志。
可以指定bin_log存放目录,而不是用数据目录,分开存储是个好习惯,特别是如果把日志和数据放在不同的磁盘分区上,这样不但可以避免日志的增长把数据磁盘分区占满,也可以提高了磁盘IO。
bin_log = /usr/local/mysql/log/mysql-bin。

三、GTID主从复制和传统主从复制相比

优点
A:很方便的进行故障转移,因为GTID是全局唯一的标识符,所以就很简单知道哪些事务在从服务器没有执行,在多个从服务器也没必要进行多个日志偏移量配置了.
B:从库和主库的数据一致性。
缺点
A:故障处理比日志处理复杂。
B:执行语句的一些限制。
C:仅支持5.6以后较晚的版本

四、基于GTID主从复制的配置

在两边的配置文件都加上
gtid_mode=ON
enforce-gtid-consistency=true

并重启数据库

原文地址:https://www.cnblogs.com/wangchengshi/p/10868707.html

时间: 2024-08-30 00:39:35

Linux----------mysql主从复制和基于GTID主从复制的相关文章

企业级-Mysql双主互备高可用负载均衡架构(基于GTID主从复制模式)

前言: 原理与思想 这里选用GTID主从复制模式Mysql主从复制模式,是为了更加确保主从复制的正确性.健康性与易配性.这里做的是两服务器A,B各有Mysql实例3310,两个实例间互为主从 主从复制模式采用GTID主从复制模式,在服务器A,B上配置keepalived负载均衡,通过VIP连接数据库,目的是一旦有某数据库宕机,keepalived 就会立即建VIP执行另外一台 健康的数据库实例上,实现快速切换,避免单点故障,从而保证业务的正常运行. 这里只做了 双主+keepalived  ,

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基于GTID 主从复制详细解析及步骤

GTID的概念 全局事务标识:global transaction identifiers GTID是一个事务一一对应,并且全局唯一ID GTID在一个服务器上只执行一次,避免重复执行导致数据混乱或主从不一致 GTID用来代替传统复制方法,不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制.而是使用MASTER_AUTO_POSTION=1的方式开始复制. MySQL-5.6.5开始支持的,MySQL-5.6.10后开始完善. 在传统的slave端,binlog是不用开

mysql主从之基于gtid的主从复制

一 GITD介绍 1.1 gtid的含义 Global Transaction Identifier,全局事务标识 阿里云的rds目前已经使用gtid 基于gtid的主从复制原理 每个mysql数据库上都有一个唯一uuid 每个事务生成一个id gtid由上面两者组合: uuid+事务id 1.2 优势 相对使用binlog+位置的方法来说 gtid让配置主从更加方便 从提升为主时比较方便 二 配置 2.1 主库的配置 [mysqld] bind-address=0.0.0.0 port=330

MySQL5.6 主从复制(基于GTID和多线程)

一:GTID工作流程图 二:什么是GTID 三:配置主从复制 四:说明 1.1 GTID工作流程图 2.1 什么是GTID GTID:是一个全局唯一标识,128位的随机符,并结合事务的ID号来组合成一个唯一的标识某一个主机上某一个事务的标识码 在binlog中,每一个事务的首部,都会写上GTID的标识,因此,GTID使得追踪和比较复制事务,变得非常简单,而且能够从奔溃中快速进行恢复 3.1主从配置以及参数说明 [Master] #数据目录位置 datadir = /MySQL_DATA   #端

mysl 基于 GTID主从复制

注意:如果主mysql已经跑了一段时间,需要用备份软件把数据备份恢复到从服务器上去,确保主从服务器数据一致,否则可能报错,而且mysql 只有5.6 以后才支持gtid,安装时确保你的软件支持gpid1.安装mysqlwget -i -c http://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm #下载mysql的yum源yum install mysql57-community-release-el7-10.noa

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

[问题一] 复制slave报错1236,是较为常见的一种报错 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 containing GTIDs that the slave require

mysql 5.7 基于GTID 主从同步的1236故障处理(其它事务故障等同)

登录从库 stop slave; 查看执行事务 show slave status\G Retrieved_Gtid_Set: ee3bdb44-f6a1-11e7-b194-005056a35fd4:21315405-51853406 Executed_Gtid_Set: ee3bdb44-f6a1-11e7-b194-005056a35fd4:1-51853406 注:Retrieved_Gtid_Set 为获取主库上的事务ID Executed_Gtid_set为正在执行的事务ID res

CentOS6.8下MySQL5.6.40基于GTID主从及多线程复制

大纲 一 GTID简介 二 环境准备 三 数据库的安装 四 基于GTID主从配置步骤 五 验证GTID复制功能 一 GTID简介 GTID(Global Transaction ID)是对于一个已提交事务的编号,并且是一个全局唯一的编号.GTID实际上是由UUID+TID组成的.其中UUID是一个MySQL实例的唯一标识.TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增.下面是一个GTID的具体形式3E11FA47-71CA-11E1-9E33-C80AA9429562:23更详