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

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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了人工误删除InnoDB ibdata数据文件与ib_logile重做日志文件如何恢复详细过程，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含10878字，纯文字阅读大概需要16分钟。

内容图文

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

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)

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;

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

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

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

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

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

本文出自 “飛鴻沓膤” 博客，请务必保留此出处http://jxzhfei.blog.51cto.com/1382161/1707284

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

标签：mysql ibdata数据文件 ib_logile重做日志文件

本文系统来源：http://jxzhfei.blog.51cto.com/1382161/1707284

内容总结

以上是互联网集市为您收集整理的人工误删除InnoDB ibdata数据文件与ib_logile重做日志文件如何恢复详细过程全部内容，希望文章能够帮你解决人工误删除InnoDB ibdata数据文件与ib_logile重做日志文件如何恢复详细过程所遇到的程序开发问题。如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/458175.html

来源：【匿名】

【上一篇】SQLServer 2008以上误操作数据库恢复方法——日志尾部备份【下一篇】php错误日志怎么看

更多 ►

【人工误删除InnoDB ibdata数据文件与ib_logile重做日志文件如何恢复详细过程】教程文章相关的互联网学习教程文章

mysql之innodb日志管理【代码】【图】

本文从两个方面进行阐述，常规的日志文件（不区分存储引擎），第二就是讲innodb存储引擎的事务日志。一、基本日志文件1.1、基本日志文件分类：错误日志(error log)慢查询日志日志(slow query log)二进制日志(binlog)查询日志(general log)1.2、错误日志主要包括mysql的启动，运行，关闭过程进行记录。默认情况下以服务器的主机名命名`hostname`.err，可以通过参数--log-error=[file_name]指定正在运行状态下删除错误日志后，不会自...

mysql的innodb中事务日志ib

事务日志或称redo日志，在mysql中默认以ib_logfile0,ib_logfile1名称存在。可以手工修改参数，调节开启几组日志来服务于当前mysql数据库,mysql采用顺序，循环写方式，每开启一个事务时，会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位事务日志或称redo日志，在mysql中默认以ib_logfile0,ib_logfile1名称存在。可以手工修改参数，调节开启几组日志来服务于当前mysql数据库,mysql采用顺序，循环写方式，每开启...

mysql的innodb中事务日志ib_logfile

ib_logfile正如你所说，它是INNODB的REDO、UNDO日志，并不是备份用的日志。MYSQL可以通过BINLOG来恢复，但这个ib_logfile没什么恢复的作用，它主要是在事务中起一个前滚或后滚的作用。 mysql的innodb中事务日志ib_logfile事务日志或称redo日志，在mysql中默认以ib_logfile0,ib_logfile1名称存在,可以手工修改参数，调节开启几组日志来服务于当前mysql数据库,mysql采用顺序，循环写方式，每开启一个事务时，会把一些相关信息记录事...

Innodb的事务与日志 & JTA事务

InnoDB引擎的行锁是通过加在什么上完成（或称实现）的？为什么是这样子的通过行多版本控制 MyISAM Innodb 事物支持：不支持支持锁的粒度： table Row 存储容量：没有上限 64TB 哈希索引：不支持支持全文索引：支持不支持外键：不支持 ...

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

1）使用rm –f ib* 删除数据文件和重做日志文件下面就来使用具体看看如何恢复。若此时你发现数据库还可以正常工作，数据照样可以写入，切记，这时千万别把mysqld进程杀死，否则没法挽救。先找到mysqld的进程pid,如下所示。mysql01:/data/mysql3306/mysql # netstat -ntlp | grep mysqldtcp 0 0 :::3306 :::* LISTEN 13206/mysqld 这里是13206之后要执行很关键的一步，输入如下命令，并查看结果：mysql01:...

mysql的innodb中事务日志ib_logfile

mysql的innodb中事务日志ib_logfile事务日志或称redo日志，在mysql中默认以ib_logfile0,ib_logfile1名称存在,可以手工修改参数，调节开启几组日志来服务于当前mysql数据库,mysql采用顺序，循环写方式，每开启一个事务时，会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位置或叫做偏移量);作用:在系统崩溃重启时，作事务重做；在系统正常时，每次checkpoint时间点，会将之前写入事务应用到数据文件中。引入一个问题：...

添加和删除InnoDB数据和日志文件_MySQL

bitsCN.com--from mysql 官方文档添加和删除InnoDB数据和日志文件这一节描述在InnoDB表空间耗尽空间之时，或者你想要改变日志文件大小之时，你可以做的一些事情。最简单的，增加InnoDB表空间大小的方法是从开始配置它为自动扩展的。为表空间定义里的最后一个数据文件指定autoextend属性。然后在文件耗尽空间之时，InnoDB以8MB为增量自动增加该文件的大小。增加的大小可以通过设置innodb_autoextend_increment值来配置,这个值以MB为...

Innodb日志与事务【代码】

错误日志：记录出错信息，也记录一些警告信息或者正确的信息。查询日志：记录所有对数据库请求的信息，不论这些请求是否得到了正确的执行。慢查询日志：设置一个阈值，将运行时间超过该值的所有SQL语句都记录到慢查询的日志文件中。二进制日志：记录对数据库执行更改的所有操作。中继日志：事务日志：2.Innodb事务：1.读未提交(RU) 2.读已提交(RC) 3.可重复读(RR) 4.串行 3.innodb引擎的4大特性：插入缓冲（insert buffer) 二...

MySQL——innodb日志管理【代码】

1、innodb存储引擎是支持事务ACID特性的，这个理论基本就是一个关系型数据库相关的数据恢复原形设计，包括日志、回滚、redo、并发控制、buffer pool等管理方面，内容非常全面；2、innodb的buffer pool主要用来存储访问过的数据页面，他就是一块连续的内存，通过一定的算法可以使这块内存得到有效的管理，它是数据库系统中拥有最大块内存的系统模块。 innodb存储引擎中数据的访问是按照页（也可以叫块，默认为16KB）的方式从数据库...

InnoDB存储引擎的表空间文件,重做日志文件【代码】【图】

和索引等数据。表空间文件InnoDB存储引擎在存储设计上模仿了Oracle，将存储的数据按表空间进行存放。默认配置下，会有一个初始化大小为10MB、名为ibdata1的文件。该文件就是默认的表空间文件（tablespace file）。你可以通过参数innodb_data_file_path对其进行设置。格式如下： innodb_data_file_path=datafile_spec1[;datafile_spec2]……你也可以用多个文件组成一个表空间，同时制定文件的属性，如： innodb_data_file_path=/db...

innodb二阶段日志提交机制【图】

innodb_flush_log_at_trx_commit参数的详细解释参见官网： https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit 其中有一段是这么写的： With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second. 意思是：如果innodb_flush_log_at_trx_com...

一次服务器断电，造成innodb引擎表（日志表）损坏的解决办法【代码】

1、mysql日志报错innodb引擎提示数据库没有正常关闭，报innodb错误180112 0:49:28 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 2580576839 180112 0:49:28 InnoD...

mysql 设置 innodb_print_all_deadlocks=ON, 保存死锁日志

5.6.2 Command-Line Format --innodb-print-all-deadlocks=#System Variable Name innodb_print_all_deadlocksScope GlobalDynamic YesPermitted Values Type booleanDefault OFF When this option is enabled, information about all deadlocks in InnoDB user transactions is recorded in the mysqld error log. Otherwise, you see information about only the last deadlock, using the SHOW ENGINE INNODB STATUS command. ...

MySQL Innodb表导致死锁日志情况分析与归纳【图】

代码如下: (gdb) b lock_rec_lock ? Breakpoint 1 at 0×867120: file lock/lock0lock.c, line 2070. ? (gdb) c ? Continuing. ? [Switching to Thread 1168550240 (LWP 5540)] ? Breakpoint 1, lock_rec_lock (impl=0, mode=5, rec=0x2aedbe01c1 “789\200″, index=0x2aada734b8, thr=0x2aada74c18) at lock/lock0lock.c:2070 ? 2070 { ? Current language: auto; currently c ? (gdb) c ? Continuing. ? Breakpoint 1, lock_rec_...

mysql-innodb的事务日志

【参考书籍：mysql技术内幕 INNODB存储引擎】【参考了一些博客内容】事务的隔离性由锁机制来实现，事务的原子性，一致性，持久性通过INNODB的redo log和undo log来完成。redo log：称为重做日志，用来保证事务的原子性和持久性。undo log：用来保证事务的一致性。二者的区别：undo log：记录某数据修改之前的值，可以用来在事务失败时，进行rollback。undo是逻辑日志，根据每行记录进行记录。redo log：用于记录某数据被修改之后的...

日志 - 最热教程

pt-query-digest解析MySQLBinlog日志文...详解Python中logging日志模块在多进程环...SQL Server 收缩日志清空删除大日志文...mysql查看执行sql语句的记录日志 ssh登录日志收集 Filebeat收集单个日志&json格式使用nginx访问服务器log日志 linux C中的多进程概念与log日志与部分...过滤nginx日志并添加防火墙拒绝访问 ce...Oracle如何决定日志切换到剩下的那个日...

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

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

内容导读

内容图文

内容总结

内容备注

内容手机端

【人工误删除InnoDB ibdata数据文件与ib_logile重做日志文件如何恢复详细过程】教程文章相关的互联网学习教程文章

日志 - 最新教程

日志 - 最热教程