简单误操作恢复

MySQL误操作后的恢复

场景:
1、数据库每天都有全备份。
2、数据库开启bin-log
3、准确定位误操作语句

一、 创建全备份,建议带有 --master-data=2参数
mysqldump -uroot -ppassword123 -S /data/mysqldata/3306/mysql.sock -F -R --triggers --lock-tables --master-data=2 -B test > /data/mysqldata/backup/test.$(date "+%F_%H:%M:%S").full.sql

二、正常使用数据库

[[email protected] backup]# mysql -uroot -ppassword123 -S /data/mysqldata/3306/mysql.sock
Warning: Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 43
Server version: 5.6.41-log Source distribution

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type ‘help;‘ or ‘\h‘ for help. Type ‘\c‘ to clear the current input statement.

mysql>
mysql>
mysql> use test6;
ERROR 1049 (42000): Unknown database ‘test6‘
mysql> use test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| t_idb_big      |
| test1          |
| test2          |
| test3          |
| test4          |
| test5          |
| test6          |
+----------------+
7 rows in set (0.00 sec)

mysql> select count from test6;
ERROR 1054 (42S22): Unknown column ‘count‘ in ‘field list‘
mysql> select count(*) from test6;
+----------+
| count(*) |
+----------+
|    30161 |
+----------+
1 row in set (0.02 sec)

mysql>
mysql>
mysql> select count(*) from t_idb_big;
+----------+
| count(*) |
+----------+
|    30161 |
+----------+
1 row in set (0.01 sec)

mysql> 

三、发生误操作,单其他操作还在进行

mysql>
mysql> delete from test6;
Query OK, 30161 rows affected (1.14 sec)

mysql>
mysql>
mysql>
mysql>
mysql> desc test5;
+-------+------------------+------+-----+---------+----------------+
| Field | Type             | Null | Key | Default | Extra          |
+-------+------------------+------+-----+---------+----------------+
| id    | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| name  | char(20)         | YES  |     | NULL    |                |
+-------+------------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> select * from test5;
+----+------+
| id | name |
+----+------+
|  3 | a    |
|  4 | b    |
+----+------+
2 rows in set (0.00 sec)

mysql> insert into test5 (name) values (‘c‘);
Query OK, 1 row affected (0.00 sec)

mysql> insert into test5 (name) values (‘d‘);
Query OK, 1 row affected (0.00 sec)

mysql> select * from test5;
+----+------+
| id | name |
+----+------+
|  3 | a    |
|  4 | b    |
|  5 | c    |
|  6 | d    |
+----+------+
4 rows in set (0.00 sec)

四、发现误操作后,及时锁库,尽快修复

mysql>
mysql>
mysql>
mysql> flush tables with read lock;
Query OK, 0 rows affected (0.46 sec)

mysql>
mysql>
mysql> exit
Bye
[[email protected]localhost backup]# ls -ralt
total 35940
drwxrwxr-x. 2 mysql mysql        6 Sep 15 16:14 3306
-rw-rw-r--. 1 mysql mysql  5568942 Sep 15 16:56 test_3306_2018-09-15.sql
drwxrwxr-x. 2 mysql mysql       73 Sep 15 17:27 mysql_full
drwxrwxr-x. 3 mysql mysql       50 Sep 15 18:45 mysql_full_by_dbs
drwxrwxr-x. 3 mysql mysql       18 Sep 15 19:25 mysql_full_by_tbs
-rw-r--r--  1 mysql mysql  6227100 Jan 27 15:24 all.sql
-rw-r--r--  1 mysql mysql   659215 Jan 27 15:42 mysql.sql.2019-01-27
-rw-r--r--  1 mysql mysql  5568897 Jan 27 15:43 test.sql.2019-01-27
-rw-r--r--  1 mysql mysql   180873 Jan 27 15:54 mysql.2019-01-27.sql.gz
-rw-r--r--  1 mysql mysql   422535 Jan 27 15:54 test.2019-01-27.sql.gz
-rw-r--r--  1 mysql mysql   180873 Jan 27 15:59 mysql..sql.gz
-rw-r--r--  1 mysql mysql   422535 Jan 27 15:59 test..sql.gz
-rw-r--r--  1 mysql mysql   180873 Jan 27 15:59 mysql.2019-01-27_15:59:24.sql.gz
-rw-r--r--  1 mysql mysql  5568942 Jan 27 15:59 test.2019-01-27_15:59:25.sql
drwxr-xr-x. 8 mysql mysql       83 Jan 30 13:54 ..
-rw-r--r--  1 root  root    658544 Jan 30 16:50 rep.sql
drwxr-xr-x. 6 mysql mysql     4096 Jan 31 18:51 .
-rw-r--r--  1 root  root  11131595 Jan 31 18:51 test.2019-01-31_18:51:43.full.sql

-- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000027‘, MASTER_LOG_POS=120;

五,定位误操作,并找到位置点,对binlog做拆分操作

mysqlbinlog mysql-bin.000027 -d test --start_position=120 -r bin.sql

vi bin.sql
找到误操作语句,并删除它

六、全备份恢复+binlog曾量恢复


[[email protected] backup]# mysql -uroot -ppassword123 -S /data/mysqldata/3306/mysql.sock <test.2019-01-31_18:51:43.full.sql
Warning: Using a password on the command line interface can be insecure.
[[email protected] backup]#
[[email protected] backup]#
[[email protected] backup]# mysql -uroot -ppassword123 -S /data/mysqldata/3306/mysql.sock < /data/mysqldata/3306/binlog/bin.sql 

原文地址:http://blog.51cto.com/accole/2348273

时间: 2024-11-07 15:20:15

简单误操作恢复的相关文章

delete、update忘加where条件误操作恢复过程演示

update.delete没有带where条件,误操作,如何恢复呢? 我现在有一张学生表,我要把小于60更新成不及格. 1 mysql> select * from student; 2 3 +----+------+-------+-------+ 4 5 | id | name | class | score | 6 7 +----+------+-------+-------+ 8 9 | 1 | a | 1 | 56 | 10 11 | 2 | b | 1 | 61 | 12 13 |

Oracle数据库常见的误操作恢复方法(上)

实验环境:Linux6.4 + Oracle 11g 面向读者:Oracle开发维护人员 本文以Oracle自带的scott用户进行演示: 首先逻辑备份导出scott的对象数据 $ exp scott/tiger file='/u01/app/backup/scott.dmp' log='/u01/app/backup/scott.log' owner=scott; 1.误操作drop了emp表 利用表级闪回恢复,只要回收站中有就可以恢复. SQL> drop table emp; Table

Mysql误操作恢复流程

一.开启binlog. show variables like 'log_bin'; #vim  /etc/my.cnf 在[mysqld]中加入 log-bin                 = mysql-binlog-bin                 = /usr/local/mysql/log/mysql-bin.log 重启mysql服务 #service mysqld stop#service mysqld start 二.数据写入 建库 create database ba

SQL 误操作恢复实验

直接通过SQL语句恢复有两个必需的条件: 一.数据库在创建之后做过一次完整的备份: 二.数据库的恢复模式(Recovery mode)是"完整(Full)". 恢复步骤: 1.BACKUP LOG [DataBase] TO disk= N'D:\testlog' WITH NORECOVERY 备份当前日志,在出现误操作时一定要先备份当前日志 2.RESTORE DATABASE  [DataBase] FROM DISK = 'd:\test' WITH NORECOVERY, 

MySQL 误操作后数据恢复(update,delete忘加where条件)

在数据库日常维护中,开发人员是最让人头痛的,很多时候都会由于SQL语句写的有问题导致服务器出问题,导致资源耗尽.最危险的操作就是在做DML操作的时候忘加where条件,导致全表更新,这是作为运维或者DBA的我们改如何处理呢?下面我分别针对update和delete操作忘加where条件导致全表更新的处理方法. 一. update 忘加where条件误操作恢复数据(binglog格式必须是ROW) 1.创建测试用的数据表 mysql> create table t1 ( -> id int un

SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持2008及更高版本,这

【转】SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

4号,公司的生产数据表被全部删除,目前没有找到原因,由于刚接触SQL不久,所以短时间内不会还原,也不敢动被原服务器,于是就将原服务器停掉,拷贝出里面的PPD数据库文件,留作备份:近几天在自己的电脑上尝试修复,一直没有成功,细读了一下<SQL2005技术内幕——存储引擎>了解到删除列.删除表这些操作不会直接对每一行数据进行操作,而是直接改变他们的物理指向地址的ID,专业术语我也不是很清楚,我的理解是这样的,有时间再弄清楚,不过这足以让我明白被删除的表还是存在mdf文件中,其改变的便宜地址记录在日

binlog-rollback.pl 在线恢复update 和delete不加条件误操作sql

一.binlog-rollback.pl工具介绍 是perl开发的脚本工具,此工具主要是生成反向的DML sql语句: #基于row模式的binlog,生成DML(insert/update/delete)的rollback语句 #通过mysqlbinlog -v 解析binlog生成可读的sql文件 #提取需要处理的有效sql #"### "开头的行.如果输入的start-position位于某个event group中间,则会导致"无法识别event"错误 #将

SCPPO:SQL误操作如何恢复?

[前言] 今天研究项目中自己有疑惑的一块儿内容应该是这个系统的核心-数据从上传的Access中解析出来(ETL的贡献)经过一系列的存储过程将数据放到数据库表中(每天凌晨都会定时的执行这一系列操作)这只是今天的引子,不具体深入的讲解下去,小编会在接下来的博文中更加深入的为大家分享: 在分析这块儿的时候无意在服务器上发现一款软件-ApexSQL Log:之前没接触过出于好奇就去网上查了一下它是干嘛用的,这一查不要紧,又燃起了自己新的兴趣,仿佛一切的一切上天冥冥之中自有安排!为何这么说?小编下面为大家