GTID主从

最新推荐文章于 2024-08-24 02:04:49 发布
最新推荐文章于 2024-08-24 02:04:49 发布
阅读量167 收藏
点赞数
文章标签： 数据库 mysql 服务器
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ZHJSXX/article/details/126105934
版权

GTID主从

GTID概念介绍

GTID即全局事务ID (global transaction identifier), 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。GTID最初由google实现，官方MySQL在5.6才加入该功能。mysql主从结构在一主一从情况下对于GTID来说就没有优势了，而对于2台主以上的结构优势异常明显，可以在数据不丢失的情况下切换新主。使用GTID需要注意: 在构建主从复制之前，在一台将成为主的实例上进行一些操作（如数据清理等），通过GTID复制，这些在主从成立之前的操作也会被复制到从服务器上，引起复制失败。也就是说通过GTID复制都是从最先开始的事务日志开始，即使这些操作在复制之前执行。比如在server1上执行一些drop、delete的清理操作，接着在server2上执行change的操作，会使得server2也进行server1的清理操作。

GTID实际上是由UUID+TID (即transactionId)组成的。其中UUID(即server_uuid) 产生于auto.conf文件(cat /data/mysql/data/auto.cnf)，是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增，所以GTID能够保证每个MySQL实例事务的执行（不会重复执行同一个事务，并且会补全没有执行的事务）。GTID在一组复制中，全局唯一。 下面是一个GTID的具体形式 :

mysql> show master status;
+-----------+----------+--------------+------------------+-------------------------------------------+
| File      | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+-----------+----------+--------------+------------------+-------------------------------------------+
| on.000003 |      187 |              |                  | 7286f791-125d-11e9-9a9c-0050568843f8:1-362|
+-----------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

GTID:7286f791-125d-11e9-9a9c-0050568843f8:1-362 UUID:7286f791-125d-11e9-9a9c-0050568843f8 transactionId:1-362

在整个复制架构中GTID 是不变化的,即使在多个连环主从中也不会变。

例如：ServerA —>ServerB ---->ServerC
GTID从在ServerA ,ServerB,ServerC 中都是一样的。
了解了GTID的格式，通过UUID可以知道这个事务在哪个实例上提交的。通过GTID可以极方便的进行复制结构上的故障转移，新主设置，这就很好地解决了下面这个图所展现出来的问题。

在这里插入图片描述

如图, Server1(Master)崩溃，根据从上show slave status获得Master_log_File/Read_Master_Log_Pos的值，Server2(Slave)已经跟上了主，Server3(Slave)没有跟上主。这时要是把Server2提升为主，Server3变成Server2的从。这时在Server3上执行change的时候需要做一些计算。

这个问题在5.6的GTID出现后，就显得非常的简单。由于同一事务的GTID在所有节点上的值一致，那么根据Server3当前停止点的GTID就能定位到Server2上的GTID。甚至由于MASTER_AUTO_POSITION功能的出现，我们都不需要知道GTID的具体值，直接使用CHANGE MASTER TO MASTER_HOST=‘xxx’, MASTER_AUTO_POSITION命令就可以直接完成failover的工做

GTID和Binlog的关系

  • GTID在binlog中的结构
    在这里插入图片描述

  • GTID event 结构
    在这里插入图片描述

  • Previous_gtid_log_event
    Previous_gtid_log_event 在每个binlog 头部都会有每次binlog rotate的时候存储在binlog头部Previous-GTIDs在binlog中只会存储在这台机器上执行过的所有binlog，不包括手动设置gtid_purged值。换句话说，如果你手动set global gtid_purged=xx； 那么xx是不会记录在Previous_gtid_log_event中的。

  • GTID和Binlog之间的关系是怎么对应的呢? 如何才能找到GTID=? 对应的binlog文件呢？
    假设有4个binlog: bin.001,bin.002,bin.003,bin.004
    bin.001 : Previous-GTIDs=empty; binlog_event有: 1-40
    bin.002 : Previous-GTIDs=1-40; binlog_event有: 41-80
    bin.003 : Previous-GTIDs=1-80; binlog_event有: 81-120
    bin.004 : Previous-GTIDs=1-120; binlog_event有: 121-160
    假设现在我们要找GTID=$A，那么MySQL的扫描顺序为:

  • 从最后一个binlog开始扫描（即: bin.004）

  • bin.004的Previous-GTIDs=1-120，如果$A=140 > Previous-GTIDs,那么肯定在bin.004中

  • bin.004的Previous-GTIDs=1-120，如果$A=88 包含在Previous-GTIDs中,那么继续对比上一个binlog文件 bin.003,然后再循环前面2个步骤，直到找到为止.

GTID 重要参数的持久化

  • GTID相关参数
参数comment
gtid_executed执行过的所有GTID
gtid_purged丢弃掉的GTID
gtid_modeGTID模式
gtid_nextsession级别的变量，下一个gtid
gtid_owned正在运行的GTID
enforce_gtid_consistency保证GTID安全的参数

开启GTID的必备条件

gtid_mode=on    (必选)
enforce-gtid-consistency=1  （必选）
log_bin=mysql-bin           （可选）    #高可用切换，最好开启该功能
log-slave-updates=1     （可选）       #高可用切换，最好打开该功能

GTID工作原理

从服务器连接到主服务器之后，把自己执行过的GTID (Executed_Gtid_Set: 即已经执行的事务编码) 、获取到的GTID (Retrieved_Gtid_Set: 即从库已经接收到主库的事务编号) 发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主， 先change到同步最成功的那台从服务器， 等把GTID全部补全了，就可以把它提升为主了。

GTID是MySQL 5.6的新特性，可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库，从库在执行的时候也是用同样的GTID写binlog，这样主从同步以后，就可通过GTID确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过GTID自动找点儿，而无需像之前那样通过File_name和File_position找点儿了。

简而言之，GTID的工作流程为：

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

GTID主从配置

环境说明：

数据库角色IP应用与系统版本
主数据库192.168.40.99centos8/redhat8
mysql-5.7
从数据库192.168.40.100centos8/redhat8
mysql-5.7

主库配置。vi /etc/my.cnf，添加以下配置，重启mysql

[root@localhost ~]# vim /etc/my.cnf
server-id=44
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
[root@localhost ~]# service mysqld restart
Shutting down MySQL.. SUCCESS!
Starting MySQL. SUCCESS!
[root@localhost ~]#

从库配置。vi /etc/my.cnf, 添加以下配置，重启mysql

[root@localhost ~]# vim /etc/my.cnf
server-id=66
relay-log=myrelay
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
read_only=on
master-info-repository=TABLE
relay-log-info-repository=TABLE
[root@localhost ~]# service mysqld restart
Shutting down MySQL.. SUCCESS!
Starting MySQL. SUCCESS!
[root@localhost ~]#

主库授权复制用户

[root@localhost ~]# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.37 MySQL Community Server (GPL)

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
mysql> grant replication slave on *.* to 'haha'@'%' identified by 'haha123';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql>

从库设置要同步的主库信息，并开启同步

mysql> change master to master_host='192.168.40.99',master_user='haha',master_password='haha123',master_port=3306,master_auto_position=1;
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.40.99
                  Master_User: haha
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql_bin.000001
          Read_Master_Log_Pos: 154
               Relay_Log_File: myrelay.000002
                Relay_Log_Pos: 367
        Relay_Master_Log_File: mysql_bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:

测试
主库创建哈哈数据库
在这里插入图片描述
从库查看
在这里插入图片描述

http协议

超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应

状态码

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

lamp架构运行的原理

AMP其实是指Linux+Apache+Mysql+PHP的结构体系。其工作原理如下：
浏览器向服务器发送http请求，服务器 (Apache) 接受请求,由于php作为Apache的组件模块也会一起启动，它们具有相同的生命周期。Apache会将一些静态资源保存，然后去调用php处理模块进行php脚本的处理。脚本处理完后，Apache将处理完的信息通过http response的方式发送给浏览器，浏览器解析，渲染等一系列操作后呈现整个网页。
两者的区别
在LNMP中，Nginx本身对脚本不做任何的处理，而是去调用一个PHP-FPM的进程，二者是相互独立的。
在LAMP中，PHP是Apache的一个模块，具有相同的生命周期。

加油少年 good
关注
MySQL主从之GTID主从
时羽天的博客
08-01 573
MySQL的GTID主从概念和配置
gtid主从
minyao
08-31 229
文章目录1. 事务1.1 事务的特性 1. 事务 事务（Transaction），一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起，并用形如begin transaction和end transaction语句（或函数调用）来界定。事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。 1
MySQL主从复制之GTID模式
最新发布
weixin_68398469的博客
08-24 1809
GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog 都会传递到从库，从库在执行的时候也是用同样的GTID写binlog，这样主从同步以后，就可通过GTID确定从库同步到的位置了。
mysql主从
QWQ45597316的博客
07-02 343
mysql主从
MySQL主从配置和gtid主从配置
m0_62469712的博客
08-02 1015
分别在主从两台服务器上安装mysql-5.7版本，此处略过安装步骤，若有疑问请参考《mysql基础》与《mysql进阶》两篇文章。vi/etc/my.cnf,添加以下配置，重启mysql。为确保从数据库与主数据库里的数据一样，先全备主数据库并还原到从数据库中。vi/etc/my.cnf，添加以下配置，重启mysql。克隆出来的机器会有问题因为它们uuid是一样的所有会配置不成功。从库设置要同步的主库信息，并开启同步。解决方法输入这两个命令就可以了。重启从库的mysql服务。.........
mysql 5.7 gtid 主从_MySQL 5.7基于GTID的主从复制实践
weixin_31546795的博客
01-19 250
原标题：MySQL 5.7基于GTID的主从复制实践在 「」 一文中我们讲解了 MySQL 5.7 新特性多源复制的实现方法。今天我们来讲讲 MySQL 5.7 的另一个新特性基于 GTID 的主从复制实现。什么是GTID Replication从 MySQL 5.6.5 开始新增了一种基于 GTID 的复制方式。通过 GTID 保证了每个在主库上提交的事务在集群中有一个唯一的ID。这种方式强化了...
mysql gtid 主从_基于GTID搭建主从MySQL
weixin_42347925的博客
01-21 484
基于gtid搭建主从MySQL一、GTID的使用想让主从之间使用gtid的方式同步数据，需要我们在配置文件中开启mysql对gtid相关的配置信息找到my.cnf ，在mysqld模块中加入如下的配置。(主库从库都这样)# on表示开启，OFF表示关闭gtid-mode = ON# 下面的两个变量必须开启，否则MySQL拒绝启动# 通常情况，从服务器从主服务器接收到的更新不记入它的二进制日志。该选...
mysql-gtid主从配置
dabaohjl的博客
07-05 417
环境说明：主库配置。vi /etc/my.cnf，添加以下配置，重启mysql。 从库配置。vi /etc/my.cnf, 添加以下配置，重启mysql。 主库授权复制用户。 （报错的话再my.cnf里面加上 plugin-load-add=validate_password.so validate-password=FORCE_PLUS_PERMANENT ）从库设置要同步的主库信息，并开启同步。 （报错的话，执行下面操作）（ ） 配置完之后，通过查看slave的状态，可以看是否配置成功。同时可以在
GTID方式配置主从
qq_29188123的博客
08-31 264
事务是什么 事务是由原子性，一致性，隔离性和持久性组成（这四个属性通常称为ACID特性。） 原子性：只要有一步任务没有完成，所有任务都不能进行（要么做完，要么不做） 一致性：最开始为一致性，最后完成后为另一种一致性（从一个一致性到另一个一致性状态，与原子性密切相关） 隔离性：一个事务不能被其他事务干扰 持久性：也称永久性，一旦提交代表这一个事务结束（commit），会永久性保存（没有明确的提交，但也有隐性提交） 手动事务：手动加事务 自动事务：系统自动加事务 （成功提交，失败了其中一个回滚到之前） GTID
1、GTID主从
weixin_46447154的博客
08-01 139
mysql
GTID主从同步
p12361465的博客
11-22 715
GTID主从同步
mysql的GTID主从
奥给利
11-12 245
GTID主从 配置GTID //master配置 [root@xiefei local]# cat /etc/my.cnf [mysqld] basedir = /usr/local/mysql datadir = /opt/data socket = /tmp/mysql.sock port = 3306 pid-file = /opt/data/mysql.pid user = mysql s...
1. GTID主从
退！退！的博客
08-01 118
GTID主从
mysqlgtid主从复制
05-23
MySQL GTID（全局事务标识符）是一个用于在主从复制中跟踪事务的标识符。GTID 由 MySQL 服务器生成，用于唯一标识每个事务。使用 GTID，主服务器可以轻松地将事务传播到所有从服务器，并且可以自动处理主从服务器...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值