MySQL5.7下面,误操作导致的drop table db1.tb1; 的恢复方法:

MySQL5.7下面,误操作导致的drop table db1.tb1; 的恢复方法:

0、停业务数据写入。【iptables封禁】

1、从备份服务器上拉取最新的一个全备文件,恢复到一个临时的服务器上,解压并启动mysqld。

2、在这台新的slave上执行如下命令:

2.1 先配置好复制关系, change master to 到当前误操作的服务器,但是不要启动复制进程。【类似如下命令】

>CHANGE MASTER TO 
MASTER_HOST='172.16.20.73',
MASTER_USER='rpl',
MASTER_PASSWORD='rpl',
master_log_file='master-bin.000005',
master_log_pos=245;

2.2 在新的slave上执行复制过滤操作:

> CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE = ('db1.tb1');

2.3 开启slave 复制,到出问题的地方之前停下来

> start slave io_thread ;
> start slave sql_thread until master_LOG_FILE='mysql-bin.000010',master_LOG_POS=10020;   -- 执行到最后一次没问题的位移点

2.4 在slave上跳过这个误操作的事务

> set GTID_NEXT='56bc2f04-7556-11e8-b3b6-000c29ba98ce:1492' ;  -- 这里的这个就是应该跳过的那个事务(可以从主库的binlog里面找到这个gtid编号)
> begin ;
> commit ;
> set GTID_NEXT="AUTOMATIC";
> start slave ;
> show slave status \G 查看复制情况

2.5 将这个从库的db1.tb1 通过mysqldump方式导出,然后倒入到线上误操作的实例里面。 【大表的话,可以用xtrabackup备份单表,然后import倒入表空间来完成数据的倒入】

原文地址:http://blog.51cto.com/lee90/2142562

时间: 2024-07-30 23:12:27

MySQL5.7下面,误操作导致的drop table db1.tb1; 的恢复方法:的相关文章

一次误操作导致的gi psu升级失败

oracle使用opatch auto的方式安装gi psu时需要一个节点一个节点来,昨晚的升级中,因为误操作而是两节点同时安装gi psu,最终在补丁安装完成后,无法拉起crs. 选择进行补丁的rollback,结果悲剧的发现rollback的前提是需要crs启动的状态,无奈之下只能进行备份文件的恢复了. 不过因为意识的疏忽,压缩$oracle_home目录和$grid_home目录时没有使用root用户,导致部分文件没有备份出来. 以后打类似的psu,有两个注意点: 第一,一定要一个节点一个

SQL SERVER 还原误操作导致还原无法停止,处理办法

昨天遇到运行库不知道单位哪个小伙子,把数据库还原了,导致单位业务全部瘫痪,主数据库一直显示正在还原,真的是不敢动,经过多方寻找,找到此脚本-------------------------数据库还原日志,导致数据库一直在正在还原状态,运行此脚本有一定的几率可以恢复RESTORE database YXHIS_BAK(库名) with recovery RESTORE database YXHIS_BAK(库名) with norecovery 原文地址:https://www.cnblogs.c

oracle数据库产生误操作,将一个字段置空了,恢复数据

工作的时候没仔细检查sql直接执行了,将线上的数据弄错了,发现抓紧修改,还好只修改了一个表的一列: 在网上查了下oracle可以查询24小时任何时刻的数据 select * from btgl_ylbt_sqb t as of timestamp to_timestamp('2018-01-24 10:56:00','yyyy-mm-dd hh24:mi:ss'); --查询到此时数据 --将这列恢复到这个时刻 update btgl_ylbt_sqb sqb   set sqb.duratio

电路板损坏导致电脑识别不到硬盘怎么恢复

· · · 硬盘电路板损坏会导致电脑无法识别硬盘.硬盘连接电脑没有任何反应,是数据恢复工作中遇到的一种很常见的硬盘故障表现,针对这一故障情况可以按照如下方法进行硬盘故障检测和数据恢复.· · · 首先给硬盘加电,观察硬盘加电后的状态是否为无法识别.然后仔细观察硬盘的电路板是否完好,如果电路板内的ROM芯片.驱动芯片等重要模块没有损坏的话只需更换损坏的其他模块尝试修复即可,如果ROM芯片或者驱动芯片等重要模块已经损坏则情况比较严重,需要根据电路板的匹配要求全面更换和修复电路板,这个过程就会更加复杂

当数据被误删除/误操作后造成数据丢失。你尝试过用什么手段来挽救数据/损失?

一.前提 当数据被误删除/误操作后,第一时间要关闭数据库.业务方需要紧急挂停机公告,避免数据二次污染,用于保护数据的一致性 BINLOG格式为ROW格式,不讨论其他格式的BINLOG 二.数据被误操作(update/delete/drop)造成数据丢失,可以用哪些手段来恢复? BINLOG恢复:可以使用逆向解析BINLOG工具来恢复.例如:binlog2SQL等 延迟从库: 可以通过解除延迟从库,并指定BINLOG结束位置点,可以实现数据恢复 三.数据被误删除(rm/物理文件损坏)造成数据丢失,

MySQL【Update误操作】回滚(转)

前言:      继上一篇MySQL[Delete误操作]回滚之后,现在介绍下Update回滚,操作数据库时候难免会因为“大意”而误操作,需要快速恢复的话通过备份来恢复是不太可能的,因为需要还原和binlog差来恢复,等不了,很费时.这里说明因为Update 操作的恢复方法:主要还是通过binlog来进行恢复,前提是binlog_format必须是Row格式,否则只能通过备份来恢复数据了.和上一篇的条件一样.方法:     条件:开启Binlog,Format为Row.     步骤:1.通过M

ApexSQL Log-SQL误操作恢复工具

原文:ApexSQL Log-SQL误操作恢复工具 今天不小心对数据库执行了一次误操作,心想有没有什么工具能恢复这次误操作呢?于是找到了Log Explorer 4.2,可惜它最多只支持SQL 2005,在SQL 2008上无法使用,然后又找到了ApexSQL Log,最新版本最高支持SQL 2008以及SQL 2012,试用版可以提供功能无限制14天的免费试用期,功能倒真是强大 直接下载安装,官方下载地址:http://www.apexsql.com/sql_tools_log.aspx 安装

oracle11g系统级别触发器来跟踪监控drop误操作

前言: db中有一张表的数据老是紊乱,猜猜是经历过drop.create的数据同步操作,但是现在谁也不知道在哪里操作的,所以准备做一个触发器去记录下是哪个应用服务器那个db账号操作的. 3,系统级别触发器 3.1 触发事件 包括各种DDL操作以及各种数据库事件,ddl包括create.alter.drop.rename.grant.revoke.audit.noaudit.commit.truncate.analyze.associate statistics.disassociate stat

请列出你在从事IT生涯中,最难以忘怀的一次误操作

IT系统最怕什么,我觉得就两点: 1.不可靠的软硬件. 2.误操作. 第一点就不用解释了,第二点是该文的内容,主要摘选自ITPUB的精华贴——[精华] 请列出你在从事DBA生涯中,最难以忘怀的一次误操作 中摘录各位网友的经验和教训,常看看以警惕自己. #2 一次一个session占用内存很大,这个session id比较大,所以以为是用户进程,kill, 则库立刻down了,查日志后,才知道是一个后台进程,但详细是哪个进程,现在忘记了. 好的是库起来了,这个故障,我一直牢记于心. 现在做任何操作