十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
情况1、如果你有该库的整体备份或对这个表的单独备份,那么也许可以恢复。可以将最新的备份恢复到一个备用的服务器上,导出那表的内容,完成恢复
创新互联公司是专业的渝水网站建设公司,渝水接单;提供网站制作、网站建设,网页设计,网站设计,建网站,PHP网站建设等专业做网站服务;采用PHP框架,可快速的进行渝水网站开发网页制作和功能扩展;专业做搜索引擎喜爱的网站,专业的做网站团队,希望更多企业前来合作!
情况2、如果没有任何备份,那就基本没戏了。一般删除表的操作是drop table,日志中不会记录删除具体行数的记录。表所对应目录下的文件已经被删除(innodb独立表空间,单表归为一文件)。同样的情况适用于myisam数据库引擎,对应的myd/myi/frm文件均被删除。这不像windows还有垃圾箱,是不可逆的操作
1、首先构建测试环境数据create table t1(a varchar(10),b varchar(10));insert into t1 values('1','1');insert into t1 values('2','2');commit;。
2、模拟误修改,将t1表中的b字段更新为错误数据 "123456"update t1 set b='123456' where a='1';commit;select * from t1;。
3、将恢复工具上传到服务器并进行解压。unzip binlog2sql-master.zip。
4、得到误修改时的binlog文件(show binary logs;),实验环境是mysql-bin.000011。
5、通过 binlog2sql.py 脚本的到所有 对表 t1 的修改操作。python binlog2sql.py -hlocalhost -P23307 -ubinlog2sql -p'binlog2sql' -dtest -tt1 --start-file='mysql-bin.000011'。
6、得到了误删除的sql的准确位置在1382-1615之间,使用 _**-B**_ 选项生成回滚sql。python binlog2sql.py -hlocalhost -P23307 -ubinlog2sql -p'binlog2sql' -dtest -tt1 --start-file='mysql-bin.000011' --start-position=1382 --stop-position=1615 -B。
7、执行得到的回滚语句进行误操作恢复。就完成了。
以下情况可以恢复数据:
1 innodb引擎表开启了事务,执行dml语句,比如delete、update、insert之类,并且没有提交即commit操作的话,可以执行rollback进行回滚恢复。如果是ddl操作,如drop、create、alter之类的操作时无效的
2 在进行删除操作之前有备份,比如mysqldump,物理备份数据文件之类的操作,那么可以恢复到删除前的数据
3 如果你的删除操作是直接对data下的文件进行删除,注意,不是粉碎文件操作,那么你可以尝试用磁盘恢复软件来找回被误删的数据文件;
除以上情况,其他真的是没法恢复了,不过貌似很多公司号称能够恢复,要收费,具体他们怎么恢复我就不晓得了。
MySQL开启binlog后,写入操作都会记录到二进制日志里,可以使用mysqlbinlog查看/导出/恢复数据.
假设你之前进行了 mysqldump全量备份,和binlog增量备份(在mysqldump全量备份时使用参数--flush-logs清除全量备份前的binlog).
先恢复之前用mysqldump进行的全量备份,然后用 mysqlbinlog进行时间点还原:
1
找个别的机器安装个同版本的mysql或从已安装同版本的其他机器上(非同版本的也可以试下):
拷贝
mysql/data/mysql
目录到你的mysql/data/
下吧
2
试着启动mysql服务,如果能启动了,理论上应该丢失的只有用户、授权等一些系统信息,不影响你的使用的数据;
如果不能启动,看错误日志,争取启动了。
3
赶紧把数据备份一份出来,重新把所有库(只是你后来创建的业务相关的库,不包括mysql库)都删了,重新导入一遍。理论上不这样也可以,但只是非生产重要的环境下。
4
重新做用户授权。
误删数据的几种操作
如何事前预防误删数据?
误删行数据恢复
误删行数据恢复可以使用 Flashback工具 。
Flashback恢复数据的原理是通过修改binlog内容,拿回原库进行回放,前提是 binlog_format=row和binlog_row_image=FULL 。
在使用Flashback进行恢复的时候, 不建议在主库上进行操作 ,比较安全的做法是恢复出一个备份,或者找一个从库作为临时库,在这个临时库上执行操作,然后再将确认过的临时库的数据恢复到主库。
误删库/表
drop table或者truncate table误删数据表 无法通过Flashback工具恢复 ,因为binlog_format的格式即使是ROW模式,在binlog中记录的也只是一条drop table或者truncate语句,因此无法进行恢复。
此时恢复的方式需要 全量备份加增量日志的方式进行恢复 ,因此要求数据有定期的全量备份,并且实时备份binlog。
假如某人在中午12点误删除了一个库里的某张表,恢复数据的流程如下:
mysqlbinlog恢复数据慢的原因?
如何更快的恢复误删的表?
在用备份恢复出临时实例以后,将这个临时实例设置成线上备库的从库:
假设此时备库的binlog已经被删除,那么需要去binlog备份系统找到删掉的日志文件拷贝到日志目录下,假设文件名是master.000001,打开日志目录下的binlog的index文件,在开头加入master.000001,让备库重新识别此日志文件
延迟复制备库
以上恢复都具有时间不可控性,如果采用上述步骤进行恢复,建议开发成工具(甚至可以做自己的DBA自动化平台),并大量测试后进行使用,避免手动误操作带来更大的问题。
一般的主备复制存在的问题是,假设主库上的表被删除,这个命令很快会被发给所有从库,进而导致从库的数据表也被一起误删除。
延迟复制备库 是可以持续保持与主库有N秒延迟的备库 。
假设这里N=3600,那么表示只要在1个小时以内发现了误删除,就可以的到备库上执行stop slave,再通过之前讲到的方法,跳过误操作的命令(比如将误删除的GTID加到实例集合中),就可以恢复出需要的数据。
rm误删
只要你的集群是高可用,如果rm删除了某个节点(只要不是恶意删除所有节点),HA系统会自动开始工作,选出一个新的主库,从而保证集群工作。