mysql undo 和redo 被误删除的恢复操作(一致性)
今天在群里看到有人说不熟悉innodb把ibdata(数据文件)和ib_logfile(事务日志)文件误删除了。不知道怎么解决。当时我也不知道怎么办。后来查阅相关资料。终找到解决方法。其实恢复也挺简单的。我们不知道的时候就觉得难了。谁说不是这样呢?
下面我们就来模拟生产环境下,人为删除数据文件和重做日志文件。然后详细说明恢复步骤。
1.用sysbench模拟数据的写入,如下所示:

[root@yayun-mysql-server ~]# sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --init-rng=on --num-threads=16 --max-requests=0 --oltp-dist-type=uniform --max-time=1800 --mysql-user=root --mysql-socket=/tmp/mysqld.sock --mysql-password=123456 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex prepare
sysbench 0.4.10: multi-threaded system evaluation benchmark Creating table 'sbtest'...
Creating 1000000 records in table 'sbtest'...

2.使用命令rm -f ib*删除数据文件和事务日志文件:

[root@yayun-mysql-server mysql]# ls
employees ib_logfile1 mysql-bin.000003 mysql-bin.000008 performance_schema world_innodb yayun-mysql-server.pid
general.log menagerie mysql-bin.000004 mysql-bin.000009 sakila world_myisam
host mysql mysql-bin.000005 mysql-bin.000010 sbtest xtrabackup_binlog_pos_innodb
ibdata1 mysql-bin.000001 mysql-bin.000006 mysql-bin.index slow-query.log yayun
ib_logfile0 mysql-bin.000002 mysql-bin.000007 percona test yayun-mysql-server.err
[root@yayun-mysql-server mysql]# rm -f ib*
[root@yayun-mysql-server mysql]#

下面我们来看看如何恢复:
若此时发现数据库还能正常工作,数据依然可读可写,切记:这个时候千万不要把mysqld进程杀死,否则真没法挽救了,你就等着哭吧。

(root@yayun 20:42:25pm> ) [yayun]>select * from t1;
+----+-------+
| id | name |
+----+-------+
| 1 | yayun |
| 2 | atlas |
| 3 | mysql |
+----+-------+
3 rows in set (0.00 sec) (root@yayun 20:42:28pm> ) [yayun]>insert into t1 select 4,'python';
Query OK, 1 row affected (0.01 sec)
Records: 1 Duplicates: 0 Warnings: 0 (root@yayun 20:42:48pm> ) [yayun]>select * from t1;
+----+--------+
| id | name |
+----+--------+
| 1 | yayun |
| 2 | atlas |
| 3 | mysql |
| 4 | python |
+----+--------+
4 rows in set (0.00 sec) (root@yayun 20:42:50pm> ) [yayun]>

我这里读写都正常。所以我们能够恢复成功的。
(1)首先,先找到mysqld进程的pid,如下所示:
[root@yayun-mysql-server ~]# netstat -nltp | grep mysqld
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 5725/mysqld
[root@yayun-mysql-server ~]#
可见mysqld的pid是5725,这一步是关键的一步。
(2)使用如下命令查看结果(非常重要)
[root@yayun-mysql-server ~]# ll /proc/5725/fd | egrep 'ib_|ibdata'
lrwx------. 1 root root 64 Apr 30 20:44 10 -> /data/mysql/ib_logfile1 (deleted)
lrwx------. 1 root root 64 Apr 30 20:44 4 -> /data/mysql/ibdata1 (deleted)
lrwx------. 1 root root 64 Apr 30 20:44 9 -> /data/mysql/ib_logfile0 (deleted)
[root@yayun-mysql-server ~]#
这里有相关很重要的知识,童鞋们自行查阅,删除一个文件时,并不是真正删除,而是打一个标记,同样在我们mysql数据库中,delete一条记录实际的删除操作也没有发生。
上面显示的结果中,其中10,4,9就是我们需要恢复的文件。
(3)在恢复文件前,需要执行flush tables with read lock,确保数据库没有写入操作,以便我们完成恢复
(root@yayun 20:55:26pm> ) [(none)]>flush tables with read lock;
Query OK, 0 rows affected (0.00 sec) (root@yayun 20:55:31pm> ) [(none)]>
那么我们如何确定没有数据写入呢?分几个步骤查看
(1)设置脏页刷新比例(让脏页尽快刷新到磁盘)
(root@yayun 20:55:31pm> ) [(none)]>set global innodb_max_dirty_pages_pct=0;
Query OK, 0 rows affected (0.00 sec) (root@yayun 20:57:42pm> ) [(none)]>
(2)查看binlog日志写入情况,确保File和Position的值没有发生变化

(root@yayun 20:57:42pm> ) [(none)]>show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000010 | 61704130 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec) (root@yayun 20:59:11pm> ) [(none)]>

(3)查看innodb状态信息,确保脏页已经刷新到磁盘

(root@yayun 20:59:11pm> ) [(none)]>show engine innodb status\G
------------
TRANSACTIONS
------------
Trx id counter B9E0F
Purge done for trx's n:o < B9E0C undo n:o < 0 #确保后台线程purge把undo log全部清刷掉 -------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 2543, seg size 2545, 0 merges #确保合并插入缓存等于1 ---
LOG
---
Log sequence number 6173930288
Log flushed up to 6173930288 #确保这里三个值保持一致,并且不再变化
Last checkpoint at 6173930288 Buffer pool size 65534
Free buffers 50513
Database pages 15020
Old database pages 5506
Modified db pages 0 #确保脏页数量为0 --------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 5725, id 140014471358208, state: waiting for server activity
Number of rows inserted 1000004, updated 1995, deleted 0, read 2008
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s #确保插入,更新,删除为0

上面我们都确认后,就可以进行恢复操作了。记得前面我们查看要恢复的文件的命令吧,我们的mysqld进程的pid是5725,我们再次看看需要恢复的文件
[root@yayun-mysql-server ~]# ll /proc/5725/fd | egrep 'ib_|ibdata'
lrwx------. 1 root root 64 Apr 30 20:44 10 -> /data/mysql/ib_logfile1 (deleted)
lrwx------. 1 root root 64 Apr 30 20:44 4 -> /data/mysql/ibdata1 (deleted)
lrwx------. 1 root root 64 Apr 30 20:44 9 -> /data/mysql/ib_logfile0 (deleted)
[root@yayun-mysql-server ~]#
把10,4,9文件cp到原来mysql的数据目录下:
[root@yayun-mysql-server ~]# cd /proc/5725/fd
[root@yayun-mysql-server fd]# cp 10 /data/mysql/ib_logfile1
[root@yayun-mysql-server fd]# cp 4 /data/mysql/ibdata1
[root@yayun-mysql-server fd]# cp 9 /data/mysql/ib_logfile0
[root@yayun-mysql-server fd]#
修改文件权限

[root@yayun-mysql-server ~]# cd /data/mysql
[root@yayun-mysql-server mysql]# chown -R mysql.mysql ib*
[root@yayun-mysql-server mysql]# ll | egrep 'ib_|ibdata1'
-rw-r--r-- 1 mysql mysql 866123776 Apr 30 21:13 ibdata1
-rw-r--r-- 1 mysql mysql 67108864 Apr 30 21:13 ib_logfile0
-rw-r--r-- 1 mysql mysql 67108864 Apr 30 21:11 ib_logfile1
[root@yayun-mysql-server mysql]#

重启mysql,修复完成
[root@yayun-mysql-server mysql]# /etc/init.d/mysqld restart
Shutting down MySQL... [ OK ]
Starting MySQL.... [ OK ]
[root@yayun-mysql-server mysql]#
mysql undo 和redo 被误删除的恢复操作(一致性)的更多相关文章
- MySQL user表root用户误删除后恢复
mysql user表root 用户误删除后恢复root用户 方法/步骤 1.停止mysql服务:在mysql安装目录下找到my.ini:在my.ini中找到以下片段[mysqld]:另起一行加入代码 ...
- Mysql undo与redo Log
http://mysql.taobao.org/monthly/2015/04/01/ http://www.cnblogs.com/Bozh/archive/2013/03/18/2966494.h ...
- Oracle数据误删除的恢复操作
flashbackup 闪回操作: 1. 打开表的闪回功能: alter table dw_stg.fm_user_play_d enable row movement; 2. 查询要闪回的表的记录信 ...
- 误删除系列一:linux的bin目录误删除后恢复操作
感言:一失足成千古恨,一不小心就把/usr/bin下所有的命令都删除了,当你以为自己很熟练时,当你以为自己操作对时,可能就是失手的时候,还好这次只是一个测试环境....God 恢复过程:(以下是在vs ...
- 说说MySQL中的Redo log Undo log都在干啥
在数据库系统中,既有存放数据的文件,也有存放日志的文件.日志在内存中也是有缓存Log buffer,也有磁盘文件log file,本文主要描述存放日志的文件. MySQL中的日志文件, ...
- 详细分析MySQL事务日志(redo log和undo log)
innodb事务日志包括redo log和undo log.redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作. undo log不是redo log的逆向过程,其实它 ...
- MySql Undo Redo
Undo LogUndo Log 是为了实现事务的原子性,在MySQL数据库InnoDB存储引擎中,还用Undo Log来实现多版本并发控制(简称:MVCC). - 事务的原子性(Atomicity) ...
- 【转】说说MySQL中的Redo log Undo log都在干啥
阅读目录(Content) 1 undo 1.1 undo是啥 1.2 undo参数 1.3 undo空间管理 2 redo 2.1 redo是啥 2.2 redo 参数 2.3 redo 空间管理 ...
- 详细分析MySQL事务日志(redo log和undo log) 表明了为何mysql不会丢数据
innodb事务日志包括redo log和undo log.redo log是重做日志,提供前滚操作,undo log是回滚日志,提供回滚操作. undo log不是redo log的逆向过程,其实它 ...
随机推荐
- springboot(十二):springboot单元测试、打包部署
单元测试 1.在pom包中添加spring-boot-starter-test包引用 <dependency> <groupId>org.springframework.boo ...
- Python排序算法之选择排序
选择排序 选择排序比较好理解,好像是在一堆大小不一的球中进行选择(以从小到大,先选最小球为例): 1. 选择一个基准球 2. 将基准球和余下的球进行一一比较,如果比基准球小,则进行交换 3. 第一轮过 ...
- VxWorks Fuzzing 之道:VxWorks 工控实时操作系统漏洞挖掘调试与利用揭秘
转载:freebuf 0×00 前言 关于VxWorks,这里引用44CON议题<攻击 VxWorks:从石器时代到星际>探究 一文章中的介绍: VxWorks 是世界上使用最广泛的一种在 ...
- jzoj4313 电话线铺设(最小生成树+最近公共祖先)
题面 \(solution:\) 这道题很奇妙,需要对kruskal重构树有足够的了解!我们先对王牌电缆实行kruskal重构树,然后我们再来枚举每一条李牌电缆,我们将某一条李牌电缆加进这棵树中必然构 ...
- 让 IE9 以下的浏览器支持 Media Queries
1. 如何让 IE9 以下的浏览器支持 css3 的media query 需要用到的 min-width/max-width 属性 css3 的媒体查询 IE 浏览器的支持程度是从 IE9开始支持, ...
- 虚拟树研究-CheckBox初步判断只能在第一列
//虚拟树研究-CheckBox初步判断只能在第一列 procedure TWindowsXPForm.XPTreeInitNode(Sender: TBaseVirtualTree; ParentN ...
- GCC编译过程与动态链接库和静态链接库
1. 库的介绍 库是写好的现有的,成熟的,可以复用的代码.现实中每个程序都要依赖很多基础的底层库,不可能每个人的代码都从零开始,因此库的存在意义非同寻常. 本质上来说库是一种可执行代码的二进制形式,可 ...
- 工作中bug笔记
1.报Cannot read property indexOf of undefined 错误的时候!!!报这种错的时候,一般是因为indexOf前面检查的东西是不存在的!!!!! 2.使用< ...
- mysql系列十二、mysql常用hint
对于经常使用oracle的朋友可能知道,oracle的hint功能种类很多,对于优化sql语句提供了很多方法.同样,在mysql里,也有类似的hint功能.下面介绍一些常用的. 强制索引 FORCE ...
- sqlserver2008r2数据库使用触发器对sa及其他数据库账号访问进行IP限制
一.只允许指定IP访问数据库 创建测试账号 CREATE LOGIN testuser WITH PASSWORD = '123' GO CREATE TRIGGER [tr_connection_l ...