mysql 误删除ibdata1之后的恢复方法

mysql 误删除ibdata1之后如何恢复

如果误删除了在线服务器中mysql innodb相关的数据文件ibdata1以及日志文件 ib_logfile*，
应该怎样恢复呢？

这时候应该一身冷汗了吧？
==================================
先抽根烟，冷静一下。
==================================
再观察一下网站，发现一切都很正常，数据的读取与写入操作都完全正常。
这是怎么个情况？

其实，mysqld在运行状态中，会保持这些文件为打开状态，
即使把它们删除了，它们仍旧存在于文件系统中，mysqld仍然可以对其进行读写。

代码如下:

root@localhost:/var/lib/mysql# ls -la /proc/14101/fd/ | grep -e ibdata -e ib_
lrwx------ 1 root  root  64 Aug  7 23:29 3 -> /var/lib/mysql/ibdata1 (deleted)
lrwx------ 1 root  root  64 Aug  7 23:29 8 -> /var/lib/mysql/ib_logfile0 (deleted)
lrwx------ 1 root  root  64 Aug  7 23:29 9 -> /var/lib/mysql/ib_logfile1 (deleted)

14101是mysqld的pid(进程ID)

只要mysqld不结束，就可以通过proc文件系统找到这几个被删除的文件(已经被Mark为deleted状态)。

这时候应该松了一口气吧。只要把这几个文件复制回 /var/lib/mysql就行了吗？

事情绝对没有这么简单。

因为，在innodb的buffer pool中，有许多dirty page(就是内存中的数据已经被修改，但是没有写回文件中),
如果直接把文件复制回去，轻则数据丢失，重则ibdata1文件损坏。

备份mysql数据的时候，也不能直接备份这几个文件，是同样的道理。

我们必须保证所有buffer pool中的数据修改都保存到了硬盘文件上面，
为此，首先要停止更多的写入/更新/删除操作，然后等待innodb flush pages to disk.
停止写入的话，可以把网站应用关闭，或者lock tables:

代码如下:

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 ROWS affected (0.37 sec)

这时就要等它flush结束，怎样知道有没有结束呢？观察checkpoint age就可以了。

代码如下:

mysql> SHOW engine innodb STATUS  
---
LOG
---
Log SEQUENCE NUMBER 363096003
Log flushed up TO 363096003
LAST checkpoint at 363096003

checkpoint age 就是 Log sequence number的值减去 Last checkpoint at的值，
如果为0，那么表示所有的page都flush到硬盘文件中了。

这时就要等它flush结束，怎样知道有没有结束呢？观察checkpoint age就可以了。

代码如下:

mysql> SHOW engine innodb STATUS  
---
LOG
---
Log SEQUENCE NUMBER 363096003
Log flushed up TO 363096003
LAST checkpoint at 363096003

checkpoint age 就是 Log sequence number的值减去 Last checkpoint at的值，
如果为0，那么表示所有的page都flush到硬盘文件中了。

为了加速这个flush的过程，可以这样设置一下：

代码如下:

mysql> SET global innodb_max_dirty_pages_pct=0;
Query OK, 0 ROWS affected (0.01 sec)

此外，还必须保证一些后台的线程完成了它们的工作，
比如insert buffer thread. ibuf的大小应该=1

代码如下:

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: SIZE 1, free list len 398, seg SIZE 400,

还有purge thread，它应该purge了全部的transactions:

代码如下:

------------
TRANSACTIONS
------------
Trx id counter 0 16644
Purge done FOR trx's n:o < 0 16644 undo n:o < 0 0

还要确保innodb不再进行写操作了：

代码如下:

FILE I/O
--------
I/O thread 0 state: waiting FOR i/o request (INSERT buffer thread)
I/O thread 1 state: waiting FOR i/o request (log thread)
I/O thread 2 state: waiting FOR i/o request (READ thread)
 I/O thread 3 state: waiting FOR i/o request (WRITE thread)
Pending normal aio reads: 0, aio writes: 0,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
332 OS file reads, 47 OS file writes, 32 OS fsyncs
0.00 reads/s, 0 avg bytes/READ, 0.00 writes/s, 0.00 fsyncs/s

然后把文件复制回去：

代码如下:

root@localhost:/var/lib/mysql# cp /proc/14101/fd/3 /var/lib/mysql/ibdata1
root@localhost:/var/lib/mysql# cp /proc/14101/fd/8 /var/lib/mysql/ib_logfile0
root@localhost:/var/lib/mysql# cp /proc/14101/fd/9 /var/lib/mysql/ib_logfile1
修改权限
root@localhost:/var/lib/mysql# chown -R mysql ib* 重启mysqld
root@localhost:/var/lib/mysql# /etc/init.d/mysql restart
结束~~~

结论：
1) 出现意外时，千万不能慌张，抽根烟先冷静一下。
2) 在解决方案不明确的时候，不要进行操作，比如重启mysqld，重启服务器。
3) 有必要监控mysql的ibdata等文件是否存在。

赞 (0)

相关推荐

  • MySQL中数据导入恢复的简单教程

    有两个简单的方法MySQL中的数据加载到MySQL数据库从先前备份的文件. LOAD DATA导入数据: MySQL提供了LOAD DATA语句,作为一个大容量数据加载.下面是一个例子声明中,读取一个文件dump.txt,,从当前目录加载到当前数据库中的表mytbl: mysql> LOAD DATA LOCAL INFILE 'dump.txt' INTO TABLE mytbl; 如果本地的关键字是不存在的,MySQL的外观使用绝对路径名寻找到完全指定位置的文件在服务器主机上的数据文件,从文

  • MySQL数据库误操作后快速回滚的方法

    基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. binlog2sql快速回滚 首先,确认你的MySQL server开启了binlog,设置了以下参数: [mysqld] server-id = 1 log_bin = /var/log/mysql/mysql-bin.log max_binlog_siz

  • MySQL误操作后快速恢复数据的方法

    摘要: 利用binlog闪回误操作数据. 基本上每个跟数据库打交道的程序员(当然也可能是你同事)都会碰一个问题,MySQL误操作后如何快速回滚?比如,delete一张表,忘加限制条件,整张表没了.假如这还是线上环境核心业务数据,那这事就闹大了.误操作后,能快速回滚数据是非常重要的. 传统解法 用全量备份重搭实例,再利用增量binlog备份,恢复到误操作之前的状态.然后跳过误操作的SQL,再继续应用binlog.此法费时费力,不值得再推荐. 利用binlog2sql快速闪回 首先,确认你的MySQ

  • 如何恢复Mysql数据库的详细介绍

    由于在一台测试机器上打算重新安装Mysql数据库,由于简单粗暴的直接卸载了,没有备份公司Discuz和Redmine使用的Mysql数据库,过程可想的悲惨. 还好的是只是卸载掉了Mysql的程序,所有的数据文件还是存在的. 下面是在恢复数据库的过程 1. Discuz数据库 Discuz数据库的恢复非常顺利, 在安装好新版本的Mysql后,直接将原来的数据库文件copy到新的数据目录中,重新启动mysql, 就能看到恢复的数据库了 2. Redmine数据库 本打算直接使用上面的经验,也能看到所

  • 关于mysql数据库误删除后的数据恢复操作说明

    在日常运维工作中,对于mysql数据库的备份是至关重要的!数据库对于网站的重要性使得我们对mysql数据的管理不容有失! 然后,是人总难免会犯错误,说不定哪天大脑短路了来个误操作把数据库给删除了,怎么办??? 下面,就mysql数据库误删除后的恢复方案进行说明. 一.工作场景 (1)MySQL数据库每晚12:00自动完全备份. (2)某天早上上班,9点的时候,一同事犯晕drop了一个数据库! (3)需要紧急恢复!可利用备份的数据文件以及增量的binlog文件进行数据恢复. 二.数据恢复思路 (1

  • 详解MySQL误操作后怎样进行数据恢复

    一.开启binlog. 首先查看binlog是否开启 mysql> show variables like "log_bin"; +---------------+-------+ |Variable_name | Value +---------------+-------+ | log_bin OFF +---------------+-------+ 1 row in set (0.00 sec) 值为OFF,需开启,开启binlog方式如下: #vim /etc/my.c

  • mysql 误删除ibdata1之后的恢复方法

    mysql 误删除ibdata1之后如何恢复 如果误删除了在线服务器中mysql innodb相关的数据文件ibdata1以及日志文件 ib_logfile*,应该怎样恢复呢? 这时候应该一身冷汗了吧?==================================先抽根烟,冷静一下.==================================再观察一下网站,发现一切都很正常,数据的读取与写入操作都完全正常.这是怎么个情况? 其实,mysqld在运行状态中,会保持这些文件为打开状态,

  • SQL Server简单模式下误删除堆表记录恢复方法(绕过页眉校验)

    SQL Server简单模式下误删除堆表记录恢复方法(绕过页眉校验)

    首先,我需要强调下,这篇主旨是揭示堆表的删除记录找回的原理,我所考虑的方面并不适用于每个人的每种情况,望大家见谅~ 很多朋友认为数据库在简单模式下,堆表误删除一条记录,是无法找回的,因为没有日志记录.其实不然,某种意义上是可以找回的,因为堆表在删除记录时,只更改了行偏移,实际数据没有被物理删除,所以利用这点,测试了下恢复数据,果然成功了,但是还有点问题没有研究出结果:如果不关闭页面校验,除了更改偏移量,删除数据时还需要更改页眉,这点还没时间去琢磨,所以恢复数据时还要能推断出页眉的16进制对应关系

  • MySQL单表ibd文件恢复方法详解

    前言: 随着innodb的普及,innobackup也成为了主流备份方式.物理备份对于新建slave,全库恢复的需求都能从容应对. 但当面临单表数据误删,或者单表误drop的情况,如果使用物理全备进行恢复呢? 下文将进行详细分析. 恢复过程中需要用到的工具,percona data recover tool : https://launchpad.net/percona-innodb-recovery-tool 情况一:误删部分数据,需要用最近一次备份覆盖 来自同一台机器的ibd恢复覆盖,且备份

  • MySQL 自动备份与数据库被破坏后的恢复方法第1/2页

    一.前言: 当数据库服务器建立好以后,我们首先要做的不是考虑要在这个支持数据库的服务器运行哪些受MySQL提携的程序,而是当数据库遭到破坏后,怎样安然恢复到最后一次正常的状态,使得数据的损失达到最小. 或者说,仅仅是数据库服务器的建立,只能说明它能做些什么,并不代表它能稳定的做些什么.灾难恢复的效率及全面性,也是系统的稳定性的一个准因素,尤其对于一个服务器系统. 这一节,介绍数据库自动备份以及数据库被破坏后的恢复的方法.在这里,我们使用mysqlhotcopy,并且定义一段Shell脚本来实现数

  • mysql 找回误删表的数据方法(必看)

    有备份的话很简单,只需要生成一个最近备份的数据 然后用mysqlbinlog找回备份时间点之后的数据 再恢复到现网即可. 要是没有备份 可能就会比较麻烦,找回数据的成本也是非常之高的. 下面介绍下 mysqlbinlog找回备份时间点之后的数据的办法: 做个简单的实验,将mysql的表数据删除之后,然后用mysqlbinlog 找回刚才删除的表的数据. app表的创建时间和数据的插入: 2013-02-04 10:00:00 原理: mysqlbinlog 前提: mysql开启了bin log

  • mysql 5.7.10 安装配置方法图文教程

    mysql 5.7.10 安装配置方法图文教程

    MySQL5.7.10下载及安装及配置 一．下载 自MySQL版本升级到5.7以后,其安装及配置过程和原来版本发生了很大的变化,下面详细介绍5.7版本MySQL的下载.安装及配置过程. 图1.1 MySQL5.7 目前针对不同用户,MySQL提供了2个不同的版本: Ø MySQL Community Server:社区版,该版本完全免费,但是官方不提供技术支持. Ø MySQL Enterprise Server:企业版,它能够高性价比的为企业提供数据仓库应用,支持ACID事物处理,提供完整的提

  • 详解MySQL数据备份之mysqldump使用方法

    mysqldump常用于MySQL数据库逻辑备份. 1.各种用法说明 A. 最简单的用法: mysqldump -uroot -pPassword [database name] > [dump file] 上述命令将指定数据库备份到某dump文件(转储文件)中,比如: mysqldump -uroot -p123 test > test.dump 生成的test.dump文件中包含建表语句(生成数据库结构哦)和插入数据的insert语句.  B. --opt 如果加上--opt参数则生成的d

  • 在Linux环境下mysql的root密码忘记解决方法（三种）

    MySQL密码的恢复方法之一 1．首先确认服务器出于安全的状态,也就是没有人能够任意地连接MySQL数据库. 因为在重新设置MySQL的root密码的期间,MySQL数据库完全出于没有密码保护的 状态下,其他的用户也可以任意地登录和修改MySQL的信息.可以采用将MySQL对外的端口封闭,并且停止Apache以及所有的用户进程的方法实现服务器的准安全状态.最安全的状态是到服务器的Console上面操作,并且拔掉网线. 2．修改MySQL的登录设置: # vi /etc/my.cnf 在[mysq

  • windows mysql 自动备份的几种方法汇总

    基于之前的文章方法,加入批处理命令即可实现自动备份.只是由于批处理命令中对于备份文件的名字按照时间命名比较特别,所以特别整理一文. 1.复制date文件夹备份 ============================ 假想环境: MySQL   安装位置:C:\MySQL 论坛数据库名称为:bbs 数据库备份目的地:C:\db_bak\ ============================ 新建db_bak.bat,写入以下代码 *******************************

  • 服务器断电导致虚拟机数据丢失的恢复方法详解

    服务器断电导致虚拟机数据丢失的恢复方法详解

    本文实例讲述了服务器断电导致虚拟机数据丢失的恢复方法.分享给大家供大家参考,具体如下: 在服务器运行过程中如果出现意外情况突然断电很容易引起服务器故障,服务器中的硬件设备损坏可以修复或者购买,但是服务器中的数据一旦发生故障丢失,对于企业来说将是不可估量的损失.那么服务器数据一旦丢失就除了痛哭之外别无他法了吗?不是的,下面我将引用一个真实案例为大家讲解意外断电导致服务器数据丢失的数据恢复方法和过程.文中若有歧义之处欢迎探讨. 虚拟机数据丢失情况描述 因服务器突然断电原因导致Xen Server服务

随机推荐