备份：

就是将一个当前数据库系统中的“活”着的数据库，转换为一个死的不可操作的“数据文件”的过程。

恢复：

就是将“死”的数据文件，还原为活的可操作的数据库。

备份操作

在没有登录数据库系统的时候（登录前），使用mysql安装文件夹中的bin目录中的mysqldump命令来实现备份：

备份语法：

mysqldump -h要连接的数据库服务器 -u用户名 -p 要备份的数据库名 >要备份到的目标文件完整路径

注意：该命令需要在管理员模式下运行。

恢复操作：

通常的恢复操作，用于两种场景：

1，数据库迁移：从一台电脑，迁移到另一台电脑。

2，数据库本地还原：原数据库可能某种原因，损毁了，需要恢复！

而这里的演示，只能使用本地从一个数据库备份后，还原到另一个数据库中！！！

还原语法：

mysql -h数据库服务器 -u用户名 -p 要恢复的数据库名 < 要恢复的数据库文件完整路径

数据备份与还原 基础概念： 备份，将当前已有的数据或记录另存一份； 还原，将数据恢复到备份时的状态。 为什么要进行数据的备份与还原？ 防止数据丢失； 保护数据记录。 数据备份与还原的方式有很多种，具体可以分为：数据表备份、单表数据备份、SQL备份和增量备份。

1.硬件设备清单：

2.故障描述：

需要进行数据恢复的服务器是一台r520型号存储，共有7块SAS硬盘分别组成raid1和raid5两组磁盘阵列。主要sql server数据库存放在C盘中，在使用过程中，客户发现C盘容量即将占满，于是将数据库路径指向了D盘，在D盘生成了一个.ndf文件。客户在继续使用了大约10天之后，数据库出现故障，连接失效，无法正常附加查询。

3.备份数据：

考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一其他原因导致数据无法再次恢复。使用dd命令或winhex工具将所有磁盘都镜像成文件。

4.故障分析：

(a)分析故障原因；由于数据库文件所在磁盘容量不足，导致数据库无法继续正常运行，出现逻辑错误。

(b)分析RAID组结构；客户服务器上共7块300G硬盘，其中2块硬盘做RAID 1，用于安装操作系统，其余5块硬盘做RAID 5存放数据。分析RAID 1和RAID 5的相关结构，重组虚拟出RAID 1和RAID 5，查看其中数据。

(c)分析原始数据库文件；由于客户在数据库发生故障之后，进行过多次数据库恢复尝试，并且每一次尝试都是在源环境下进行的，导致原始数据库文件被更改覆盖，并且磁盘空间被多次复写，无法使用尝试恢复之后的数据库文件进行修复。询问客户得知，客户在数据库发生故障的时候，备份过一分原始的故障数据库文件。

5.数据库修复：

从虚拟出的RAID 5空间中将客户之前备份的数据库文件拷贝出来，尝试在数据库中附加，附加失败，错误提示如下图一：

错误提示主数据库文件和次级数据库文件不匹配，查看.ndf文件底层，发现.ndf文件中几乎没有数据，尝试取消.mdf文件和.ndf文件之间关联，只用.mdf文件进行附加。尝试后发现，只用.mdf文件附加时也发生错误，但是错误提示改变。图二：

此时错误提示日志文件（.ldf）和数据库文件（.mdf）不匹配。之后对数据库尝试进行无数据库附加，附加成功。但是发现数据库系统表损坏，无法正常使用。图三

对数据库的系统表尝试修复，但由于系统表损坏过于严重，无法修复。数据库记录提取；解析数据库文件中的数据库记录；编写相应的程序提取数据库文件中的数据库记录；根据客户以前的数据库备份获取数据库中的表结构；重构表结构并肩提取出的数据库记录导入到新的表中。

6.数据验证：

由客户对提取出的数据库记录进行验证,所有数据完全恢复，本次数据恢复成功。

7.数据恢复结论：

在数据库使用过程中，要合理分配数据库文件所在磁盘空间，及时清理垃圾数据，保证数据库的正常、安全运行。

一、 前言

2018年5月28日，北京晴有轻度沙尘暴。 坐上公交车走在上班的路上，想起老罗经常说起的一句话：想成盛田昭夫时代的索尼，想成乔布斯时代的苹果，于是继续研读着 《日本制造：盛田昭夫的日式经营学》。

到了人大西门在西区食堂吃了个早餐，穿过人民大学很快就来到了公司。坐在工位上打开电脑登上QQ，不一会运营的CC的头像就开始闪动，“mooc平台登录不了”，“你看看”。又一会领导的头像开始闪动，“xxx说慕课平台不能登录了”。 额… 这事都惊动领导了？

二、 排查问题

打开chrome浏览器开始预览，等了好久代理服务器才反馈

Time out！

使用 SecureCRT 连接了一下服务器，首先重新启动了一下Nginx代理服务器

service nignx stop // 关闭Nginx服务 service nginx start // 开启Nginx服务

去前台刷新了几下没有恢复。 那就在重启一下php吧，于是就

service php-fpm stop // 关闭PHP服务 service php-fpm start // 开启PHP服务

又去前台试了试还是没有恢复。（有人会问为什么不直接用 service xxx restart 来重启各服务呢？ 我也不知道为什么，个人爱好吧！）那只有一种可能数据库出问题了。

打开 Navicat 连接了一下数据库，发现可以正常连接而且可以看到所有的表，随便打开了一张表能看到里面的数据，但是弹出了一个错误的提示。

Got error 28 from storage engine

大概是这个错误提示，当时也没在意，心想反正提示错误了那就重启一下物理服务器吧，这里是物理服务器！！！随后执行了这个命令（为什么不直接重启MySQL服务呢？ 事后想了想我也不知道为什么。 而且如果当时注意看看这个错误，是因为磁盘空间问题引起的，也许后面就不会有那么多惊心动魄了！）

reboot // 重启物理服务器

执行完以后所有的服务都正常关闭了，只有Mysql数据库服务

Shutdown MySQL ……………………………………………….

引号已经5排了，实在是等不下去了。 断电！！！（MySQL没有安全关闭，直接断电会出问题的！！！）。

三、 恢复进程

等了一会，物理服务器启动起来了。一切的应用服务都正常启动了，只看到在启动MySQL数据库的时候出现了

The server quit without updating pid file (/var/lib/mysql/localhost.localdomain.pid)

等到全部服务加载完成以后手动又进行了一次MySQL数据库启动

service mysql start

依然报前面那样的错误，此时心里开始紧张了起来。 Google了一下这个错误，网上提供了几种解决的方案：

1、 Mysql权限问题

chown -R mysql:mysql /var/lib/mysql/* chmod -R 660 /var/lib/mysql/*

2、 Mysql 服务已开启

ps -ef|grep mysqld // 查看是否有mysqld进程 kill -9 进程号 // 强制杀死进程

3、 残余数据影响了Mysql服务的启动

删除数据库目录(我的数据库目录为rpm安装默认目录：/var/lib/mysql)下的 mysql-bin.index 文件

4、 Mysql配置文件(默认为：/etc/myf)

配置文件里面没有配置数据库目录，这个问题一般在刚安装MySQL时候会出现

5、 skip-federated字段问题

MySQL配置文件注释掉skip-federated字段

6、 selinux的问题

centos6.8以上默认会开启selinux服务，加强版军用级防火墙。为了查问题可以直接关掉 /usr/sbin/setenforce 0

以上解决方案全部都已经使用过了，都没有解决问题，依然开启服务会报错。 此时的心开始凉了。

回头看了看往期的备份，xxxx_20171208.sql。 都快2018年6月份了，我的上次备份竟然是17年12月份的，半年了！都半年没备份过了！ （我视乎隐约的感觉前段时间是有备份的，备份的服务器硬盘好像被我清理了）。

进入到数据库目录下，看到了除了上述说的 mysql-bin.index 文件以外还有其他的几个文件：mysql-bin.~rec~ 、 ib_logfile1、 ib_logfile0、 ibdata1 想了想是不是这几个也是一些残余文件，全部删了试试。 尝试把这几个文件转移到了其他的目录（使用的mv命令）模拟删除效果，同时还相当于备份。

service mysql start

竟然MySQL数据库服务正常启动了！ 心里的喜悦涌了上来，赶紧使用Navicat连接一下看看，能够正常连接，看到了数据库。 打开数据库以后所有的表都没有了！ 此时心又酸了起来。 一转眼11:30了，时间过的可真快啊，同事叫着一起吃饭，此时的我已经全无吃饭的心情了。

恢复表结构

把刚才移走的几个文件又恢复到了原目录里，既然恢复MySQL进程现在没什么希望了，那就想办法恢复数据吧。 进入到数据库目录（/var/lib/mysql）下找到了我的数据库名字以目录的形式存放。 进去该目录以后发现里面都是以扩展名为：xxxx表.frm文件，这些不都是我的数据库表吗？ 里面是不是就存放了所有的数据？ 是不是直接拿这些文件就可以恢复数据呢？Google了一下，果然有这方面的文章，大致说： “frm可以恢复表结构，同时InnoDB数据库引擎和MyISAM数据库引擎恢复的方式不一样”。

1、 InnoDB数据库引擎

在一个正常的MySQL数据库服务器（new_server）下建立数据库（new_db），该数据库的名称和异常服务器（old_server）数据库(old_db)保持一致。在new_db数据库中建立一张表与old_db的表名称（t_user）一致。将new_server服务器的MySQL数据库服务关闭。从old_server服务器下old_db的数据库目录下复制t_user.frm文件到new_server服务器下new_db的数据库目录下替换t_user.frm文件。开启new_server服务器的MySQL数据库服务。使用连接工具连接new_server就可以看到new_db下的表及表结构。

2、 MyISAM数据库引擎

其他和InnoDB数据库引擎操作基本一致，只是在new_server服务器下new_db的数据库目录下创建两个空的文件：t_user.MYD 和 t_user.MYI。

我使用的数据库为InnoDB引擎，无奈的我以上两种方法都使用了，没有恢复任何表结构更没有数据，也许可能是我操作有问题吧。 此时看到了目录下有一个文件： ibdata1 Google了一下，可以和xxx.frm配合使用，又一次将new_server服务器的MySQL数据库服务关闭。 直接把old_server服务器下old_db的数据库目录下复制ibdata1文件到new_server服务器下new_db的数据库目录下替换ibdata1文件。

service mysql start

新的服务器也出现了这样的错误，导致错误的很大原因可能是ibdata1文件损坏引起的。

今天北京的天气已经达到了35摄氏度，但此时我的心已经凉了一半了，虽然没有按时备份数据及服务器异常崩溃造成数据丢失比直接删库的责任小了点，但是也办法向公司交代，真的需要开始准备 “离职申请” 了吗？

binlog日志

打开微信

我：你们公司用的是什么数据库，是MySQL吗 好友LZ：是的 我：公司的MySQL坏了，启动不了了； 数据没有备份； 有什么好办法把数据拿回来吗 好友LZ：你们之前数据的binlog还有吗；通过这个应该可以恢复 我：都有 好友LZ：我也没弄过数据恢复，都是DBA搞，感觉应该可以的；你先查查看网上有没有解决方案，我这会在上线。 我：嗯

本来想说：“你能不能问问好友LZ你们DBA遇到过这种情况吗，帮忙给个方案”；最后还是没有好意思开出口。 不过binlog这个名字让我突然想起了数据库目录（/var/lib/mysql）下面几个较大的文件。

这十几个文件就是binlog日志文件，每台服务器上面的个数应该不一样，这个文件只有每次重启MySQL服务或者刷新日志（MySQL命令：show master logs）的时候才会新增一个。看了一下我最近的几个文件，2018年1月16、 2018年3月18、 2018年4月18、 2018年5月28这几个时间点产生了新的文件，说明MySQL服务器这几个日期都进行过关闭又开启的操作。

binlog使用：

binlog文件简介（网上摘抄） MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。 binlog作用（网上摘抄） MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。 数据恢复，通过使用mysqlbinlog工具来使恢复数据。

使用binlog恢复数据之前需要确定MySQL是否开启binlog日志

show variables like 'log_%';

状态 OFF 为未开启，状态 ON 表示已开启

可以通过MySQL配置文件（默认路径：/etc/myf）开启或关闭binlog日志

vi /etc/myf

使用加上#可以关闭，去掉开启。 修改后需要重启MySQL服务（service mysql restart）才可以生效。

恢复数据（binlog日志方式）

初试mysqlbinlog工具

看到上面的那么多mysql-bin文件，很显然使用centos6.5下rpm方式安装的MySQL默认是打开binlog日志的。 这时我们就需要用到MySQL的 mysqlbinlog 工具，想使用它首先需要确保已经安装MySQL服务，然后我们需要找到它的位置

find / -name mysql

2 表示为MySQL可执行文件的目录 3 表示为MySQL的数据库目录

那我们先简单的使用一下

cd /var/lib/mysql mysqlbinlog mysql-bin.000001 >mysql-bin.000001.sql

很显然我在使用mysqlbinlog的时候是，直接执行的mysqlbinlog命令，前面并没有增加任何路径。 因为默认centos系统会将/usr/bin这个目录配置到环境标量中，若我们使用的是rpm方式安装的MySQL，默认是安装到/usr/bin目录下的。 可以直接在任何路径下使用/usr/bin目录里的文件。 执行完上面的语句后会发现在当前目录生成一个mysql-bin.000001.sql的文件， 打开文件可以看到很多sql语句。

对于我当前的情况来看并不需要把所有的binlog都处理一遍，上面提到我上次的备份是在2017年12月8日的时候（xxxx_20171208.sql）因此我只需要从 mysql-bin.000009 这个binlog文件开始就可以了。

首先我在另外一台服务器上面重新搭建了一个MySQL服务，把mysql-bin.000009以后的几个binlog都拷贝到了这台新的服务器上面去。（服务器出现任何问题，建议不要对该服务器做任何操作，换一台新的电脑或服务来处理，为了保护数据的完整性！）

使用备份文件恢复数据

在新的MySQL上面建了一个和以前一样名称的数据库

mysql -u数据库用户名 -p数据库密码 数据库名称 --default-character-set=utf8 < xxxx_20171208.sql 例：mysql -uroot -proot xxxx --default-character-set=utf8 < xxxx_20171208.sql

使用binlog恢复数据

这时数据库有了，数据表及表结构也有了，那就开始恢复数据吧。

mysqlbinlog mysql-bin.000009 | mysql -uroot -proot

回车马上就出错了，遇到了两种错误，一种是PRIMARY的错误，一种是找不到记录的错误。 mysqlbinlog在执行mysql-bin.000009文件里的插入语句时出错了。 看了一下mysql-bin.000009文件的创建时间是2017年11月12日，我的备份文件是2017年12月8日，他们两个时间差了二十几天，执行上面恢复语句肯定会出现重复插入的问题，数据库里的某些表是由PRIMARY KEY的约束的，所以会导致PRIMARY错误。 这时我们需要用到mysqlbinlog的参数： start-datetime 和 end-datetime，顾名思义一个是开始时间一个是结束时间。

mysqlbinlog --start-datetime="2017-12-08 10:00:00" mysql-bin.000009 | mysql -uroot -proot

看了一下我备份的xxxx_20171208.sql大致是2017年12月8日的10左右，没有添加 end-datetime 参数的话默认为该binglog文件下的最后一个时间点。 执行了以后报了一个找不到记录的异常。 应该是执行删除或更新语句的时候没有找到某条记录，时间还是不对。 于是我就查看了数据库的日志表，最后的时间是2017年12月8日9点32分41秒，有执行了一次

mysqlbinlog --start-datetime="2017-12-08 09:32:41" mysql-bin.000009 | mysql -uroot -proot

依然报错，那怎么办呢，难道这个方法不行？

mysqlbinlog mysql-bin.000009 >mysql-bin.000009.sql

此时打开mysql-bin.000009.sql里面拥有大量的sql语句，发现好多条sql语句在这个时间点下。 看来使用参数来控制行不通。 还好mysqlbinlog工具给我们提供了另外两个参数start-position 和 end-position

修改了一下命令

mysqlbinlog --start-position="123456" mysql-bin.000009 | mysql -uroot -proot

果然一切都正常了，执行这个命令需要很久，它要把你这段时间所有的增加、删除、更新都执行一遍。 这里可能还会遇到一个问题，我的这个MySQL服务器里面这有一个数据库，MySQL的binlog文件记录的是所有数据库的增加、删除、更新记录，那怎样只针对某个数据库来操作呢？ 这时我们需要用到mysqlbinlog的database参数

mysqlbinlog --database=xxxx --start-position="123456" mysql-bin.000009 | mysql -uroot -proot

半年的数据，就这么一个一个的binlog文件进行处理的，从晚上6点到夜里的12点完成所有文件的恢复，数据量不是很大，服务器的性能也不是太高，中间出了点问题，不过都是服务器中断的问题。 最后把所有的数据全部恢复了回来，这心惊肉跳的一天！

这是工作7年来出的最大一次事故，去年给自己定的一个目标今年写12篇有质量的文章反馈给互联网，都快过半年了�...

人生大起大落落落落落落，实在是太刺激了，下面这真是一个悲伤的故事。

那年公司 ERP 系统刚进行升级。

因为公司陆续上了 MES 和 PDM 系统。为了加快整个公司信息化平台的统一，请了个第三方公司来做中间接口。

然后故事开始了。

某一个晚上，第三方人员问我要 ERP 的 SA 密码。

我很警惕：“你要干嘛?”

“我测试一下中间表。”

“有没有写表的操作?”

“没有，只有读表的操作。”

于是我放心的给了 SA 密码。给了 VPN 权限通道。放她进来了。

十分钟后…..

她带着哭腔打电话来(是的，对方做测试的是个 93 年的萌妹子。)

“吴哥哥， 服务器中毒了 。。。。”

我当时还在逛果壳呢，一听她说我服务器中毒了，我表示无比淡定。还以大哥的经验教训了一顿她。

“叫你不要往我服务器传插件嘛，这次帮你解决一下，下次不准了哟。”

我认为是小 case 呢，不就中毒了嘛，系统往回滚一天就好了。

然后悲剧的事情就出现了，远程进不去，于是我就去机房本地登录，居然也进不去。

我不死心，强制重启，居然还是进不去。我的服务器系统就这样崩了。。。

好在那几天在做开发，系统没有启用，于是我和我的老板汇报了这个情况：

“老大，我们服务器系统崩了。”

“哦，那就搞好它让它别崩。” 果然是霸道总裁啊。

当时数据和应用服务器我都是分开跑的，所以应用服务器奔溃了，我觉得也没多大事，就重新做系统吧。于是我重新做了个系统，然后喊萌妹子上来搭平台。

“小刘啊，你可害惨我了，一个下午给你重做服务器系统了，我基础环境都配置好了，你上来搭平台吧。”

萌妹子那是无比的歉意啊，又是答应请我吃饭又是答应请我看电影的。我都想系统再崩溃一次了。

按理说这样应该是没问题了，就在我走出机房，在外面抽了根烟，45 度仰望了一下天空，联想了一下和萌妹子点个 9 分熟的牛排，在喝一口二锅头这样浪漫的晚餐的时候。电话来了。

来电话的是萌妹子的老板。

“小吴，我想找一下 information.db 和 mfmedia.db 这两个总表没找到，你给我找一下。”

我都蒙了，从来没人问过我这样的问题，难道她老板不是 IT 行业的。

“ 数据库文件都在目录树里啊 ，自己去找啊。”

“没有。”

于是我登上服务器一看，我傻了。 所有的表都空了，所有的表都静静的躺在那，但是里面都空了。。。

不可能啊，我数据库是放在另外一台服务器上的，怎么可能会没有了。

于是我问萌妹子：“XXX，你到底做了什么操作啊，为毛我数据库都没了。”

萌妹子说：“我啥也没干啊，只是按照步骤一路点 YES。”

我才想起来， 在第一次配置基础环境的时候，建账套会提示是否初始环境，如果点是了，数据库就会被初始化 ，然后这位萌妹子傻傻的点了是。

“你知道不知道你干了什么， 公司 06 年到现在所有的数据，财务的，供应链的，进销存的全部都在这台服务器里，200 多个 G 数据，因为你一个是，全没了 。”

萌妹子也吓蒙了，话都说不出来了。

没办法，我再给我老板打电话。

“老板，有个好消息，有个坏消息。”

“直接说坏的。” 我就喜欢我们老板这么直接。

“恩。。恩。。那个。。就是那个。ERP 的数据没了。”

“哦，那就找回来。” 老板还是那么的霸气。我特么都要爱上他了。

“老板，我想你没明白这个的严重性。ERP 数据没了，从 06 年开始的都没了，这意味着就算找回来，整理所有的表，排错也需要 3 天左右时间，到时候所有的生产都要暂时停止。如果找不回来，我们可能就要倒闭了。”

我忽然有种掌握天下苍生的感觉。。。

对面沉默了 5 秒后，爆吼了一句：“吴 XX，你给我滚到我办公室来!!”

中间和老板手握手谈心，被老板亲切慰问的细节跳过不表。

当时公司高层对数据安全还没有那么重视，之前预算做的项目，我已经做了备份的计划书，一直没被审批下来，现在估计悔得肠子都清了。

于是我开始漫长的 数据恢复之旅 。

我之前已经做了个本地备份的计划，每天晚上会备份一次。我把希望都放在了它身上。等我把备份的数据库附件上去，发现时间居然都是两个星期之前的。

而且还有一些新表都没有，我联系对方，对方告知研发人员两个星期前做测试的时候把备份计划关了。。。

我心里万头草泥马奔腾而过。

最后没有办法，把老服务器又翻了出来，翻出之前的老数据，开始转换。

期间老板给我短信：“数据恢复进行的怎么样了呢。”

“报告，正在稳步进行中，按照目前的状况，可恢复的可能性超过 90%。” 别问我 90% 怎么算出来的，我就是哄他才这样说的。

“唉，真是心急呀，睡都睡不着。小吴呀，当初要是听你的，上了备份该多好呀。” 现在知道后悔了，哼哼。

“老大别担心，我会搞定的。” 是的，作为一位负责的员工，我就是这么让老大心安。

“恩，那就交给你了哦，熬夜少抽点烟哦。” 哎呀，瞬间觉得我老大萌萌哒有没有。

这里花了我一个晚上加一个白天。

数据转换好了，还有一些时间差的数据没法找到。于是通知各个部门，找单据，开始往里面补单子，一条一条的按照业务流程补进去。

为了协同更方便，在会议室加设了几十台电脑集体办公。。。

在大家一片怨声载道中，三天时间，终于把数据恢复了过来。三天内我没离开机房超过 10 米，吃喝拉撒都在机房，不对，拉撒不在。

这件事情造成的后果：

1. 大部分员工放假三天，我加班三天三夜。

2. 本来很爱我的大部分员工因为单据事件，集体转为黑我恨我了。

3. 公司立马批了我的计划，冷备，热备，异地容灾，全部上全了。

4.我挥刀自宫，自己罚了自己，扣除了自己一个月工资。

5.老板到现在还是在怀疑请的那家公司已经被我们竞争对手收买，是故意来破坏我们的。

6.萌妹子拉黑了我。

这真是个悲伤的故事。

看完了这个悲伤的故事，我们要回归理性， MySQL 数据库误删除后怎么办?

在日常运维工作中，对于数据库的备份是至关重要的!数据库对于网站的重要性使得我们对 MySQL 数据库的管理不容有失!

然而是人总难免会犯错误，说不定哪天大脑短路了，误操作把数据库给删除了，怎么办?

下面，就 MySQL 数据库误删除后的恢复方案进行说明。

工作场景

MySQL 数据库每晚 12:00 自动完全备份。

某天早上上班，9 点的时候，一同事犯晕 drop 了一个数据库!

需要 紧急恢复 可 利用备份的数据文件以及增量的 binlog 文件进行数据恢复 。

数据恢复思路

利用全备的 SQL 文件中记录的 CHANGE MASTER 语句 ，binlog 文件及其位置点信息，找出 binlog 文件中增量的那部分。

用 MySQLbinlog 命令将上述的 binlog 文件导出为 SQL 文件，并剔除其中的 drop 语句。

通过全备文件和增量 binlog 文件的导出 SQL 文件，就可以恢复到完整的数据。

实例说明

首先，要 确保 MySQL 开启了 binlog 日志功能。 在 /etc/myf 文件里的 [mysqld] 区块添加，如下图，然后重启 MySQL 服务。

1.在 ops 库下创建一张表 customers

2.现在进行全备份

参数说明：

-B：指定数据库

-F：刷新日志

-R：备份存储过程等

-x：锁表

Cmaster-data：在备份语句里添加 CHANGE MASTER 语句以及 binlog 文件及位置点信息

3.再次插入数据

4.此时误操作，删除了 test 数据库

此时，全备之后到误操作时刻之间，用户写入的数据在 binlog 中，需要恢复出来!

5.查看全备之后新增的 binlog 文件

这是全备时刻的 binlog 文件位置，即 mysql-bin.000002 的 106 行，因此 在该文件之前的 binlog 文件中的数据都已经包含在这个全备的 SQL 文件中了。

6.移动 binlog 文件，并导出为 SQL 文件

剔除其中的 drop 语句，查看 MySQL 的数据存放目录，由下面可知是在 /var/lib/mysql 下，将 binlog 文件导出 SQL 文件，并 vim 编辑它删除其中的 drop 语句。

注意：在 恢复全备数据之前必须将该 binlog 文件移出，否则恢复过程中，会继续写入语句到 binlog，最终导致增量恢复数据部分变得比较混乱。

7.恢复数据

查看数据库，看看 ops 库在不在。

此时恢复了全备时刻的数据。接着，使用 002bin.sql 文件恢复全备时刻到删除数据库之间，新增的数据。

再次查看数据库，发现全备份到删除数据库之间的那部分数据也 恢复 了!!

以上就是 MySQL 数据库增量数据恢复的实例过程!

最后，总结几点：

本案例适用于人为 SQL 语句造成的误操作或者没有主从复制等的热备情况宕机时的修复。

恢复条件为 MySQL 要开启 binlog 日志功能，并且要全备和增量的所有数据。

恢复时建议对外停止更新，即禁止更新数据库。

先恢复全量，然后把全备时刻点以后的增量日志，按顺序恢复成 SQL 文件，然后把文件中有问题的 SQL 语句删除(也可通过时间和位置点)，再恢复到数据库。

来源：51CTO

计 算 机 世 界

C HINA C OMPUTER W ORLD

关 于 IT 产 业 和 产 业 IT 的 一 切

软件：用友，速达，管家婆，远光，奇安、金蝶、美萍、百威、广联达……等各种财务软件、医药软件、医院软件、汽配软件、服装软件、宾馆软件、书店软件、超市软件、OA办公自动化……等各种行业软件。

数据库：SQL，Oracle，Sybase，Access、dBase，FoxBase……等各种版本的新老数据库。

故障：数据库质疑，删除库内表，格式化，重做系统，重分区，系统还原，软件报错，数据错乱，备份覆盖，硬盘损坏……

收费：根据故障轻重和数据库文件的容量收费，500元起，数据库文件容量越大，工作量越大，耗时越长，收费越高。

涉密：如果客户数据涉密和隐私，可以签订《数据保密协议》，保证数据不会有任何形式的泄露。

有的时候因为web服务器掉电或者其他原因意外重启导致数据库损坏，作为站长的我们可以使用mysql自带的mysqlcheck命令来快速修复所有的数据库。

1、在开始运行中输入CMD,启动命令行. 进入MYSQL的bin目录：

入图片描述

2、运行MYSQL自带的mysqlcheck修复命令

运行：mysqlcheck -A -o -r -uroot -p888888

注意，将888888改成你自己的root用户密码

然后就会自动进行修复操作：

注意：在修复过程中，如果看到有error的提示，表示这个表示坏的，无法修复的，对于含有坏表的数据库，你只能删除它，或停止它，不然会影响整个MYSQL的稳定，造成MYSQL自动停止。(提示"The storage engine for the table doesn't support repair"的表不需要处理)

如果修复太快看不到结果,可以运行

mysqlcheck -A -o -r -uroot -p888888 >>C:\mysqlerror.txt

将888888改为你自己的MySQL root密码，运行后打开C:\mysqlerror.txt就可以看到了.

是不是很方便呢，作为站长的我们很轻松的就可以掌握这个方法！

这世界上有后悔药-houhuiyao.cc 后悔药数据恢复 站长语

前面介绍了MySQL数据库在使用InnoDB引擎时，如果误删了数据表，在共享表空间MySQL数据表InnoDB引擎表误删恢复(共享表空间ibdata1)和独立表空间MySQL数据表InnoDB引擎表误删恢复(独立表空间innodb_file_per_table=1)的情况下如何恢复数据。

本文将探讨下MySQL数据库误删恢复。

后悔药数据恢复提醒您：

1，首先需要说明的是，生产环境下慎重执行删除操作，除非你确实明白自己在做什么，否则不执行危险动作。

2，有条件的情况下，依靠系统来管理数据和数据库，尽可能降低依潜在的管理的风险。

3，数据库有Update、Delete、Insert、Truncate、Drop类操作，先在测试环境执行一次，看结果和预期是否相符。生产环境执行前，先对要操作的表做一个备份，以防万一。后续将针对每个危险动作如何在生产执行时即准备好危机应对动作做一个探讨。

4，备份，备份，备份。

数据库误删，不管是使用的rm -rf testdb还是drop database testdb，最终的效果都是一样的：数据目录下的testdb目录及目录下的文件都不可见了(和之前介绍的Linux下恢复删除的情况一致)，实际上文件内容依然还在那里如果没有数据覆盖上去的话。

#测试环境准备命令：mysql> create database testdb;Query OK, 1 row affected (0.08 sec)mysql> mysql> use testdb; Database changed mysql> mysql> create table aa(id int not null primary key, name varchar(20)); Query OK, 0 rows affected (0.34 sec)mysql> mysql> insert into aa values(1,'a'),(2,'b'),(3,'c'),(4,'d'); Query OK, 4 rows affected (0.17 sec) Records: 4 Duplicates: 0 Warnings: 0mysql> select * from aa; +----+------+ | id | name | +----+------+ | 1 | a | | 2 | b | | 3 | c | | 4 | d | +----+------+ 4 rows in set (0.00 sec)

testdb数据库表文件：

#删除数据库：#使用SQL命令 drop database testdb;#使用rm rm -rf testdb/

那么，这种情况下的数据库恢复动作就简单了，参考前面介绍Innodb引擎时的恢复方法即可：

1，完整的恢复testdb目录及目录下的文件即可找回删除掉的库名和表数据，然后针对具体的表引擎，将数据重新导入到数据库中即可。

2，如果找回的是非完整的，那么操作思路是一样的，能恢复多少恢复多少，剩余的如果实在找不回来，从最近一次的备份里提取，然后依靠其他手段比如单据来补全数据。

还是不知道怎么恢复MySQL数据库？找后悔药MySQL数据恢复houhuiyao.cc吧！

一、附加数据库与分离数据库相反，只有分离的数据库才能附加，分离后的数据库不能再正常读取，只有附加后才能读取；而还原数据库是指在原有数据库的基础上进行，一般选择覆盖原有数据库，SQL中如果不存在这个库是不能还原的（物理设备上要有库文件）。客户的服务器需要重装，小编是先备份原库（使用软件或SQL备份或停止SQL直接拷走数据库文件或在PE下拷走），重装完成后拷回原位置直接附加（个人经验附加始终比还原快），使用还原的情况比较少。还原数据库小编之前已经分享过，这里不再赘述。今天小编来分享下数据库的分离与附加。

二、分离数据库

1、选中要分离的库—右键“所有任务”—分离数据库

2、如果存在数据库连接可“清除”，点击“确定”

3、分离成功

三、附加数据库

1、要在“数据库”上右键—所有任务—附加数据库

2、附加数据库界面：点击按钮

3、选择要附加的数据库文件，注意要选择.MDF的文件，.LDF是日志文件

4、选择好后的界面，注意“指定数据库所有者”，有的是sa，有的是其它的，比如科脉是km

5、点击“确定”，附加成功

四、有时候轻度数据库置疑也可以通过“分离—附加”来修复，不过还是不建议这样做。我是百家号作者小白信息说，专注电子信息领域经验分享、技术交流，感谢关注！

故障描述：

5块2T硬盘组建RAID5，划分LUN供windows服务器使用。在windows服务器内装有Sql Server2008数据库。存储空间内共有三个逻辑分区，大小分别为500G、800G、2.3T。数据库文件丢失，主要涉及五个数据库，表个数约为6000个左右。丢失原因未知，且不能确定数据存储位置。三个数据库的大小分别为8G、15G、20G。在文件丢失后服务器仍处于开机状态，但并未写入大量数据。

初检流程：

1、使用RAID信息及内部数据块信息重组RAID。

2、提取LUN内三个分区镜像。

3、扫描文件系统内丢失文件，未找到被删除数据库文件。

4、初检结果为数据库文件丢失，通过文件系统角度无法恢复。

恢复流程：

1、制定恢复方案。在数据库文件被删除且判定为无法恢复文件后，只能通过扫描数据页，并提取页内记录的方式进行恢复。

2、使用北亚自主编数据页扫描程序扫描分区内数据页并提取。在分别扫描两个分区镜像后发现500G系统盘内数据页数量极少且数据页断裂情况严重，另一分区内扫描到数据页个数较多。暂定此分区为数据库文件存储空间。

3、重组系统表。Sql Server数据库使用系统表来管理所有用户表，在这些系统表内记录了各表的列数、数据类型及约束信息等。解析系统表过程中发现提取出的数据页内系统表损坏，无法正常读取信息。在与客户沟通后得知有备份文件，且备份完成后没有大量改动表结构，系统表可用。

4、还原备份。

5、分别提取三个库中各表表结构信息

6、解析表结构脚本。将各表的列信息存入数据库内便于后续使用。

7、解析系统表获取用户表id信息、关联表结构与数据页。（为保护客户隐私，后续步骤涉及用户表表名及数据页内数据部分均未截图）

8、新建数据库，使用北亚自主编写软件解析记录并导入到恢复环境内。

9、整理恢复结果。在此分区内除数据库文件外还存有备份文件若干，所以在导出记录后可能存在重复数据，必须去重。编写SQL存储过程进行去重。

10、客户验证数据。客户在查验过数据后表示数据可以接受，移交数据到客户存储设备，恢复成功。