MySQL实现基于时间点的恢复

前期说明:我每天指定了数据库凌晨1点做全备,这天有人一不小心,删除了某个数据库里面的一个表,需要恢复,怎么弄?

参考 :http://blog.csdn.net/zhaoyangjian724/article/details/48715321

1  确认log_bin是否打开

mysql> show global variables like ‘log_bin‘; 
+---------------+-------+ 
| Variable_name | Value | 
+---------------+-------+ 
| log_bin       | ON    | 
+---------------+-------+ 
1 row in set (0.00 sec)

如果没有开启在配置文件里my.cnf,添加

[mysqld]

log-bin=mysql-bin

2  在test库里面新建一个表upl

use test;
create table upl;
插入数据
insert into upl values (1,‘tom‘),(2,‘mary‘),(3,‘bean‘);
查看数据
mysql> select * from upl;
+------+------+
| id   | user |
+------+------+
|    1 | tom  |
|    2 | mary |
|    3 | bean

3 在时间点a备份数据库test

mysqldump -uroot -p --databases test > /data/test.sql

4 时间点b再次登录数据库,创建表test.t2

 mysql> create table t2 (a int); 
Query OK, 0 rows affected (0.00 sec) 
mysql> insert into t2 values(10); 
Query OK, 1 row affected (0.02 sec) 
mysql> commit; 
Query OK, 0 rows affected (0.00 sec) 
mysql> select * from t2; 
+------+ 
| a    | 
+------+ 
|   10 | 
+------+ 
1 row in set (0.00 sec)

5 在时间点c删除upl,t2

drop table upl;

drop table t2;

6 要求恢复到时间点b (upl和t2同时存在)

先恢复全库  mysql -uroot -p < /data/test.sql

登录mysql发现upl表已经存在了

挖掘log-bin日志  mysqlbinlog --start-datetime=‘2016-10-21 14:46:10‘ --stop-datetime=‘2016-10-21 14:50:35‘  mysql-bin.000001 > recovery.sql

说明:这两个时间点只能取大概的时间,不能确定精确的时间,可以写上面数据库备份完的那个时间,结束时间就写删除某个表的时间(大概) 这个mysql-bin.000001 日志文件选择最新的那个(距离删除时间最近的)

然后再把这个recovery.sql倒入到数据库里

mysql -uroot -p < recovery.sql

再次登录mysql数据库,发现t2也已经存在了,到此全部恢复完成!

时间: 2024-10-09 06:52:42

MySQL实现基于时间点的恢复的相关文章

基于时间点的恢复

由于误操作,删除了一张表,那么基于时间点的恢复是没有用的,因为日志里还存在着一些误操作,我们需要恢复到误操作之前的状态,然后跳过误操作,再恢复后面的语句,完成最后的恢复 1 如果10点发生误操作 mysqlbinlog --stop-date='2015-06-15 9:59:59' mysql-bin.000015 | mysql -uroot -p test 2 跳过故障时间点,进行后面的恢复 mysqlbinlog --start-date='2015-06-15 10:00:01' my

表空间基于时间点的恢复

步骤:1.检测和解决对要恢复的表空间有依赖关系的对象问题select *  from sys.ts_pitr_check where (ts1_name = 'UERS' and ts2_name != 'USERS')    or (ts1_name != 'USERS' and ts2_name = 'USERS');如果有依赖约束,可以考虑disable掉约束:或者同时还原依赖对象所在的表空间 2.检测哪些对象不会被还原如果有些表,在还原后还需要存在,可以使用数据泵等工具导出,等表空间还原

使用 mysqldump 实现 MySQL 5.7 基于时间点的恢复

创建测试数据全备数据库 mysqldump --single-transaction --flush-logs --master-data=2 --all-databases --triggers --routines --events --set-gtid-purged=off> backup.sql 再新增测试数据删除表中所有数据确认最近一次备份后的二进制日志保存文件 确认删除数据的时间点 mysqlbinlog --base64-output=decode-rows -v mysql01-

Mysql 基于innobackupex 的备份&amp;恢复

备份,对于任何数据库,任何系统都是重中之重.针对Mysql,我选择percona xtrabackup软件.我更喜欢物理层面的热备份.而不是逻辑层面的备份(mysqldump),当然很多情况,也要定期做mysqldump备份.增加一个安全的备份选择. 关于如何下载安装percona xtrabackup,请参考: http://blog.51cto.com/hsbxxl/2107388 先看看innobackupex常用参数 --compact        创建一个不包含第二索引(除了主键之外

Oracle 学习之RMAN(十四)恢复实战--基于时间点恢复

1. 我们先做一个全备 RMAN> backup database ; Starting backup at 2015/07/09 13:40:47 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=28 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in b

基于时间的 SQL注入研究

SQL注入攻击是业界一种非常流行的攻击方式,是由rfp在1998年<Phrack>杂志第54期上的"NT Web Technology Vulnerabilities"文章中首次提出的.时过境迁,相关SQL注入的技术和工具都进行了不断的发展和演化.目前 SQL注入漏洞已经是信息安全的一大领域,无论是小到个人网站,还是大到电子商务网站,都或多或少的存在SQL注入漏洞.为什么SQL注入漏洞会屡禁不止,原因就在于要想防御SQL注入漏洞,需要对SQL语句.业务流程行为.各种主流数据

Mysql的增量备份 及基于时间点与位置的恢复

增量备份的优点是没有重复数据,备份量不大,时间短.缺点也很明显,需要上次完全备份及完全备份之后所有的增量备份才能恢复,反推恢复,操作较为繁琐. Mysql没有提供增量备份的方法,但是可以通过二进制日志间接实现增量备份. 二进制日志对备份的意义如下:1)二进制日志保存了所有更新或者可能更新数据库的日志文件2)二进制日志在启动Mysql服务器后开始记录,并在文件达到max_binlog_size 所设置的大小或者接收到的flush logs命令后重新创建新的日志文件.3)只需要定时执行flush l

13. Clustrix 基于时间点恢复

在不太可能发生灾难的情况下,可以在特定数据库.表或整个集群上执行ClustrixDB集群的某个时间点恢复.应该非常小心地处理这一问题. 先决条件 在你可以使用时间点恢复之前,你的集群应该有几个先决条件: ClustrixDB并行备份的二进制备份应该是可用的.有关此功能的更多信息,请参见ClustrixDB快速备份和恢复.https://www.cnblogs.com/yuxiaohao/p/11956565.html 需要启用binlogging.您可以在配置复制时找到有关启用binlog的信息

MySQL中基于mysqldump和二进制日志log-bin二进制日志进行逻辑备份以及基于时间点的还原

本文出处:http://www.cnblogs.com/wy123/p/6956464.html 本文仅模拟使用mysqldump和log-bin二进制日志进行简单测试,仅作为个人学习笔记,可能离实际应用还有很大差距,仅参考. 开启MySQL的bin-log二进制日志 模拟还原是需要mysqldump出来的文件和log-bin,因此需要开始log-bin二进制日志. mysql5.7.18在开启二进制日志的时候除了要设置log-bin的位置之外,另外需要设置一个server-id,MySQL之前