InnoDB拥有内部恢复机制,假如数据库崩溃了,InnoDB通过从最后一个时间戳开始运行日志文件,来尝试修复数据库。
大多数情况下会修复成功,而且整个过程是透明的。
假如InnoDB自行修复失败,那么数据库将不能启动。
在继续 *** 作前,先浏览下MySQL的日志文件,确定数据库是因为InnoDB表的损坏而崩溃。
有一种方法是更新InnoDB的日志文件计数器以跳过引起崩溃的查询,这种情况下,将造成数据的不一致性而且会经常使主从复制中断。
一旦确定MySQL因为InnoDB表损坏无法启动时,就可以按照以下5步进行修复:
1.添加如下配置到/etc/my.cnf文件中
innodb_force_recovery = 4
2.这时就可以重新启动数据库了,在innodb_force_recovery配置的作用,所有的插入与更新 *** 作将被忽略
3.导出所有的数据表
4.关闭数据库并删除所有数据表文件及目录,再运行 mysql_install_db来创建MySQL默认数据表
5.在/etc/my.cnf中删除innodb_force_recovery这一行,再启动MySQL(这时MySQL正常启动)
6.从第3步备份的文件中恢复所有的数据。
MySQL开启binlog后,写入 *** 作都会记录到二进制日志里,可以使用mysqlbinlog查看/导出/恢复数据.1.如果你有归档日志的话,你可以先将数据恢复到上一个备份点,然后使用recover恢复到做命令前的时间点上。呵呵,还是很麻烦的。
2.mysql中的表在正常情况下执行delete 指定删除的记录实际上只是在索引文件中做了删除标记,同时也将数据文件中对记录的头几个字节改写, 但这几个字节具体的与入内容不清楚.
通过研究数据文件, 会发现几种数据类型保存的格式.
varchar: 在该类型数据开始的位置有一个字节来指出后面多少个字节是该字段的内容, 但是有一个例外就是如果后面的内容与varchar字段指定的长度完全相等时,就没有开头的这个字节了.
text: 这个基本上与varchar类型一样, 但是在开始是由两个字节来指出后面的数据长度的. 而且是高位在前,低位在后.
datetime: 为8个字节,同样是低位在前,高位在后, 将其转化为long值后就是yyyymmddhhmmss的格式的数据.
由于要恢复的表中只有这几种数据类型,所以对其他的类型没有研究.
知道了数据储存的格式, 就可以分析数据文件来读取记录了.
需要注意一点就是如果你在删除数据库插入了新的数据, 那么就有可能将原来的数据覆盖掉. 所以应该在删除出错后立即恢复才能恢复出大部分数据
1 找个别的机器安装个同版本的mysql或从已安装同版本的其他机器上(非同版本的也可以试下):拷贝 mysql/data/mysql 目录到你的mysql/data/ 下吧
2 试着启动mysql服务,如果能启动了,理论上应该丢失的只有用户、授权等一些系统信息,不影响你的使用的数据;
如果不能启动,看错误日志,争取启动了。
3 赶紧把数据备份一份出来,重新把所有库(只是你后来创建的业务相关的库,不包括mysql库)都删了,重新导入一遍。理论上不这样也可以,但只是非生产重要的环境下。
4 重新做用户授权。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)