mysql -默认数据库mysql，performance_schema 被误删除测试案例

前提：内网测试库的默认数据库msql，performance_schema被人不小心删掉。当时创建了一个新的自定义的数据库mcc_2013_user,准备创建存储过程时，错误就出来了。提示mysql.proc 找不到。后来发现不是数据字典表表有错误，是整个系统默认的数据库都被drop掉了。

注：没有备份。

1.第一步，拷贝一份相同的两个数据库文件

>>手动创建系统默认数据库

我手动创建一个同名的数据库，在数据库里面建立同名的数据库字典表，存储过程能顺利创建上吗？答案：可以的，只要不重启数据库，错误就不会显现出来。数据库是暂时被借用的，不做检查。

之后我又在mcc_2013_user数据库上创建了几个基于表的定时任务。

在数据库重启之后，日志里面报找不到事件对应的用户m1，二进制日志文件暴增，磁盘目录一下子就涨到97%。。

登陆系统查询 ps -ef | grep mysql 进程在，但是mysql -um1 -p  -S  /tmp/mysq.socks 根本进不去，悲催的是mysql的root 密码也忘记了，估计就是记得也进不去，因为数据字典表不被识别了。

>>从外网数据库拷贝一份同名的系统默认数据库

用压缩命令打包： zip -r  mysql-performance.zip  mysql  performance_schema ，拷贝到了内网数据库，解压缩到data目录下。

问题：两个数据库版本不一样，内网是5.1，外网是5.5 。不知道结果怎么样，但是要试一试。

这时试着关闭数据库，但是无法关闭，想想先把root的密码找回来在说。

2.第二步，重设root密码

>>修改Mysql 配置文件my.cnf：
# vi /date/mysql/3306/my.cnf
在[mysqld]的段中加上一句：skip-grant-tables 

>>重启数据库mysql ，数据库现在是关闭不了，又登不上去，怎么办呢，查了一下mysql的进程，下了一个死定的决心，用kill命令把进程杀掉了。之后数据库神奇的重新起来了。多亏是内网数据库，要不真不敢这么做。。
>>登录并修改MySQL的root密码
# /date/mysql/bin/mysql
mysql> use mysql ;
mysql> update user set password = password ( 'root') where user = 'root' ;
mysql> flush privileges ;
>>将mysql的my.cnf 配置文件里面的skip-grant-tables 注释掉，或者是删除。重启数据库。

这一步是成功了，拷贝的数据库文件也被识别了。root用户也可以登录了。现在做第三步，清理binlog日志。

3.第三步，清理binlog

>>查询binlog信息

    show binary logs ,发现最后一个日志为000359.

>>删除除最后一个日志外的其它所有的binlog。

mysql> purge binary logs to 'mysql-bin.000359';

Query OK, 0 rows affected (0.00 sec)

--显示binlog列表，就剩一个日志了
mysql> show binary logs \G
Log_name: mysql-bin.000359
File_size: 106

--查看binlog events

mysql> show binlog events \G
Log_name: mysql-bin.000359
Pos: 4
Event_type: Format_desc
Server_id: 1

End_log_pos: 106
Info: Server ver: 5.1.36-log, Binlog ver: 4

>>设置自动清理mysql binlog日志，配置my.cnf：expire_logs_days = 5 。

最后一步，清理所有的日志，不包括当前的被保留的最后一个日志。这一步又出错了。我把所有的日志都给清理掉了。忘记做备份了。备份很重要，重于一切，数据库再次关闭后，又起不来了。报错： mysqld_safe mysqld from pid file /data/mysql/3306/mysql.pid ended。

怎么办呢？思考了一下，决定关闭二进制日志文件试一试。

3.第四步，彻底关闭binlog

注释掉 mysql 配置文件里面的两个参数：
log-bin=mysql-bin
binlog_format=mixed

重启数据库，成功。后来我改变了log-bin日志的路径。在一次shutdown数据库，又启动之后，二进制日志文件重新应用。

这回数据库是彻底恢复过来了。重新投入使用。。

 

小结：第一次自己独立处理这样子的故障，虽然是内网测试库。整过过程下来，思路是一点点清晰的，拷贝过来的默认的数据库是外网测试库的，大概是一样的，但是存放用户名的user数据字典表，不识别root的密码，必须重新设置才行。如果数据字典表里面是完全不一样的东西，我想不仅仅是用户，存储过程，事件，恐怕都得重新创建了。开始担心版本的问题，现在看来高版本是兼容低版本的。还有一个没有尝试，就是利用binlog来做恢复其他被删除的数据库的表。但是看网上这个有点麻烦。下次做一个实验的。好好研究一下binlog。