通过.frm和.ibd文件恢复表结构和数据 这里以hue数据库中的desktop_document2表为例 分成两步骤,先去表结构,再取数据,最好在一个用完就可以删除的数据库中进行 取表结构篇: 1.创建一个新数据库,然后创建一个和需要恢复的表的同名表,且引擎必须为InnoDB(即引擎为InnoDB的t_user表,其结构无所谓,字段数量相同就行), 2.关闭数据库服务(service mysqld stop),然后拿原来的desktop_document2.frm替换新建的数据库中的deskt

找到mysql启动位置 whereis mysql 备份指定数据库 包括表结构和数据 使用命令mysqldump 数据库名 -u 用户名 -p > 存储文件路径 [root@izm5e16gjdevwdl8q7q3qoz bin]# mysqldump zlhwebdb -u root -p > /var/www/mysql.sqlEnter password: 查询下 成功生成了 导入sql文件 恢复数据 恢復mysql備份數據 sql 到數據庫裏 (命令行執行) 1.創建數據庫 查詢mys

1.mysql的安装 我是使用apt-get直接安装的 :sudo apt-get install mysql-server sudo apt-get install mysql-client 2.配置mysql管理员密码 sudo mysqladmin -u root 当前密码 新密码 安装的时候貌似也没遇到什么障碍 3.查看mysql的状态 sudo netstat -tap | grep mysql 4.启动/停止/重启mysql sudo  /etc/init.d/mysql start

该方法只介绍了如何救回这个表名(数据不恢复) 如果想要恢复原来数据 直接用extundelete把文件恢复后放回去即可 并且是适用于平时没有全备的情况下  如果有全备 直接那全备的frm和idb文件放回去 就可以了 该方法同样适用于数据表迁移(只迁移一个表)  因为discard再import的速度 远比先dump再恢复的速度要快得多 建议: 平时备份一下表结构是非常重要的  -- 如果你直接删除了mysql的表文件 (.frm .idb)  在mysql5.6 可能你就悲剧了  可能再也用不回

参考:http://my.oschina.net/sansom/blog/179116 参考:http://www.jb51.net/article/43282.htm 注意!此方法只适用于innodb_file_per_table独立表空间的InnoDB实例. 此种方法可以恢复ibdata文件被误删.被恶意修改,没有从库和备份数据的情况下的数据恢复,不能保证数据库所有表数据的100%恢复,目的是尽可能多的恢复. 恢复数据前提是表结构定义文件frm可以使用,如果有下面报错就比较麻烦,需要手动恢复

情况描述:服务器硬盘损坏,服务器换了个新硬盘 ,然后老硬盘插在上面.挂载在这台机器.可以从老硬盘里面拿到数据.只拿到了里面的mysql数据文件夹,把数据文件夹覆盖新的服务器mysql数据文件夹 启动报错!!!报错!!!错!!!. 数据文件如下: 于是觉得不能使用覆盖文件的方式还原数据,得使用科学方法恢复.google之…… 找到解决办法如下: 可以发现数据目录下有对应数据库名称的文件夹,文件夹下有很多 表名.ibd 文件,这些文件其实就是数据,我们要利用它们来恢复 恢复步骤: 1.在新库里面创建

昨晚收到一则求助,一个用户的本地数据库的重要数据由于误操作被删除,需要进行紧急恢复,用户的数据库日常并没有进行过任何备份,binlog也没有开启,所以从备份和binlog入手已经成为不可能,咨询了丁奇,发了一篇percona的文章给我,顿时感觉有希望,于是到percona的官网上下载了恢复工具: 一.安装: .tar -xvf percona-data-recovery-tool-for-innodb-0.5.tar.gz .cd percona-data-recovery-tool-for-i

http://www.ttlsa.com/mysql/mysql-utilities-mysqlfrm/ 以诊断模式读取目录中的所有的FRM文件: D:\Program Files (x86)\EasyPHP-5.3.8.0\mysql\utilities>mysqlfrm --diagnostic "D:/Program Files (x86)/EasyPHP-5.3.8.0/mysql/data/pttuicd" 昨天很悲剧,一直在用easyphp5.3.8,突然想升级了,下

a.开启binlog日志:1)编辑打开mysql配置文件/etc/mys.cnf[root@vm-002 ~]# vim /etc/my.cnf在[mysqld] 区块添加 log-bin=mysql-bin 确认是打开状态(mysql-bin 是日志的基本名或前缀名): b. 下面开始进行场景模拟:1)ops库会在每天凌晨4点进行一次完全备份的定时计划任务 这里手动执行下,将ops数据库备份到/opt/backup/ops_$(date +%F).sql.gz文件中:[root@vm-002

整个恢复过程其实可以总结为下面几步: (1):恢复表结构 (2):复制出来创建表的sql语句 (3):恢复表数据(在恢复表数据的时候,首先需要解除当前创建的表与默认生成的.ibd文件间的关系,接着将要恢复数据表的.ibd文件与当前创建的表联系起来即可) 1.通过官网下载mysql-utilities-1.6.5.tar.gz(https://downloads.mysql.com/archives/utilities/) #tar xzvf mysql-utilities-1.6.5.tar.g

一.查看下自己的MySQL是否开启了binlog日志 # 是否启用binlog日志 OFF:关闭 ON:开启 show variables like 'log_bin'; 二.开启binlog日志 在linxu服务器中找到my.cnf : mysql --help | grep 'Default options' -A 1 执行结果 Default options are read from the following files in the given order: /etc/my.cnf

一.恢复到某个二进制文件 1.开启二进制日志 在mysqld的配置节点下添加如下配置 log-bin="E:/Mysql57BinLog/binlog"(windows下的路径,linux下自行修改路径)  expire_logs_days=10 max_binlog_size=100M 2.重启mysql服务 使用命令show VARIABLES like '%log_bin%';查看 3.创建库和表 create database mytest; use mytest; creat

在以前获取的Oracle数据库备份一般都是dmp文件,创建表空间和用户就直接使用imp或者impdp导入即可. 这一次遇到的情况比较特殊,对方提供数据时给我的是使用SQLPlus导出的SQL脚本文件,是Linux系统中导出的,因为很难让对方再次提供数据,因此只有用这个来导入数据.导入速度慢不说,还挺麻烦,不过没办法,问题总得解决. 在这个过程中遇到两大问题: 1. SQL脚本文件太大(超过1G),Windows上看不了内容,不知道怎么导入到数据库中. 一般SQLPlus执行SQL脚本文件倒是容易

根据二进制日志恢复 目的:恢复数据,根据二进制日志将数据恢复到今天任意时刻 增量恢复,回滚恢复 如果有备份好的数据,将备份好的数据导入新数据库时,会随着产生二进制日志 先准备一台初始化的数据库 mysqld --initialize --user =mysql --basedir=/usr/local/mysql --datadir=/data/mysql/ 启动数据库 service mysqld start 因为数据库版本为5.7,初始化启动后新密码会在mysql-error.log文件中

mysql创建每张表后都会在“mysql安装目录/data/数据库名/”目录下创建一个“表名.frm”文件. 该.frm文件并不能直接打开,但是它可以帮助你恢复你的表结构~~ 具体操作如下: 我现在准备恢复clientmanager数据库中的表结构,其中clientmanager数据库中包含了tb_client表. 那么我先打开新安装的mysql,并创建一个同名的数据库clientmanager: create database clientmanager; 然后在该数据库下创建表tb_clie

以表”Table”为例: 如类型是MyISAM, 数据文件则以”Table.frm””Table.MYD””Table.MYI””三个文件存储于”/data/$databasename/”目录中. 如类型是InnoDB, 数据文件则存储在”$innodb_data_home_dir/″中的ibdata1文件中(一般情况),结构文件存在于table_name.frm中. MySQL的数据库文件直接复制便可以使用,但是那是指“MyISAM”类型的表. 而使用MySQL-Front直接创建表,默认是“

客户的机器系统异常关机,重启后mysql数据库不能正常启动,重装系统后发现数据库文件损坏,悲催的是客户数据库没有进行及时备份,只能想办法从数据库文件当中恢复,查找资料,试验各种方法,确认下面步骤可行: 一.找回表结构,如果表结构没有丢失直接到下一步 a.先创建一个数据库,这个数据库必须是没有表和任何操作的. b.创建一个表结构,和要恢复的表名是一样的.表里的字段无所谓.一定要是innodb引擎的.CREATE TABLE `test`(  `testID` bigint(20)) ENGINE=

客户的机器系统异常关机,重新启动后mysql数据库不能正常启动,重装系统后发现数据库文件损坏,悲催的是客户数据库没有进行及时备份,仅仅能想办法从数据库文件其中恢复,查找资料,试验各种方法,确认以下步骤可行: 一.找回表结构.假设表结构没有丢失直接到下一步       a.先创建一个数据库.这个数据库必须是没有表和不论什么操作的. b.创建一个表结构.和要恢复的表名是一样的. 表里的字段无所谓. 一定要是innodb引擎的.CREATE TABLE `test`(  `testID` bigint

主要用的:binlog.mysqldump.mysqlbinlog 参考: https://www.cnblogs.com/Cherie/p/3309456.html https://blog.csdn.net/okhelp/article/details/79092044?utm_source=blogxgwz25

mysql存储在磁盘中,各种天灾人祸都会导致数据丢失.大公司的时候我们常常需要做好数据冷热备,对于小公司来说要做好所有数据备份需要支出大量的成本,很多公司也是不现实的.万一还没有做好备份,数据被误删除了,或者ibdata损坏了怎么办呢?别担心,只要有部分的frm.ibd存在就可以恢复部分数据. 注意: 一.这个是对innodb的数据恢复.myisam不需要这么麻烦,只要数据文件存在直接复制过去就可以. 二.大家的mysql数据库必须是按表存放数据的,默认不是,但是大家生产肯定是按分表设置的吧,如

mysql 正常运行的时候,查看 table 的结构并不是困难的事. 但是有时 mysql 发生故障,这种方法便不再可行. 当遇到故障,通常使用新的 mysql 实例来恢复当前的数据. 建表是非常重要的步骤,我们必须有其它的方法来寻找 table 的结构. table 结构定义在哪里 通常关注的用户数据,底层都实际存储在 mysql 数据目录. 其它的元数据也不例外,比如 table 表结构的定义. mysql 数据目录文件结构是非常清晰的, 目录对应数据库 frm 文件存储了 table 结构