MYSQL官方截止目前还没有出来数据闪回特性,也许后续版本会出现。 社区有一些开源工具可以使用,沿用的基本都是彭立勋最早提出的思路,利用binlog对SQL进行反向解析,从而实现数据闪回,例如不带where条件的update操作,导致全表数据被误更新。 闪回前提: binlog_format = ROW 操作模拟: 没加where条件,导致全表更新;或者没加host列,导致多余行被更新。 闪回方式: 一、利用mysql自带的mysqlbinlog命令解析binlog,再通过grep、sed等命令把binlog中相关SQL误操作给逆向回来,然后导入SQL文件来恢复错误操作。 -27 11:40:00" --stop-datetime="2017-11-27 12:00:00" | egrep -A4 -i 'UPDATE `mysql`.
---- 前言 MyFlash 是美团点评开源的一个 MySQL 闪回工具,可以用来回滚 MySQL 中的 DML 操作,恢复到某时刻的数据。 本文将简单地介绍 MySQL 闪回工具 MyFlash 的使用。 限制 MyFlash 工具存在如下限制: binlog 格式必须为 row,且 binlog_row_image = full 仅支持 5.6 与 5.7 版本的 MySQL 只能回滚 DML( 增、删 --start-position 指定回滚开始的位置。如不指定,从文件的开始处回滚。请指定正确的有效的位置,否则无法回滚。 --stop-position 指定回滚结束的位置。 ="2020-11-29 17:24:30" --sqlTypes="UPDATE,DELETE" --binlogFileNames=/opt/mysql/log/binlog/3308/mysql-bin
但是在记录闪回日志时,只会将改变前的值保存在flashback buffer中,再由RVWR写入闪回日志中。 闪回时,从闪回日志的尾部向头部方向,依次取出闪回日志中的记录并应用在数据库上。 ,NAME闪回日志的位置,FIRST_CHANGE#闪回日志中记录的最早的SCN,FIRST_TIME闪回日志中记录的最早时间 启用数据库闪回模式 如果想启动FLASHBACK DATABASE的功能 recovery area中的闪回日志将自动全部删除 2.即便以resetlogs打开数据库,当前闪回日志里的内容仍然保留,仍然 可以继续进行闪回以restlogs方式打开数据库。 3.如果闪回数据库的时间点之间进行了控制文件的恢复或重建,数据文件的收缩,或删除了某个表空间,则闪回将失败。 4.闪回日志在出现空间压力的情况下,oracle会自动删除闪回日志,则有可能导致无法闪回到指定的时间点。
参考资料:Using Oracle Flashback Technology Oracle 11g的新特性闪回操作 闪回查询 闪回查询 闪回版本查询 闪回事务查询 闪回数据 闪回表 闪回删除 闪回数据 21:12:11 SQL> commit; 提交完成。 闪回归档 参考资料: Using Flashback Data Archive (Oracle Total Recall) Oracle 11g 闪回数据归档 闪回归档:Flashback Data Archive 信息写出到日志文件,ARCH进程负责进行日志归档;在Oracle 11g中,新增的后台进程FBDA(Flashback Data Archiver Process)则用于对闪回数据进行归档写出。 闪回数据库 参考资料:Oracle DB闪回(Flashback database)开启笔记 数据库的闪回 是Oracle不同于查询闪回和归档闪回的另外一种闪回机制 Oracle 10g引入 需要配置闪回区域
-B --生成回滚SQL [root@wallet01 ~]# mysql -uroot -pabcd.1234 mysql> grant select,replication client,replication slave on *.* to 'flashback'@'%' identified by 'flashback'; mysql> flush privileges; mysql> show master ]# mysql -utpcc -ptpcc mysql> select now(); +---------------------+ | now() | +-------- mysql> select count(*) from warehouse; +----------+ | count(*) | +----------+ | 10 | +-------- -utpcc -ptpcc < rollback.sql [root@wallet01 ~]# mysql -utpcc -ptpcc mysql> use tpcc Database changed
---- 操作数据库时,如果不慎执行了 DML 误操作,闪回工具可以回滚这类 DML 误操作。 闪回之前 在使用闪回工具之前,需要明确几个小问题: 哪些 SQL 类型可以使用闪回工具? 可以使用闪回工具回滚的 DML 类型包括:DELETE、INSERT、UPDATE,不支持 DDL。 需要满足哪些条件才能使用? 如果 DML 操作涉及的数据量较小,则推荐直接在应用侧执行闪回语句效率更高,但闪回语句需要经过应用侧确认之后,在应用层执行。 有哪些闪回工具推荐? 目前比较主流的 MySQL 闪回工具有 binlog2sql[1]、my2sql[2]、MyFlash[3] 三款。 使用闪回工具只是一种补救措施,安全运维应该在预防误操作上有哪些安排呢? 一个让运维人员睡的安心的数据保障系统(MySQL 版)。 预防,为了减少数据误删除发生的概率,通过交付基线避免。
二、GaussDB T 的 Flashback Table 功能非常强劲可以闪回TRUNCATE Gaussdb提供了类似Oracle的闪回表功能;可以很好的应对drop table或者truncate 闪回被drop table SQL> flashback table roger.test to before drop; Succeed. 那么truncate 的表能闪回吗 ? SQL> create table roger.test_copy as select * from roger.test ; Succeed. SQL> 可以看到成功闪回了被truncate table。 那么如果表被truncate之后,被写入数据之后,还能闪回吗? 下面测试一下。 可以看到非常强大;仍然可以进行闪回。。。。 这样妈妈再也不用担心数据被truncate了。。。。 那么如果表被ddl change了,还能闪回吗? 我们进一步验证一下呢?
也有团队利用LVM快照来缩短恢复时间,但快照的缺点是会影响mysql的性能。 MySQL闪回(flashback)利用binlog直接进行回滚,能快速恢复且不用停机。 本文将简单进行mysql根据binlog闪回数据的实战测试 基础知识准备 binlog是二进制日志文件,用来记录Mysql内部对数据库的改动(只记录对数据的修改操作),主要用于数据库的主从复制以及增量恢复 所以有这种根据binlog得到执行sql语句、闪回sql语句,我们只需要利用根据分析binlog,然后就可以找到准确的数据改动sql,并得到闪回sql,检查无误后执行就可以恢复数据了 准备工作 我们采用 有三条语句 然后每一条语句的最后面还有这样子一段注释 #start 590075 end 590633 time 2019-09-14 22:05:35 这代表的是在log文件中的起始位置和结束位置 闪回 sql语句 我们有了起始位置和结束位置,就可以利用工具,得到这一部分变化的闪回sql了 前面的大部分参数都一样 后面的筛选日期参数变成了起始位置和结束位置的值 还有一个-B即可 python binlog2sql.py
闪回恢复其实是利用回收站的闪回恢复删除的表。利用MVCC机制闪回恢复到指定时间点或者CSN点(commit sequence number)。 闪回技术能够有选择性的高效撤销一个已提交事务的影响,从人为错误中恢复。在采用闪回技术之前,只能通过备份恢复、PITR等手段找回已提交的数据库修改,恢复时长需要数分钟甚至数小时。 重要提示: 遗憾的是,官方文档关于闪回恢复的前提条件并没有描述到位,导致初次接触该功能的小伙伴有些茫然(我也是),无法复现闪回恢复的特性操作。 的闪回功能。 执行闪回查询命令,查看闪回结果 基于timestamp的闪回查询 select * from t1 timecapsule timestamp to_timestamp('2021-10-12 10:03
首先尝试Flashback Query闪回数据。 dbms_flashback.get_system_change_number fscn from dual; FSCN ---------------------- 1551702 使用应用用户尝试闪回 根据业务提供的大致误操作时间,结合V$ARCHIVED_LOG视图,选择适当SCN向前执行闪回查询: SQL> select count(*) from emp1 as of scn 1551171 由业务人员通过emp1_recov表确认,向当前表补回误删除的数据,至此闪回恢复成功。没有闪回特性的话,需要通过物理备份执行不完全恢复,或者找出足够及时的逻辑备份来进行恢复,其过程都可能是极其复杂的。
环境:RHEL 6.4 + Oracle 11.2.0.4 目录: 一、闪回查询 1.1 闪回查询举例 1.2 闪回版本查询举例 二、闪回事物 2.1 闪回事物查询的先决条件 2.2 闪回事物查询 三、闪回表 四、Flashback Data Archive 五、闪回数据库 5.1 配置闪回数据库 5.2 使用闪回数据库 5.3 监视闪回数据库 Reference 一、闪回查询 -- 初始化参数 alter flashback archive fa_data add tablespace fda3 quota 50M; --清除归档fa_data归档中2015年11月17日前的所有行: alter flashback archive fa_data purge before timestamp to_timestamp('2015-11-16 00:00:00','YYYY-MM-DD HH24 5.1 配置闪回数据库 5.1.1 开启闪回数据库: --必须配置闪回恢复区 show parameter db_recovery --必须归档模式 shutdown immediate; startup
Oracle闪回原理-Logminer解读redo(r11笔记第17天) 但是对于DDL的闪回,这个特性真是非常强悍了。比如一个truncate操作,它的逆操作改怎么定义,就很难去界定了。 我们开启闪回数据库的功能。 alter database flashback on;这个时候查看闪回区,会发现突然多出了两个闪回日志。 ,但是闪回日志的时间戳会发生变化,证明是在持续更新。 但是闪回日志的大小依旧不会有任何的变化。 听起来闪回日志的作用还是不大明显,如果你做了DML的操作,那这个过程的影响就会放大数倍。 当前的这个测试表数据量在1600万。 而闪回日志是否很忙呢,这下终于忙起来了,而且非常忙,生成了非常多的闪回日志。
============= 闪回技术通常用于快速简单恢复数据库中出现的认为误操作等逻辑错误,从闪回的方式可以分为基于数据库级别闪回、表级别闪回、事务 级别闪回,根据闪回对数据的影响程度又可以分为闪回恢复 ,闪回查询。 闪回日志不能复用,也不能归档。闪回日志使用循环写方式。 数据库的闪回恢复的速度要快于RMAN以及基于用户管理的备份与恢复,其主要原因是因为数据库闪回使用的是闪回日志,而闪回日志中保存的是数据块的完整镜像。 其次闪回能够恢复的程度取决于闪回空间的大小以及闪回的保留策略,闪回空间大小会被循环使用,而闪回的保留策略则决定了闪回日志保留的时间长度。总之,合理的平衡恢复速度与可用空间依赖于具体服务要求。
♣ 题目部分 在Oracle中,什么是闪回?闪回有哪些分类? Oracle中闪回技术分类图如下所示: ? 有关闪回需要注意以下几点: (1)闪回查询、闪回版本查询、闪回事务查询以及闪回表主要是基于回滚(Undo)表空间中的回滚信息实现的。 (2)闪回删除是基于Oracle中的回收站(Recycle Bin)特性实现的。 (3)闪回数据库是基于闪回恢复区(Flash Recovery Area)中的闪回日志来实现的。 (4)闪回数据归档是基于闪回归档区中的数据来实现的。
首先是一个报警信息,可以看到是闪回区超过了报警的阈值,为了尽可能提前发现问题,我把阈值设置为了70%,和Oracle默认的80%有一些差别。 闪回区空间不足引发的SQL问题分析(r10笔记第32天) 不过我们换一种全新的解读方式,就是通过图表来看,基本也能够定位出问题的方向。 这是一个当天抓取到的闪回区使用率的图表,可以看到闪回区在早上的时间段使用率攀升。 ? 那么这个问题该怎么进一步解读呢,我们可以看看是否是一个周期性的问题,下面是一周内的闪回区使用对比图,那么从我这边得到的消息是近期也没有其它的应用变更,这个图表看起来就不大正常了,似乎没有什么特定的规律可循 而且通过上面的图表很可能会得出一个错误的结论,怎么理解呢,我们得到一个月的闪回区使用情况,就会发现这种规律来。闪回区的变化其实还是有一定的规律可循的。 ?
本文主要讲述了FLASHBACK DROP特性以及闪回特性中回收站(RECYCLEBIN)的管理。 1) from "BIN$k1zC3yEiwZvgQAB/AQBRVw==$0"; --可以使用回收站名来访问对象,但要对对象加双引号 COUNT(1) ---------- 13 2.实施闪回并查看闪回后的情况 rename to newtbname; 第二条语句用于被删除的表名已经被再次重用,故闪回之前必须将其改名为新表名,schema不变化 9.如回收站中存在两个相同的原表名,则闪回时总是闪回最近的版本 ,如果闪回特定的表,需要指定 该表在回收站中的名称。 ,而是只能恢复drop 之后的表 11.flashback drop 不能闪回drop user scott cascade删除方案的操作,此只能用flashback database 12.在system
使用限制只能回滚DML, 不能回滚DDL使用回滚/闪回功能时,binlog格式必须为row,且binlog_row_image=full, DML统计以及大事务分析不受影响MySQL8.0版本需要在配置文件中加入 default_authentication_plugin =mysql_native_password,用户密码认证必须是mysql_native_password才能解析此工具是伪装成从库拉取binlog `t1` SET `b` = 'aa' WHERE `id` = 2确定flashback位置mysql> show master status ;+---------------+---------- /回滚误操作$ lltotal 124M-rw-r--r-- 1 root root 107 Sep 14 10:09 biglong_trx.txt-rw-r--r-- 1 root root `t1` SET `b`='b' WHERE `id`=2;数据闪回并不是万能的,备份恢复是最后底线。
从9i开始,Oracle提供了闪回(FLASHBACK)功能。 使用FLASHBACK TABLE语句从撤消段中(undo segment)读取该表的过去映像,并利用Oracle9i中引入的回闪查询重建表行。UNDO_RETENTION给出了闪回支持的最小时间。 (当然,如果回滚表空间的空间分配不足,当系统处于忙时,有可能重用还没有达到UNDO_RETENTION时间限制的数据的空间)。使用闪回的一个前提是表不能进行DDL操作。 不但不能对DDL操作进行回闪,而且,也无法闪回到DDL操作以前的数据了。 一.delete误删 方法1:如果表结构没有改变,直接闪回整个表,具体步骤: --首先需要表闪回权限,开启行移动功能 alter table 表名 enable row movement; --执行闪回恢复表数据到某个时间点
背景 openGauss闪回功能能够有选择性的高效撤销一个已提交事务的影响,从人为错误中恢复。在采用闪回技术之前,只能通过备份恢复、PITR等手段找回已提交的数据库修改,恢复时长需要数分钟甚至数小时。 闪回truncate基于回收站机制,通过还原回收站中记录的表的物理文件,实现已truncate表的恢复。 闪回DROP:可以恢复意外删除的表,从回收站(recyclebin)中恢复被删除的表及其附属结构如索引、表约束等。 后来查看管理员指南,在特性描述倒是说了“ASTORE引擎暂不支持闪回功能。备机不支持闪回操作。”在开发者指南 CREATE TABLE部分找到这么一句话。 因此,由于openGauss建表默认为astore模式,是不支持闪回的。所以,现在需要修改建表脚本为ustore模式。
Oracle 数据库闪回通常设置在 DataGuard 备库,如果主库误删数据,可用备库闪回至删除点之前,获取丢失数据,然后再自动同步回来! 注意: 主库不建议开启闪回,首先影响性能,其次主库不可能为了某些数据去做闪回,所以很鸡肋! 那么,DataGuard 备库如何开启数据库闪回? 需要有充足的磁盘空间 1、第一步,关闭 DataGuard 备库同步进程 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 2、第二步,开启闪回功能 /oradata/fast_recovery_area 需要物理真是存在,设置的闪回区大小即闪回日志占用磁盘空间的上限! 一段时间,确认 100G 空间能够保留多久的闪回日志,大致推算出需要保存固定时间闪回日志的空间,根据实际情况进行修改! ----