GTID 模式 - 通过跳过事务解决主从故障

文若2年前技术文章941

一、前言

很多场景下我们需要跳过一个事务来修复主从关系,例如主从事务不一致,或者对无主键表更新,导致较大延迟,操作过程在此记录。

二、操作流程

1. 获取最后一个 GTID 操作

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

  1. 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 变量。

  2. 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; 查到。

2. 跳过一个事务

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;

2. 原因分析

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

4998000 * 2 / 3600 / 24 = 155 天

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

3. 处理过程

  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)
  2. 确认从库最后一个事务:

    *************************** 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

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

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

    set session gtid_next='741e7d25-a5a2-11eb-a8d2-facd1b9d5200:1696110';
    begin;commit;
    set session gtid_next='AUTOMATIC';
  5. 修复数据 跳过事务,则主库的更新操作没有在从库应用,已经被回滚,此时可以手动在从库跑一下该 SQL。不同的场景有不用的修复方法,此时就跑原 SQL 即可。 修复数据时,要注意如果有级联复制,这种特殊操作前,临时会话级别关闭 binlog

    set session sql_log_bin = 0;
  6. 重新启动复制

    start slave;

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

阅读剩余的53%

相关文章

CDP实操--配置KNOX SSO(五)

CDP实操--配置KNOX SSO(五)

1.1配置Atlas的SSO身份验证在Knox SSO的topology里配置Knox与LDAP集成认证如下,并重启Knox服务role=authenticationauthentication.na...

nginx服务企业应用

1、软件的分类1.1 常用来提供静态服务的软件Apache :这是中小型Web服务的主流,Web服务器中的老大哥,Nginx :大型网站Web服务的主流,曾经Web服务器中的初生牛犊,现已长大。Ngi...

Kubernetes源码解读(四)--Lister&Watcher源码分析

Kubernetes源码解读(四)--Lister&Watcher源码分析

Lister&&Watcher是Reflector的一个主要能力提供者,我们来看看Lister&&Watcher是如何实现List()和watch()的过程的。List...

MySQL 复制延迟是如何计算的?

MySQL 复制延迟是如何计算的?

前言日常运维中总会收到 MySQL 备库延迟告警,一般数据库监控只读实例延迟都是采集 Seconds_Behind_Master 值,我们都知道它在某些场景下不可靠,今天一起探索 MySQL 是如何计...

Seatunel 集群部署

Seatunel 集群部署

1、基础环境准备java 1.8 并配置java home操作系统:centos7.9下载安装包:https://www.apache.org/dyn/closer.lua/seatunnel/2.3...

Mysql备份及恢复-XtraBackup

Mysql备份及恢复-XtraBackup

1、下载备份软件#不能使用8.0的版本,不支持mysql8.0之前的备份wget -c https://downloads.percona.com/downloads/Percona-XtraBack...

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。