记一次mysql数据恢复

确切的说更像是一次数据迁移。

背景介绍:

操作系统:Windows Server 2008 R2

数据库版本:MySQL 5.5

数据库的安装目录与数据文件目录不在同一个磁盘,数据文件所在的目录磁盘损坏。而后通过数据恢复工具恢复数据文件。前期研发的同事尝试启动恢复数据库,不成功,多轮尝试不成功后找到我。

1.得到同事给的数据文件 ibdata1,Mysql安装目录MySQL\MySQL Server 5.5。调整my.ini文件尝试启动数据库。

2.将mysql base dir 拷贝到英文目录D:\test,重新配置my.ini。切换目录尝试启动。

3.启动另外一个窗口尝试登录

4.尝试跳过密码验证,设置参数skip-grant-tables

5.查看数据库

6.并没有发现业务库,进一步查看用户。

7.查看搜索引擎,InnoDB启动了。

8.查看错误日志

170121 11:31:27  InnoDB: Error: page 7 log sequence number 1055477743
InnoDB: is in the future! Current system log sequence number 566049292.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
170121 11:31:27  InnoDB: Error: page 1 log sequence number 1055476531
InnoDB: is in the future! Current system log sequence number 566049292.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files. See
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: for more information.

9.看到了报错,日志文件与数据文件内容不符。 证明数据文件是读到了的,只是,没有业务用户,没有表的定义。重新与报表工程师沟通,得知业务库数据库名为JD,用户也为JD。开始感觉有地方不对劲了,如果只是Innodb的数据文件损坏,mysql.user中应该是有用户记录的呀,怀疑这个安装目录不是原始的Mysql安装目录。

10.找到原始安装目录,进行目录替换。

11.可以查到数据了。尝试通过mysqldump 的方式导出数据。

mysqldump --database jd > jd_db.sql

之后搭建好新的环境,导入数据库,创建好用户,授权。(唯一注意的一点是字符集的问题)

至此整个数据恢复工作完成。

时间: 2024-08-05 13:47:02

记一次mysql数据恢复的相关文章

【夯实Mysql基础】记一次mysql语句的优化过程!

1. [事件起因] 今天在做项目的时候,发现提供给客户端的接口时间很慢,达到了2秒多,我第一时间,抓了接口,看了运行的sql,发现就是 2个sql慢,分别占了1秒多. 一个sql是 链接了5个表同时使用了 2个 order by和 1个limit的分页 sql. 一个sql是上一个sql的count(*),即链接了5个表,当然没有limit了(取总数). 2. [着手优化] 1)[优化思路] 第一条是 做client调用 service层的数据缓存 第二条就是 优化sql本身. 这里着重讲一下

记一次MySql入库后,文本出现乱码的问题

最近采用ADO.NET开发了一个工具,解析了一条如下的日志并入库(MySql) 2014-08-19 00:37:10 [INFO] roleName=♣丶伊诺,orderId=1408190037102121039,price=10.0,point=100 发现入库后的roleName中的♣显示为□乱码了,一开始以为是表的编码问题,确认后是utf-8编码木有问题,后来又排除了文件编码及代码中的字符串都没有乱码的问题,凭经验分析,可能是连接字符串的问题吧,后来把MySql的连接字符串中也加入了u

记一次揪心的MySQL数据恢复过程

https://blog.csdn.net/poxiaonie/article/details/78304699 === 先说下背景,公司其中一个项目所有服务都部署在客户的机房内,机房较小,没有UPS.其中一个MySQL实例(单机,无主从,windows server 2008,MySQL5.6.19)存放大量的日志数据,每天几十G的数据,定期清除(保存大概四个月的数据),由于硬盘空间不够,所以没有定期的备份.机房突然断电,启动MySQL server,当时没有注意错误日志,但是访问其中一个表时

MySQL 数据恢复 全备份恢复以及增量恢复 (以手残删库为例)

数据恢复原理图 测试环境 MySQL5.5 1 首先新建数据库 lampol  数据表 test create database lampol; use lampol; create table test (id int(10),name varchar(10)); 2 插入数据信息 insert into test values(1,'lampol1'); insert into test values(2,'lampol2'); 3 插入后的信息 mysql> select * from l

记一次Mysql魔鬼实训

1.查看某个Mysql数据库当前使用的字符集 show create database [库名称] 2.查看当前书库版本信息 #mysql -V MariaDB [(none)]> use mysql; MariaDB [mysql]> select version(); 3.查看当前登录的用户 MariaDB [mysql]> select user(); 4.创建GBK字符集的数据库test1; MariaDB [mysql]> create database test1 de

MySQL · 数据恢复 · undrop-for-innodb

摘要: 简介 undrop-for-innodb 是针对 innodb 的一套数据恢复工具,可以从文件级别恢复诸如:DROP/TRUNCATE table, 删除表中某些记录,innodb 文件被删除,文件系统损坏,磁盘 corruption 等几种情况. 简介 undrop-for-innodb 是针对 innodb 的一套数据恢复工具,可以从文件级别恢复诸如:DROP/TRUNCATE table, 删除表中某些记录,innodb 文件被删除,文件系统损坏,磁盘 corruption 等几种

记一次MySQL找回用户数据

事情经过 有天,我们公司外区的一个销售C说他8月3号以前的工作流记录找不到了.问清缘由,原来是更新了微信号(我们公司的工作流是基于企业微信开发的).经过分析,微信号和流程数据并没什么关系,所以初步得出结论:本来只需要更新微信号的,结果我们公司的流程系统管理员把用户先删除,再创建了新的用户. 解决过程 1.首先想到的是直接从定时备份数据里面找回原来的用户ID,结果发现系统只备份了十天的记录,而工作流系统上显示销售C只有8月3号以后的流程记录,距今已经40多天,从自动备份的数据里已经无法恢复. 2.

mysql数据恢复

1.找到mysql mysql-bin* 存放位置.查看安装路径 ps -ef |grep mysql 2.连接数据库 mysql -h127.0.0 -uuser -ppwd  查看当前所记录的mysql-bin 文件 show master status;   记下 File 字段值 (这个就是当前的log文件)3.退出mysql客户端   回到mysql mysql-bin* 存放位置. 4.从log文件中找出你删除执行的语句 按时间 mysqlbinlog --no-defaults -

记一次mysql的preparedStatement使用超限问题

[现象&背景] 本服务是个为数据库的分库分表提供路由规则计算,sql过滤执行的中间服务.即上游将请求发给本服务,本服务根据分库分表规则将相应的sql执行发送给对应的分库.分表去执行,并整理结果返回给上游. 2016-07-14下午,上游流量切换后,mysql大量报出" Can't create more than max_prepared_stmt_count statements (current value: 16382)",mysql不能工作导致本层数据库路由服务不能工作