概念:
说事务的隔离级别之前,应该先说清楚事务

事务是一组具有统一逻辑功能的语句的组合。
事务具有4个特点:
原子性、隔离性、永久性、一致性
原子性 变更的执行结果具有统一性、全部执行ok、or not。
隔离性 事务执行完毕之前,对其他事物是不可见的
永久性 执行成功后永久生效
一致性 执行全部ok或者全部回退

文章目录
一、前言
二、操作流程

  1. 获取最后一个 GTID 操作
  2. 跳过一个事务
    三、案例
  3. 问题描述
  4. 原因分析
  5. 处理过程
    一、前言
    很多场景下我们需要跳过一个事务来修复主从关系,例如主从事务不一致,或者对无主键表更新,导致较大延迟,操作过程在此记录。

二、操作流程

  1. 获取最后一个 GTID 操作
    在 GTID 模式下,如果需要跳过一个事务,就需要先获得从库执行的最后一个 GTID 操作,可以通过下方几种方法获得:

    show slave status:

    Executed_Gtid_Set: 2102e47a-a63b-11eb-b2a1-fa85c353c300:1-68835,
    741e7d25-a5a2-11eb-a8d2-facd1b9d5200:1-1691060:1691062-1696109,
    aeccf6dc-c76d-11eb-a563-fab7dbe5cd00:1-38,
    eab37148-e44b-11eb-a993-fa85c353c300:1-2

这里主要看 Executed_Gtid_Set 变量。

show master status:

*************************** 1. row ***************************
File: mysql-bin.000014
Position: 234
Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 2102e47a-a63b-11eb-b2a1-fa85c353c300:1-68835,
741e7d25-a5a2-11eb-a8d2-facd1b9d5200:1-1691060:1691062-1696109,
aeccf6dc-c76d-11eb-a563-fab7dbe5cd00:1-38,
eab37148-e44b-11eb-a993-fa85c353c300:1-2
1 row in set (0.01 sec)

这里主要看 Executed_Gtid_Set 变量。

如果数据库有多次切换,Executed_Gtid_Set 中的 GTID SET 比较多,我们只看当前主库的 server_uuid 的 GTID SET 即可。
主库的 UUID 可以通过 select @@server_uuid; 查到。

  1. 跳过一个事务

    stop slave;
    set session gtid_next='72170331-ae27-11eb-b3a1-000c29169a83:96174';
    begin;commit;
    set session gtid_next='AUTOMATIC';
    start slave;

在 GTID 模式下,传统复制参数 sql_slave_skip_counter 不能使用。

三、案例

  1. 问题描述

    CREATE TABLE order_temp (
    order_code varchar(10) DEFAULT NULL,
    order_status varchar(255) DEFAULT NULL,
    order_time varchar(255) DEFAULT NULL,
    account_status varchar(255) DEFAULT NULL,
    receivable decimal(10,2) DEFAULT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

一张无主键表,开发想将 receivable 值全部修改为 3 因为测试环境,直接全表更新,在主库不到一分钟就执行成功了,没想到备库跑了两天都没有结束。

update order_temp set receivable = 3;
1

  1. 原因分析
    使用 row 模式复制 binlog 按行存储,回放的时候也是一行一行去改,因为该表没有主键索引,每一次修改都是一次全表扫描,一次全表扫描需要两秒,表中有 4998000 行数据:

4998000 * 2 / 3600 / 24 = 155 天

如果不处理的话,估计得跑上小半年,这个备库也算是废了。

  1. 处理过程
    确认主库 uuid 在主库查:

    root@mysql 14:43: [rep_test]>select @@server_uuid;
    +--------------------------------------+
    | @@server_uuid |
    +--------------------------------------+
    | 741e7d25-a5a2-11eb-a8d2-facd1b9d5200 |
    +--------------------------------------+
    1 row in set (0.00 sec)

确认从库最后一个事务:

*************************** 1. row ***************************
File: mysql-bin.000014
Position: 234
Binlog_Do_DB: 
Binlog_Ignore_DB: 
Executed_Gtid_Set: 
2102e47a-a63b-11eb-b2a1-fa85c353c300:1-68835,
741e7d25-a5a2-11eb-a8d2-facd1b9d5200:1-1691060:1691062-1696109,
aeccf6dc-c76d-11eb-a563-fab7dbe5cd00:1-38,
eab37148-e44b-11eb-a993-fa85c353c300:1-2
1 row in set (0.00 sec)

第二行就是该实例主库的 uuid 最后一个事务是 1696109

停止复制:
该步骤可能持续时间较长,这个和修改的数据量和延迟的时长有关系,此刻需要回滚已经应用的 event。

stop slave;

跳过复制:
刚才最后一个事务是 1696109 正在执行的事务就是 1696109 + 1 = 1696110

set session gtid_next='741e7d25-a5a2-11eb-a8d2-facd1b9d5200:1696110';
begin;commit;
set session gtid_next='AUTOMATIC';

修复数据
跳过事务,则主库的更新操作没有在从库应用,已经被回滚,此时可以手动在从库跑一下该 SQL。不同的场景有不用的修复方法,此时就跑原 SQL 即可。
修复数据时,要注意如果有级联复制,这种特殊操作前,临时会话级别关闭 binlog

set session sql_log_bin = 0;

重新启动复制

start slave;

启动后观察主从延迟情况。
————————————————

                        版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
                    

原文链接:https://blog.csdn.net/qq_42768234/article/details/121355272

天道自古就是穷者更穷,富者更富。
国际竞争中,落后就要挨打。
生物种群竞争中,适者生存,不适者消亡
游戏世界中,菜就是原罪
所有的存在竞争的地方,都有比较,也都有好坏
以弱胜强,就要打破规则,改变环境