栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 软件开发 > 后端开发 > Java

GTID主从

Java 更新时间: 发布时间: IT归档 最新发布 模块sitemap 名妆网 法律咨询 聚返吧 英语巴士网 伯小乐 网商动力

GTID主从

GTID主从

文章目录
    • GTID主从
      • 1. gtid概念介绍
      • 2. GTID相关参数
      • 3. 开启GTID的必备条件
      • 4. GTID工作原理
        • 4.1 GTID的工作流程为:
      • 5. GTID主从配置
        • 5.1 环境
        • 5.2 主库配置
        • 5.3 从库配置。vi /etc/my.cnf, 添加以下配置,重启mysql。
        • 5.4 主库授权复制用户。
        • 5.5 从库设置要同步的主库信息,并开启同步。
      • 6. 测试

1. gtid概念介绍
  • GTID即全局事务ID (global transaction identifier), 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID

  • 对于2台主以上的结构优势异常明显,可以在数据不丢失的情况下切换新主

  • 使用GTID需要注意: 在构建主从复制之前,在一台将成为主的实例上进行一些操作(如数据清理等),通过GTID复制,这些在主从成立之前的操作也会被复制到从服务器上,引起复制失败(通过GTID复制都是从最先开始的事务日志开始,即使这些操作在复制之前执行)

  • GTID实际上是由UUID+TID (即transactionId)组成的

  • 其中UUID(即server_uuid) 产生于auto.conf文件(cat /opt/data/mysql/data/auto.cnf),是一个MySQL实例的唯一标识。

  • TID代表了该实例上已经提交的事务数量,并且随着事务提交递增,所以GTID能够保证每个MySQL实例事务的执行(不会重复执行同一个事务,并且会补全没有执行的事务)。

  • GTID在一组复制中,全局唯一。

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


GTID:7286f791-125d-11e9-9a9c-0050568843f8:10-362
UUID:7286f791-125d-11e9-9a9c-0050568843f8
transactionId:10-362 //事务id
Binlog_Do_DB 要执行的数据库
Binlog_Ignore_DB 忽略数据库
Executed_Gtid_Set 已经执行gtid的集合
  
在整个复制架构中GTID 是不变化的,即使在多个连环主从中也不会变  
  • 了解了GTID的格式,通过UUID可以知道这个事务在哪个实例上提交的。通过GTID可以极方便的进行复制结构上的故障转移,新主设置

  • 如图,事务id是一样的,S2执行完了,S3读到1493时S1崩溃

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

  • 由于同一事务的GTID在所有节点上的值一致,那么根据Server3当前停止点的GTID就能定位到Server2上的GTID。甚至由于MASTER_AUTO_POSITION功能的出现,我们都不需要知道GTID的具体值,直接使用CHANGE MASTER TO MASTER_HOST=‘xxx’, MASTER_AUTO_POSITION (自动找位置)命令就可以直接完成``failover` (故障转移)的工作。

  • GTID在binlog中的结构

  • GTID event 结构

  • gtid–开始–事件1,事件2–提交

  • Previous_gtid_log_event

    • Previous_gtid_log_event 在每个binlog 头部都会有每次binlog rotate(滚动)的时候存储在binlog头部Previous-GTIDs(之前的gtid)在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个步骤,直到找到为止。从最后一个往上找。

2. GTID相关参数
参数comment
gtid_executed执行过的所有GTID
gtid_purged丢弃掉的GTID
gtid_modegtid_modeGTID模式
gtid_nextsession级别的变量,下一个gtid
gtid_owned正在运行的GTID
enforce(执行)_gtid_consistency(一致性)保证GTID安全的参数
3. 开启GTID的必备条件
gtid_mode=on    (必选)
enforce-gtid-consistency=1  (必选)
log_bin=mysql-bin           (可选)#高可用切换,最好开启该功能
log-slave-updates=1 (可选)#高可用切换,最好打开该功能//将写的功能打开,从库
4. 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找点儿了。

4.1 GTID的工作流程为:
  • master更新数据时,会在事务前产生GTID,一同记录到binlog日志中。
  • slave端的i/o 线程将变更的binlog,写入到本地的relay log(中继日志)中。
  • sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录。
  • 如果有记录,说明该GTID的事务已经执行,slave会忽略。
  • 如果没有记录,slave就会从relay log(从库的i/o线程会请求主库的binlog日志,主库会发过来,记录到另一个位置)中执行该GTID的事务,并记录到binlog。
  • 在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描。
5. GTID主从配置 5.1 环境
数据库角色IP应用与系统版本
主数据库192.168.232.134Red Hat Enterprise Linux release 8.5 (Ootpa)
mysql-5.7
从数据库192.168.232.128Red Hat Enterprise Linux release 8.5 (Ootpa)
mysql-5.7
5.2 主库配置
[root@134h ~]# vim /etc/my.cnf 
[root@134h ~]# 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
skip-name-resolve 
sql-mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

log-bin = mysql_bin
server-id = 10
gtid_mode = on
enforce-gtid-consistency = true
log-slave-updates = on

重启
[root@134h ~]# systemctl restart mysqld
[root@134h ~]# 
5.3 从库配置。vi /etc/my.cnf, 添加以下配置,重启mysql。
[root@128m ~]# vim /etc/my.cnf 
[root@128m ~]# cat /etc/my.cnf 
[mysqld_multi]
mysqld = /usr/local/mysql/bin/mysqld_safe
mysqladmin = /usr/local/mysql/bin/mysqladmin

[mysqld3306]
datadir = /opt/data/3306
port = 3306
socket = /tmp/mysql3306.sock
pid-file = /opt/data/3306/mysql_3306.pid
log-error = /var/log/3306.log

server-id = 20
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@128m ~]# systemctl restart sql3306
[root@128m ~]# 
5.4 主库授权复制用户。
mysql>  grant replication slave on *.* to 'repl'@'192.168.232.128' identified by 'run123456';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> 
5.5 从库设置要同步的主库信息,并开启同步。
mysql> change master to master_host='192.168.232.134',master_user='repl',master_password='run123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> 
6. 测试
主
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.12 sec)

mysql> create database school;
Query OK, 1 row affected (0.00 sec)

从
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| school             |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

mysql>   
转载请注明:文章转载自 www.mshxw.com
本文地址:https://www.mshxw.com/it/1006867.html
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号