由于开发人员错误操作，上线代码误传如生产环境，造成生产交易部分功能表数据清空，影响非常恶劣。
出现事故后，迅速与开发人员沟通，得知被破坏的表不是核心交易表，具有数据非实时更新特性，为了对生产数据造成二次破坏，所以采取在测试服务器上恢复备份数据后将数据提取出来并重新导入生产环境的方法。
处理过程：当时测试服务器有一台用作监控的mysql数据库，情况紧急，所以直接就在此数据库中进行备份恢复，但是悲剧的是恢复到一半发现生产数据库的版本与此mysql的版本不一致，解决办法是命令更新升级一下即可，但是这是正在运行的监控库，不能贸然更新升级，所以迅速在另一台服务器上进行mysql搭建恢复，但是更为糟心的是此次恢复也是恢复到一半的时候异常终止，报错log_bin_trust_function_creators参数未打开，原因是备份文件中包含有函数，而新搭建的库的参数为打开，所以造成恢复中断。为了保险起见，根据生产环境的参数文件进行重新搭建mysql并迅速将备份文件导入。
以下记录mysql的常规搭建过程及恢复命令。
需要用到的安装包如下：
MySQL-client-5.5.38-1.el6.x86_64.rpm
MySQL-devel-5.5.38-1.el6.x86_64.rpm
MySQL-shared-compat-5.5.38-1.el6.x86_64.rpm
MySQL-server-5.5.38-1.el6.x86_64.rpm
1.首先检测是否存在旧的mysql版本，有就删除
rpm -qa mysql
删除掉定义的目录及文件。
2.使用rpm命令安装这4个源码安装包。
3.因为使用rpm包安装的MySQL是不会安装/etc/my.cnf文件的，所以将/usr/share/mysql目录下的my-huge.cnf 文件到/etc目录，并改名为my.cnf即可。
然后更改my.cnf配置文件中的内容，此案例直接使用生产环境的内容，特么注意datadir，pid和socket参数的设置。
4.给配置文件中定义的目录赋权限，都是属于mysql。
5.安装
/usr/bin/mysql_install_db --defaults-file=/etc/my.cnf --datadir=/data/mysql/data --user=mysql
6.启动服务
service mysql start
安装过程中会遇到各种各样的奇葩问题，一般都很简单，查询度娘即可解决。
7.当mysql正常启动后，迅速创建生产库。
create database testpay;
8.然后将备份文件导入到新库中
mysql -h 127.0.0.1 -p testpay < db_testapy_bak_2016-05-04.sql
9.因为备份文件是凌晨备份的全库，所以如果要恢复到故障发生时候的那个时间点，还需要使用binlog命令重新执行缺失的日志文件。
mysqlbinlog -h 127.0.0.1 --start-datetime="2017-02-04 02:01:00" -d testpay fb-bin.000357 |mysql -h 127.0.0.1 -p
mysqlbinlog -h 127.0.0.1 -d testpay fb-bin.000358 |mysql -h 127.0.0.1 -p
mysqlbinlog -h 127.0.0.1 -d testpay fb-bin.000359 |mysql -h 127.0.0.1 -p
mysqlbinlog -h 127.0.0.1 --stop-datetime="2017-02-04 11:12:10" -d testpay fb-bin.000360 |mysql -h 127.0.0.1 -p
10.当所有恢复完成后，需要将缺失表数据导入生产环境。
问题总结：此次恢复过程一波三折，主要是笔者对mysql使用也是半路出家，大多都是自己摸索前进。很多常识性的错误多有发生，谨以此次故障记录作为mysql深入学习的教训。
