• GTID主从


    GTID主从

    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 是不变化的,即使在多个连环主从中也不会变  
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 了解了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 (可选)#高可用切换,最好打开该功能//将写的功能打开,从库
    
    • 1
    • 2
    • 3
    • 4

    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 环境

    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 ~]# 
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21

    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 ~]# 
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25

    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> 
    
    • 1
    • 2
    • 3
    • 4

    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> 
    
    • 1
    • 2
    • 3
    • 4

    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>   
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
  • 相关阅读:
    m基于GA遗传优化的GRNN广义回归神经网络销售数据预测算法matlab仿真
    建设基础设施Terraform
    【计算商品总价~python+】
    栈与队列的简单实现(stack and queue)
    【Bug】8086汇编学习
    【个人成长】001- 4 个步骤提升你的复盘能力
    鉴源论坛 · 观擎丨基于模型的方法在民机机载软件中的应用
    后端php项目和数据库启动
    MFC树控件的属性和初始化(基于对话框的编程)
    杰理之上电池工位容易 出现不开机【篇】
  • 原文地址:https://blog.csdn.net/mushuangpanny/article/details/125610280