简单粗暴 恢复user表 1.先建立和之前user表一样的表结构.就是执行create table user .... ,执行完,数据库目录下就会建立user.ibd文件(当然还有其他的) 2.执行 alter table `user` discard tablespace ; 执行完之后,数据库目录下的user.ibd文件就没了 3.把你备份的ibd放到消失的user.ibd文件那里. 4.给这个文件加权限,所有者mysql ,权限660(你可以参考别的ibd文件所有者和权限设置) (这一步我

我们知道启用innodb_file_per_table选项后,单个表(InnoDB引擎)的数据和索引放入单独的文件中(.ibd),建表语句保存在.frm文件中本文假设192.168.85.132,3306实例无法启动(磁盘还能访问),需要将原实例下的replcrash.py_user表恢复到192.168.85.132,3308实例 一..frm得到建表语句 mysqlfrm可以读取.frm文件并从该文件中找到表定义数据生成CREATE语句.在大多数情况下,生成的CREATE语句用于在另一个服务

一.恢复到某个二进制文件 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

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

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

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

一.查看下自己的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

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

昨日晚上开发告诉我不小心truncate两个表的数据,要求还原.结果在阿里云上找到了备份内容,结果是物理备份文件.frm..ibd.心中一万个草泥马啊..没办法,开始还原吧. 1.查看测试机Mysql配置文件位置 [root@localhost mysql]# which mysqld /usr/sbin/mysqld [root@localhost mysql]# /usr/sbin/mysqld --verbose --help| 'Default options' Default opti

在本地搭建测试环境录入的数据放到线上测试,备份了数据表为一个.sql文件, 在服务器上登录mysql执行 source (如:source exposition_exposition.sql) 文件路径 居然可以自动执行  以前还真不知道source这个命令.特此记录下来!!!!!!!

经常有网站管理员因为各种原因和操作,导致网站数据误删,而且又没有做网站备份,结果不知所措,甚至给网站运营和盈利带来负面影响.所以本文我们将和大家一起分享学习下如何通过Mysql的二机制日志(binlog)来恢复数据. 系统环境: 操作系统:CentOS 6.5 X64  (虚拟机): WEB服务:PHP+Mysql+apache: 网站:为方便,直接在本地用蝉知系统搭建一个DEMO站点: 操作步骤: 1.开启binlog功能及基本操作: 2.往站点添加数据: 3.刷新binlog日志: 4.删除

一.备份的原因 运维工作的核心简单概括就两件事: 1)第一个是保护公司的数据. 2)第二个是让网站能7*24小时提供服务(用户体验).  备份的原因 1)备份就是为了恢复. 2)尽量减少数据的丢失(公司的损失) 二.备份的类型 1.冷备份: 这些备份在用户不能访问数据时进行,因此无法读取或修改数据.这些脱机备份会阻止执行任何使用数据的活动.这些类型的备份不会干扰正常运行的系统的性能.但是,对于某些应用程序,会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据. 2.温备份: 这些备份在读

.frm文件:保存了每个表的元数据,包括表结构的定义等: .ibd文件:InnoDB引擎开启了独立表空间(my.ini中配置innodb_file_per_table = 1)产生的存放该表的数据和索引的文件. 1.安装相同版本的mysql: 找回表结构 2.找回表结构(若有表结构,直接导入表即可) 建立同名的表(InnoDB),不知道列数的话随意一个字段即可(如果字段个数不一致会报错,去日志文件中查看有列数重复这些步骤) 关闭mysql服务 用需要恢复的.frm文件覆盖新生成的.frm文件.

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

参考:https://www.jianshu.com/p/50a2e13cd5cf 安装MySQL Utilities 下载地址:https://dev.mysql.com/downloads/utilities/ 下载完后直接安装即可 如果运行时需要python就下载 https://dev.mysql.com/downloads/connector/python/ 本机还需要安装与需要恢复数据的一样版本的Mysql 使用mysqlfrm命令读取frm的表结构 把需要进行数据恢复的frm文件放

ibdata1是一个用来构建innodb系统表空间的文件,这个文件包含了innodb表的元数据.撤销记录.修改buffer和双写buffer.如果file-per-table选项打开的话,该文件则不一定包含所有表的数据.当innodb_file_per_table选项打开的话,新创建表的数据和索引则不会存在系统表空间中,而是存放在各自表的.ibd文件中. 显然这个文件会越来越大,innodb_autoextend_increment选项则指定了该文件每次自动增长的步进,默认是8M. ibdata

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

MySQL Binary Log也就是常说的bin-log, ,是mysql执行改动产生的二进制日志文件,其主要作用有两个: * 数据回复 * 主从数据库.用于slave端执行增删改,保持与master同步. 1.开启binary log功能 对于mysql也是支持增量备份,但要打开mysql的bin log功能. 我们修改mysql的配置文件.linux是/etc/my.cnf,windows是mysql的安装目录/my.ini 我们在[mysqld]下面加上log-bin一行代码,如下面.

前提:保存了需要恢复数据库的文件 .frm 和 .ibd 文件 条件:InnoDB 类型的 恢复表结构1.新建一个数据库--新建一个表,表名和列数和需要恢复数据库相同2.停止mysql服务器 service mysql stop ,3.在/usr/local/mysql/my.cnf 里面添加innodb_force_recovery = 64.将需要恢复的表.frm格式文件 覆盖/usr/local/mysql/data/数据库 下的.frm格式文件5.启动mysql服务器 service m

如题,究竟该使用mysqldump还是xtrabackup,要说用,两个都能备份,都支持热备,但是生产环境我们要考虑的是效率,就是不管备份还是恢复,都要快,要稳定. 之前我在维护mysql数据库的时候,使用mysqldump来进行备份与恢复,在备份的时候锁住表,然后全部备份,在数据少的时候没问题,但如果数据很多,不允许锁表,同时需要恢复数据块的情况,mysqldump就不适合了,我在恢复一个4G数据文件的数据库的时候,恢复的数据是使用mysqldump的数据,恢复了3个小时还没有反应,造成的影响

本文适用于,mysql无法启动,但数据文件未丢失的情况. Mysql因意外情况,导致无法启动,数据库未做备份的情况下,如何将数据迁移至其他数据库中. 原数据库地址:192.168.1.100(以下简称A服务器) 新数据库地址:192.168.2.100(以下简称B服务器) 数据恢复流程: 进入A服务器,输入命令 cat /etc/my.cnf (如文件不在当前位置,可使用find / -name my.cnf  命令查询文件位置) 找到datadir 路径 通过cd /www/server/da