通过延时从库+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 日

相关推荐

  • 【C++】深入解析explicit关键字的奥秘(从原理到实践全面掌握explicit的用法)

    目录导航一、开篇引言二、揭开explicit的神秘面纱三、构造函数的隐式转换机制🍏单参数构造函数的隐式转换🔍explicit关键字的引入契机🍊多参数构造函数的特殊情况🔍explicit的实际应用价值🔍explicit的正确使用姿势四、核心要点回顾五、学习寄语 一、开篇引言 在日常C++编程实践中,explicit关键字可能并不常见于我们的代码中。然而,在标准…

    2025 年 5 月 15 日
    37100
  • 架构师启示录:知识模型、落地方法与思维模式PDF、EPUB免费下载

    适读人群 :资深程序员、初级架构师 从架构知识模型、架构落地方法、架构思维模式三大维度介绍架构师的能力模型,带你穿越“认知迷雾” 电子版仅供预览,下载后24小时内务必删除,支持正版,喜欢的请购买正版书籍 点击原文去下载 书籍信息 作者: 灵犀出版社: 机械工业出版社出版年: 2024-3页数: 212装帧: 平装丛书: 架构师书库ISBN: 97871117…

    2025 年 1 月 11 日
    60700
  • 解决IDEA编译时“java: 找不到符号”错误的全面指南

    解决IDEA编译时”java: 找不到符号”错误的全面指南 团队新从Git仓库克隆的项目在IDEA中编译时出现”java: 找不到符号”错误,主要涉及对象getter/setter方法缺失问题。经过一番探索后找到解决方案,在此与大家分享~ 内容导航 问题背景 解决方案汇总 我们的实际解决方式 其他可能情况排查 Lombok插件检查 Lombok依赖确认 JD…

    未分类 2025 年 5 月 12 日
    51600
  • Java Druid 面试题

    Druid连接池在项目中有哪些优势? 性能优越:Druid采用了高效的连接管理机制,可以快速地创建和回收数据库连接,减少了连接的创建和销毁带来的性能开销。 监控与统计:Druid提供了详细的监控信息,包括连接池的状态、SQL执行的统计信息等,这有助于性能调优和问题诊断。 SQL日志记录:Druid内置了SQL执行日志记录功能,可以记录所有SQL语句的执行情况…

    未分类 2025 年 1 月 11 日
    66800
  • 【Java】异常处理见解,了解,进阶到熟练掌握

    各位读者,早安、午安、晚安! 如果您发现这篇文章对您有所启发,不妨点赞、评论、分享,您的支持是我不断进步的动力。也欢迎您将这篇文章推荐给更多人。 今天我们将深入探讨Java面向对象编程中的抽象类和接口,让我们一起来看看它们是如何协同工作的。 目录 1.(throws和throw)我们选择忽略这个异常,将其向外抛出 1.1:使用throws时的注意事项 1.2…

    2024 年 12 月 28 日
    52000

发表回复

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

联系我们

400-800-8888

在线咨询: QQ交谈

邮件:admin@example.com

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

关注微信