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

本文涉及的产品
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
RDS AI 助手,专业版
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
简介:

    有人因为不熟悉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

相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
相关文章
|
5月前
|
存储 监控 算法
防止员工泄密软件中文件访问日志管理的 Go 语言 B + 树算法
B+树凭借高效范围查询与稳定插入删除性能,为防止员工泄密软件提供高响应、可追溯的日志管理方案,显著提升海量文件操作日志的存储与检索效率。
178 2
|
6月前
|
SQL 人工智能 监控
SLS Copilot 实践:基于 SLS 灵活构建 LLM 应用的数据基础设施
本文将分享我们在构建 SLS SQL Copilot 过程中的工程实践,展示如何基于阿里云 SLS 打造一套完整的 LLM 应用数据基础设施。
1790 95
|
6月前
|
数据采集 运维 监控
不重启、不重写、不停机:SLS 软删除如何实现真正的“无感数据急救”?
SLS 全新推出的「软删除」功能,以接近索引查询的性能,解决了数据应急删除与脏数据治理的痛点。2 分钟掌握这一数据管理神器。
750 47
|
10月前
|
存储 缓存 Apache
StarRocks+Paimon 落地阿里日志采集:万亿级实时数据秒级查询
本文介绍了阿里集团A+流量分析平台的日志查询优化方案,针对万亿级日志数据的写入与查询挑战,提出基于Flink、Paimon和StarRocks的技术架构。通过Paimon存储日志数据,结合StarRocks高效计算能力,实现秒级查询性能。具体包括分桶表设计、数据缓存优化及文件大小控制等措施,解决高并发、大数据量下的查询效率问题。最终,日志查询耗时从分钟级降至秒级,显著提升业务响应速度,并为未来更低存储成本、更高性能及更多业务场景覆盖奠定基础。
|
7月前
|
存储 缓存 Apache
StarRocks+Paimon 落地阿里日志采集:万亿级实时数据秒级查询
A+流量分析平台是阿里集团统一的全域流量数据分析平台,致力于通过埋点、采集、计算构建流量数据闭环,助力业务提升流量转化。面对万亿级日志数据带来的写入与查询挑战,平台采用Flink+Paimon+StarRocks技术方案,实现高吞吐写入与秒级查询,优化存储成本与扩展性,提升日志分析效率。
996 1
|
11月前
|
SQL 监控 数据挖掘
SLS 重磅升级:超大规模数据实现完全精确分析
SLS 全新推出的「SQL 完全精确」模式,通过“限”与“换”的策略切换,在快速分析与精确计算之间实现平衡,满足用户对于超大数据规模分析结果精确的刚性需求。标志着其在超大规模日志数据分析领域再次迈出了重要的一步。
774 118
|
7月前
|
存储 关系型数据库 数据库
【赵渝强老师】PostgreSQL数据库的WAL日志与数据写入的过程
PostgreSQL中的WAL(预写日志)是保证数据完整性的关键技术。在数据修改前,系统会先将日志写入WAL,确保宕机时可通过日志恢复数据。它减少了磁盘I/O,提升了性能,并支持手动切换日志文件。WAL文件默认存储在pg_wal目录下,采用16进制命名规则。此外,PostgreSQL提供pg_waldump工具解析日志内容。
710 0
|
7月前
|
数据采集 运维 监控
|
9月前
|
存储 NoSQL MongoDB
Docker中安装MongoDB并配置数据、日志、配置文件持久化。
现在,你有了一个运行在Docker中的MongoDB,它拥有自己的小空间,对高楼大厦的崩塌视而不见(会话丢失和数据不持久化的问题)。这个MongoDB的数据、日志、配置文件都会妥妥地保存在你为它精心准备的地方,天旋地转,它也不会失去一丁点儿宝贵的记忆(即使在容器重启后)。
1074 4