恢复表结构把刚才移走的几个文件又恢复到了原目录里，既然恢复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/my.cnf）开启或关闭binlog日志。vi /etc/my.cnf 使用加上#可以关闭，去掉开启。 修改后需要重启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，顾名思义一个是开始时间一个是结束时间。
