通过延时从库+binlog复制,恢复误操作数据

通过延迟复制与binlog恢复意外删除的数据

一、环境概述

以下是我们操作的数据库环境的详细信息:

数据库版本 实例角色 IP地址 端口
GreatSQL 8.0.32-26 主库 192.168.134.199 5725
GreatSQL 8.0.32-26 从库 192.168.134.199 5726

二、主库设置

在主库上,我们首先需要创建一个复制用户并授权:

shell> /usr/local/greatsql/bin/mysql -S /tmp/mysql5725.sock -p
greatsql> CREATE USER 'repl'@'%' IDENTIFIED BY '123';
greatsql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

三、配置延迟从库

接下来,我们配置从库以实现延迟复制:

greatsql> CHANGE MASTER TO
    MASTER_HOST='192.168.134.199',
    MASTER_PORT=5725,
    MASTER_USER='repl',
    MASTER_PASSWORD='123',
    MASTER_AUTO_POSITION=1,
    MASTER_DELAY=7200;
greatsql> START SLAVE;
greatsql> SHOW SLAVE STATUSG

file

四、模拟主库数据表误删除

我们模拟一个误删除操作,如下:

shell> /usr/local/greatsql/bin/mysql -S /tmp/mysql5725.sock -p sysbench
greatsql> DROP TABLE sbtest2;

五、从延迟从库恢复数据至主库故障前状态

  1. 备份从库:为防止恢复过程中出现意外,我们首先使用Xtrabackup备份从库:
$ xtrabackup --defaults-file=/data1/greatsql/greatsql5726/my5726.cnf -S /tmp/greatsql5726.sock --backup --slave-info 
    --stream=xbstream --target-dir=/backup/full.xb
  1. 定位误操作的binlog:我们需要找到主库误操作所在的binlog文件,并确认其位置信息:
$ /usr/local/greatsql/bin/mysqlbinlog --no-defaults --base64-output=decode-rows -vvv ./* | grep -rli 'drop'
$ /usr/local/greatsql/bin/mysqlbinlog --no-defaults --base64-output=decode-rows -vvv mysql-bin.000002 | less

file

  1. 停止sql_thread线程:设置复制不延时,并在误操作binlog位置点停止复制:
shell> /usr/local/greatsql/bin/mysql -S /tmp/mysql5726.sock -p
greatsql> STOP SLAVE;
greatsql> CHANGE MASTER TO MASTER_DELAY = 0;
greatsql> START SLAVE IO_THREAD;
greatsql> START SLAVE SQL_THREAD UNTIL SQL_BEFORE_GTIDS='2fc5a82c-2ac3-11ee-9f7f-00163e402951:187';
greatsql> SHOW SLAVE STATUSG
  1. 等待复制停止:等待复制到达指定的停止位置点,此时sql_thread线程已停止。

file

  1. 备份误操作的表:查看从库中误操作的表,并备份以便恢复到主库:
greatsql> SHOW TABLES FROM sysbench;
greatsql> SELECT COUNT(*) FROM sysbench.sbtest2;
shell> /usr/local/greatsql/bin/mysqldump -S /tmp/mysql5726.sock --set-gtid-purged=OFF --single-transaction --master-data=2 --max-allowed-packet=32M -q sysbench sbtest2 > sbtest2.sql
  1. 恢复备份数据至主库

```sql
shell> /usr/local/greatsql/bin/mysql -S /tmp/mysql5725.sock -p -A sysbench
greatsql> SET sql_log_bin = off;
greatsql> SOURCE sbtest2.sql

文章整理自互联网,只做测试使用。发布者:Lomu,转转请注明出处:https://www.it1024doc.com/4301.html

(0)
LomuLomu
上一篇 2024 年 12 月 24 日 下午2:42
下一篇 2024 年 12 月 24 日

相关推荐

  • 手动部署前后端分离的项目到本地

    1.准备工作 使用maven打包springboot项目为.jar文件得到springboot-0.0.1-SNAPSHOT.jar 打包vue项目 npm install -g @vue/cli安装Vue CLI 在项目根目录下,运行npm run build命令来构建项目得到一个dist文件夹 将打包好的文件通过远程仓库中转至docker虚拟机 在虚拟机…

    2025 年 1 月 11 日
    11400
  • 手动部署前后端分离的项目到本地

    1.准备工作 使用maven打包springboot项目为.jar文件得到springboot-0.0.1-SNAPSHOT.jar 打包vue项目 npm install -g @vue/cli安装Vue CLI 在项目根目录下,运行npm run build命令来构建项目得到一个dist文件夹 将打包好的文件通过远程仓库中转至docker虚拟机 在虚拟机…

    2025 年 1 月 11 日
    9800
  • 履约系统:应用层、领域层、集成关系设计

    大家好,我是汤师爷~ 在这篇文章中,我们一起探讨订单履约系统的应用架构设计。 应用架构设计 我们前面讨论了系统的核心概念模型和拆单逻辑。接下来,让我们从应用架构的角度,深入了解系统的各个层次。这包括应用层、领域层,以及与其他系统的集成关系。 应用层能力 应用层定义软件的应用功能,它负责接收用户请求,协调领域层能力来执行任务,并将结果返回给用户,核心模块包括:…

    2025 年 1 月 6 日
    16700
  • GreatSQL temp文件占用时长分析

    GreatSQL temp文件占用时长分析 GreatSQL DBA在日常工作中可能会遇到这种情况,存在一个 InnoDB 引擎下的 temp_x.ibt 文件很大,但是却无法确定这个文件是什么时间由哪个连接建立的,难以支撑后续定位问题,今天这篇文章彻底讲明白这个问题。 现象:发现一个实例下面(4406端口对外提供服务的实例)temp文件很大,如下所示: `…

    2025 年 1 月 12 日
    16300
  • Java之反射

    目录 反射 定义 主要用途 反射相关的类 Class类中【获得类相关方法】 Class类中【获得类中属性相关的方法】 Class类中【获得类中注解相关的方法】 Class类中【获得类中构造器相关的方法】 Class类中【获得类中方法相关的方法】 获得Class对象 代码示例1 代码示例2 反射的优缺点 反射 定义 Java的反射(reflection)机制是在…

    2024 年 12 月 28 日
    12400

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

联系我们

400-800-8888

在线咨询: QQ交谈

邮件:admin@example.com

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信