MySQL数据库INNODB 表损坏修复处理过程

最近mysql数据库经常死掉,用命令net stop mysql命令也无法停掉,关闭Tomcat的时候,出现Waiting for N instance(s) to be deallocated 信息。查了下,大概就是程序没有对数据库连接释放,导致Connection泄露了。因为用的是开元集成的平台,内部程序也不可能一下子给改掉的,就验证一下咯。启动Tomcat,用户登录系统,用netstat -ano|findstr 8000命令来查看tomcat端口占用情况,可以看到8000端口会被用户的IP地址占用,而对应的PID是0,PID=0是什么呢,是叫System Idel Process的一个进程,这个进程是一个空闲的进程。Tomcat一直被这个进程占用,没有释放,时间长了用户多了,mysql就死掉了,至于是不是程序没有释放连接,这个应该是没可能,因为系统已经用了2年,这种情况出现的太少了。
看一下mysql中表的情况,表的数据长度到达了几个G了,这种是BLOB类型的,存储的数据过多,这样的话是不是因为数据量太大,用户在用的时候对数据库进行操作,空间又不够,互相等待,造成死锁的问题呢?
     这年头,一定要注意备份啊,mysql要备份的东西比较多,
     (1)表结构文件,MySQL\MySQL Server 5.1\data目录下存放的就是数据库结构,会看到相应的数据库目录,数据库目录下面有.frm文件,.myd文件,.myi文件,这些文件都是表结构的文件。
     (2)表数据文件,MySQL Datafiles/ibdata1文件
     (3)日志文件,MySQL\MySQL Server 5.1\data目录下面ib_logfile0文件和ib_logfile1文件。二进制日志文件,如果你想要重新处理日志止的语句,这很有用。
     你的数据库结构没有问题的情况下,想恢复数据,如果有(2)、(3)应该是没有问题的,当时我只有(2),把ibdata1文件copy过去,恢复数据还是出了很多状况,启动系统还是不能用的,mysql日志一直提示Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files.说多了都是泪,谁让咱是IT呢,系统坏掉了电话都要被用户打爆的节奏,hold不住,无所不用其极的,各种搜索资料啊,最后尝试一下大多数人的办法,设置innodb_force_recovery参数。
    innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0,表示当需要恢复时执行所有的

innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。当设置参数值大于0后,可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。

1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash。
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
    设置innodb_force_recovery=4重启msql,再恢复成默认值(即不需要再my.ini文件时设置innodb_force_recovery参数),重启mysql,重启Tomcat,OK了,太惊喜了。
    菜鸟一个,其中原理讲的都不太清楚,经验之谈,仅供参考。

你可能感兴趣的:(tomcat,mysql)