人工误删除InnoDB ibdata数据文件与ib_logile重做日志文件如何恢复详细过程

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
日志服务 SLS,月写入数据量 50GB 1个月
简介:

    有人因为不熟悉InnoDB引擎,而误删除innoDB ibdata(数据文件)和ib_logfile(redo log重做事务日志文件),结果导致了悲剧的发生。如果有做主从复制同步那还好,如果是单机呢?如何恢复?

1)使用rm –f ib* 删除数据文件和重做日志文件

下面就来使用具体看看如何恢复。

若此时你发现数据库还可以正常工作,数据照样可以写入,切记,这时千万别把mysqld进程杀死,否则没法挽救。

先找到mysqld的进程pid,如下所示。

mysql01:/data/mysql3306/mysql # netstat -ntlp | grep mysqld

tcp   0      0 :::3306        :::*       LISTEN      13206/mysqld

 

这里是13206

之后要执行很关键的一步,输入如下命令,并查看结果:

mysql01:/data/mysql3306 # ll /proc/13206/fd | egrep 'ib_|ibdata'

lrwx------ 1 root root 64 Oct 28 14:08 10 -> /data/mysql3306/ib_logfile1 (deleted)

lrwx------ 1 root root 64 Oct 28 14:08 11 -> /data/mysql3306/ib_logfile2 (deleted)

lrwx------ 1 root root 64 Oct 28 14:08 4 -> /data/mysql3306/ibdata1 (deleted)

lrwx------ 1 root root 64 Oct 28 14:08 9 -> /data/mysql3306/ib_logfile0 (deleted)

 

10、11、4、9就是我们要恢复的文件,对应的文件。

 

这时,你可以把前端业务关闭,或者执行:

mysql@mysql01 ~ $mysql

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 4

Server version: 5.6.26-log MySQL Community Server (GPL)

 

Copyright (c) 2000, 2015, 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.

 

root@(none) 02:15:00>flush table with read lock;

Query OK, 0 rows affected (0.00 sec)

 

先输入以下命令,让脏页尽快刷入到磁盘里。

root@(none) 02:15:08>set global innodb_max_dirty_pages_pct=0;

Query OK, 0 rows affected (0.00 sec)

 

然后查看binlog日志写入情况

root@(none) 02:18:27>show master status;

+------------------+----------+--------------+------------------+-------------------------------------------+

| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |

+------------------+----------+--------------+------------------+-------------------------------------------+

| mysql-bin.000018 |      191 |              |                  | 279f439b-5d2f-11e5-ad29-000c294cec8f:1-35 |

+------------------+----------+--------------+------------------+-------------------------------------------+

1 row in set (0.00 sec)

 

最后再查看innodb状态信息,确保脏页已经刷入磁盘

root@(none) 02:19:31>show engine innodb status\G;

*************************** 1. row ***************************

  Type: InnoDB

  Name:

Status:

=====================================

2015-10-28 14:23:18 7f267ce54700 INNODB MONITOR OUTPUT

=====================================

Per second averages calculated from the last 30 seconds

-----------------

BACKGROUND THREAD

-----------------

srv_master_thread loops: 1 srv_active, 0 srv_shutdown, 2465 srv_idle

srv_master_thread log flush and writes: 2465

----------

SEMAPHORES

----------

OS WAIT ARRAY INFO: reservation count 2

OS WAIT ARRAY INFO: signal count 2

Mutex spin waits 0, rounds 0, OS waits 0

RW-shared spins 2, rounds 60, OS waits 2

RW-excl spins 0, rounds 0, OS waits 0

Spin rounds per wait: 0.00 mutex, 30.00 RW-shared, 0.00 RW-excl

------------

TRANSACTIONS

------------

Trx id counter 7943

Purge done for trx's n:o < 6922 undo n:o < 0 state: running but idle

##确保后台Purge进程把undo log全部清除掉,事务ID要一致。

History list length 73

LIST OF TRANSACTIONS FOR EACH SESSION:

---TRANSACTION 0, not started

MySQL thread id 4, OS thread handle 0x7f267ce54700, query id 27 localhost root init

show engine innodb status

--------

FILE I/O

--------

I/O thread 0 state: waiting for completed aio requests (insert buffer thread)

I/O thread 1 state: waiting for completed aio requests (log thread)

I/O thread 2 state: waiting for completed aio requests (read thread)

I/O thread 3 state: waiting for completed aio requests (read thread)

I/O thread 4 state: waiting for completed aio requests (read thread)

I/O thread 5 state: waiting for completed aio requests (read thread)

I/O thread 6 state: waiting for completed aio requests (write thread)

I/O thread 7 state: waiting for completed aio requests (write thread)

I/O thread 8 state: waiting for completed aio requests (write thread)

I/O thread 9 state: waiting for completed aio requests (write thread)

Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,

 ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0

Pending flushes (fsync) log: 0; buffer pool: 0

424 OS file reads, 5 OS file writes, 5 OS fsyncs

0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s

-------------------------------------

INSERT BUFFER AND ADAPTIVE HASH INDEX

-------------------------------------

Ibuf: size 1, free list len 0, seg size 2, 0 merges

##insert buffer 合并插入缓存等于1

merged operations:

 insert 0, delete mark 0, delete 0

discarded operations:

 insert 0, delete mark 0, delete 0

Hash table size 276671, node heap has 0 buffer(s)

0.00 hash searches/s, 0.00 non-hash searches/s

---

LOG

---

Log sequence number 1841823

Log flushed up to   1841823

Pages flushed up to 1841823

Last checkpoint at  1841823

0 pending log writes, 0 pending chkp writes

8 log i/o's done, 0.00 log i/o's/second

----------------------

BUFFER POOL AND MEMORY

----------------------

Total memory allocated 137363456; in additional pool allocated 0

Dictionary memory allocated 63832

Buffer pool size   8191

Free buffers       7920

Database pages     271

Old database pages 0

Modified db pages  0     #确保脏页数据为0

Pending reads 0

Pending writes: LRU 0, flush list 0, single page 0

Pages made young 0, not young 0

0.00 youngs/s, 0.00 non-youngs/s

Pages read 271, created 0, written 1

0.00 reads/s, 0.00 creates/s, 0.00 writes/s

No buffer pool page gets since the last printout

Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s

LRU len: 271, unzip_LRU len: 0

I/O sum[0]:cur[0], unzip sum[0]:cur[0]

--------------

ROW OPERATIONS

--------------

0 queries inside InnoDB, 0 queries in queue

0 read views open inside InnoDB

Main thread process no. 13206, id 139803249243904, state: sleeping

Number of rows inserted 0, updated 0, deleted 0, read 4

0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s   #确保插入、更新、删除为 0

----------------------------

END OF INNODB MONITOR OUTPUT

============================

 

1 row in set (0.00 sec)

 

ERROR:

No query specified

 

root@(none) 02:23:18>

 

上面一系列确认工作完成之后 ,就可以进行恢复操作了,删除文件

mysql01:/data/mysql3306 # ll /proc/13206/fd | egrep 'ib_|ibdata'

lrwx------ 1 root root 64 Oct 28 14:08 10 -> /data/mysql3306/ib_logfile1 (deleted)

lrwx------ 1 root root 64 Oct 28 14:08 11 -> /data/mysql3306/ib_logfile2 (deleted)

lrwx------ 1 root root 64 Oct 28 14:08 4 -> /data/mysql3306/ibdata1 (deleted)

lrwx------ 1 root root 64 Oct 28 14:08 9 -> /data/mysql3306/ib_logfile0 (deleted)

 

把这些文件复制 到原来 目录下

mysql01:/data/mysql3306 # cd /proc/13206/fd

mysql01:/proc/13206/fd # cp 10 /data/mysql3306/ib_logfile1

mysql01:/proc/13206/fd # cp 11 /data/mysql3306/ib_logfile2

mysql01:/proc/13206/fd # cp 4 /data/mysql3306/ibdata1

mysql01:/proc/13206/fd # cp 9 /data/mysql3306/ib_logfile0

 

然后修改用户属性与权限

mysql01:/proc/13206/fd # cd /data/mysql3306/

mysql01:/data/mysql3306 # ll

total 160148

-rw-rw---- 1 mysql app        56 Sep 17 19:28 auto.cnf

drwx------ 2 mysql app      4096 Oct 13 05:17 huizhe

-rw-r----- 1 root  root 50331648 Oct 28 14:33 ib_logfile0

-rw-r----- 1 root  root 50331648 Oct 28 14:32 ib_logfile1

-rw-r----- 1 root  root 50331648 Oct 28 14:32 ib_logfile2

-rw-r----- 1 root  root 12582912 Oct 28 14:33 ibdata1

drwx------ 2 mysql app      4096 Oct 28 09:32 mysql

-rw-rw---- 1 mysql app       214 Oct 29  2015 mysql-bin.000008

-rw-rw---- 1 mysql app       214 Oct 26 17:24 mysql-bin.000009

-rw-rw---- 1 mysql app       576 Oct 28 09:26 mysql-bin.000010

-rw-rw---- 1 mysql app      2166 Oct 28 09:30 mysql-bin.000011

-rw-rw---- 1 mysql app      5262 Oct 28 09:32 mysql-bin.000012

-rw-rw---- 1 mysql app       214 Oct 28 09:32 mysql-bin.000013

-rw-rw---- 1 mysql app       214 Oct 28 09:34 mysql-bin.000014

-rw-rw---- 1 mysql app       362 Oct 28 09:39 mysql-bin.000015

-rw-rw---- 1 mysql app       362 Oct 28 11:19 mysql-bin.000016

-rw-rw---- 1 mysql app       214 Oct 28 13:42 mysql-bin.000017

-rw-rw---- 1 mysql app       191 Oct 28 13:42 mysql-bin.000018

-rw-rw---- 1 mysql app       209 Oct 28 13:42 mysql-bin.index

-rw-rw---- 1 mysql app     12821 Oct 28 13:43 mysql01-slow.log

-rw-r----- 1 mysql root   129423 Oct 28 13:43 mysql01.err

-rw-rw---- 1 mysql app         6 Oct 28 13:42 mysql01.pid

drwx------ 2 mysql app      4096 Sep 17 19:24 performance_schema

drwx------ 2 mysql app      4096 Sep 17 19:24 test

drwx------ 2 mysql app      4096 Oct 28 09:59 test02

drwx------ 2 mysql app      4096 Oct 28 09:36 test08

    

mysql01:/data/mysql3306 # chown mysql:app ib*

mysql01:/data/mysql3306 # chmod 660 ib*

 

mysql01:/data/mysql3306 # ll

total 160148

-rw-rw---- 1 mysql app        56 Sep 17 19:28 auto.cnf

drwx------ 2 mysql app      4096 Oct 13 05:17 huizhe

-rw-rw---- 1 mysql app  50331648 Oct 28 14:33 ib_logfile0

-rw-rw---- 1 mysql app  50331648 Oct 28 14:32 ib_logfile1

-rw-rw---- 1 mysql app  50331648 Oct 28 14:32 ib_logfile2

-rw-rw---- 1 mysql app  12582912 Oct 28 14:33 ibdata1

drwx------ 2 mysql app      4096 Oct 28 09:32 mysql

-rw-rw---- 1 mysql app       214 Oct 29  2015 mysql-bin.000008

-rw-rw---- 1 mysql app       214 Oct 26 17:24 mysql-bin.000009

-rw-rw---- 1 mysql app       576 Oct 28 09:26 mysql-bin.000010

-rw-rw---- 1 mysql app      2166 Oct 28 09:30 mysql-bin.000011

-rw-rw---- 1 mysql app      5262 Oct 28 09:32 mysql-bin.000012

-rw-rw---- 1 mysql app       214 Oct 28 09:32 mysql-bin.000013

-rw-rw---- 1 mysql app       214 Oct 28 09:34 mysql-bin.000014

-rw-rw---- 1 mysql app       362 Oct 28 09:39 mysql-bin.000015

-rw-rw---- 1 mysql app       362 Oct 28 11:19 mysql-bin.000016

-rw-rw---- 1 mysql app       214 Oct 28 13:42 mysql-bin.000017

-rw-rw---- 1 mysql app       191 Oct 28 13:42 mysql-bin.000018

-rw-rw---- 1 mysql app       209 Oct 28 13:42 mysql-bin.index

-rw-rw---- 1 mysql app     12821 Oct 28 13:43 mysql01-slow.log

-rw-r----- 1 mysql root   129423 Oct 28 13:43 mysql01.err

-rw-rw---- 1 mysql app         6 Oct 28 13:42 mysql01.pid

drwx------ 2 mysql app      4096 Sep 17 19:24 performance_schema

drwx------ 2 mysql app      4096 Sep 17 19:24 test

drwx------ 2 mysql app      4096 Oct 28 09:59 test02

drwx------ 2 mysql app      4096 Oct 28 09:36 test08

 

 

现在,只需要重启MySQL即可。重启如下

mysql01:/data/mysql3306 # /etc/init.d/mysqld restart

Shutting  down  MySQL............     done                                                                                                                                                         

Starting MySQL..      done

友情提醒:不要在生产环境做测试哦。



本文转自 jxzhfei  51CTO博客,原文链接:http://blog.51cto.com/jxzhfei/1707284

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
18天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
127 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
|
18天前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的联机重做日志文件与数据写入过程
在Oracle数据库中,联机重做日志文件记录了数据库的变化,用于实例恢复。每个数据库有多组联机重做日志,每组建议至少有两个成员。通过SQL语句可查看日志文件信息。视频讲解和示意图进一步解释了这一过程。
|
2月前
|
数据采集 机器学习/深度学习 存储
使用 Python 清洗日志数据
使用 Python 清洗日志数据
37 2
|
4月前
|
存储 消息中间件 人工智能
AI大模型独角兽 MiniMax 基于阿里云数据库 SelectDB 版内核 Apache Doris 升级日志系统,PB 数据秒级查询响应
早期 MiniMax 基于 Grafana Loki 构建了日志系统,在资源消耗、写入性能及系统稳定性上都面临巨大的挑战。为此 MiniMax 开始寻找全新的日志系统方案,并基于阿里云数据库 SelectDB 版内核 Apache Doris 升级了日志系统,新系统已接入 MiniMax 内部所有业务线日志数据,数据规模为 PB 级, 整体可用性达到 99.9% 以上,10 亿级日志数据的检索速度可实现秒级响应。
AI大模型独角兽 MiniMax 基于阿里云数据库 SelectDB 版内核 Apache Doris 升级日志系统,PB 数据秒级查询响应
|
4月前
|
缓存 NoSQL Linux
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
131 1
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
|
3月前
|
SQL 人工智能 运维
在阿里云日志服务轻松落地您的AI模型服务——让您的数据更容易产生洞见和实现价值
您有大量的数据,数据的存储和管理消耗您大量的成本,您知道这些数据隐藏着巨大的价值,但是您总觉得还没有把数据的价值变现出来,对吗?来吧,我们用一系列的案例帮您轻松落地AI模型服务,实现数据价值的变现......
221 3
|
3月前
|
存储 SQL 缓存
InnoDB 存储引擎以及三种日志
InnoDB 存储引擎以及三种日志
30 0
|
4月前
|
存储 监控 网络协议
在Linux中,如何使用 tcpdump 监听主机为 192.168.1.1,tcp 端⼝为 80 的数据,并将将输出结果保存输出到tcpdump.log?
在Linux中,如何使用 tcpdump 监听主机为 192.168.1.1,tcp 端⼝为 80 的数据,并将将输出结果保存输出到tcpdump.log?
|
4月前
|
数据库 Java 监控
Struts 2 日志管理化身神秘魔法师,洞察应用运行乾坤,演绎奇幻篇章!
【8月更文挑战第31天】在软件开发中,了解应用运行状况至关重要。日志管理作为 Struts 2 应用的关键组件,记录着每个动作和决策,如同监控摄像头,帮助我们迅速定位问题、分析性能和使用情况,为优化提供依据。Struts 2 支持多种日志框架(如 Log4j、Logback),便于配置日志级别、格式和输出位置。通过在 Action 类中添加日志记录,我们能在开发过程中获取详细信息,及时发现并解决问题。合理配置日志不仅有助于调试,还能分析用户行为,提升应用性能和稳定性。
58 0
|
4月前
|
开发者 前端开发 编解码
Vaadin解锁移动适配新境界:一招制胜,让你的应用征服所有屏幕!
【8月更文挑战第31天】在移动互联网时代,跨平台应用开发备受青睐。作为一款基于Java的Web应用框架,Vaadin凭借其组件化设计和强大的服务器端渲染能力,助力开发者轻松构建多设备适应的Web应用。本文探讨Vaadin与移动设备的适配策略,包括响应式布局、CSS媒体查询、TouchKit插件及服务器端优化,帮助开发者打造美观且实用的移动端体验。通过这些工具和策略的应用,可有效应对屏幕尺寸、分辨率及操作系统的多样性挑战,满足广大移动用户的使用需求。
67 0