在 IT 圈内,“删库跑路”已经成为程序员经常提及的一句玩笑话。虽然是玩笑话,但却反映了数据库内数据对企业的重要性。2020年的“微盟事件”就直接让香港主板上市公司微盟集团的市值一天之内蒸发超10亿元,数百万用户受到直接影响。
MySQL闪回(flashback)利用binlog直接进行回滚,能快速恢复且不用停机。
1、 事务开始; 2、 在buffer cache中找到需要的数据块,如果没有找到,则从数据文件中载入buffer cache中; 3、 事务修改buffer cache的数据块,该数据被标识为“脏数据”,并被写入log buffer中; 4、 事务提交,LGWR进程将log buffer中的“脏数据”写入redo log file中; 5、 当发生checkpoint,CKPT进程更新所有数据文件的文件头中的信息,DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。最近在修复一个比较老的项目报表的bug的时候,因为对该项目不太熟悉,导致生产环境数据修改有误,查了资料做了回滚数据,现学习一下Oralce数据回滚以备不时之需。
前一段时间接二连三的出现开发人员在测试环境和生产误操作导致数据库误删除/更新,对DBA而言,回滚数据着实是一件头疼的事情,凡涉及到恢复线上数据必然对应用带来一定的影响。大多数情况是开发误操作delete数据,update多数行,根据之前的操作经验,本文介绍常用的恢复方法。
再说binlog2sql闪回工具之前,我们先聊下binlog。Binlog记录了MySQL数据库所有的DDL和DML操作。它在MySQL数据库里起着至关重要的作用。
背景:服务器上,Oracle数据库数据丢失,开发机上,有数据,但是因为系统坏了(太巧了),先进去把dbf文件备份出来,然后重做了系统(全盘格式化的,不要问我为什么不是只有c盘,售后做的,所以才有了后面数据恢复困难的事情)。
AntDB数据库是一款国产自研的MPP架构的分布式数据库,高度兼容Oracle语法,在通信、金融、交通等多个行业应用广泛。用户在使用AntDB数据库的过程中,经常由于误操作、应用程序Bug等,导致了误删数据或者误更新数据,影响业务正常使用。误删数据不是某个数据库的个例,几乎所有的数据库都会遇到类似问题,并且大多数数据库都会提供一个【数据闪回】的工具,利用该工具可以快速恢复误操作数据。
当执行完全恢复时,会将数据库置于完全最新的状态,包括当前提交的所有数据修改。 然而,不完全恢复会使数据库或表空间回到过去的某个时间点。这也称为“时间点恢复(PITR)”。“这意味着缺少交易;从恢复目标时间到现在所做的任何数据修改都将丢失。在许多情况下,这是理想的目标,因为可能对数据库进行了一些需要撤消的更改。恢复到过去的某个点是解决用户误操作的一种方法。
删库跑路也是个老梗了,可见在运维数据库的过程中误删除数据,或者开发的代码有bug,造成数据的误删除屡见不鲜。不过现在也有许多用于恢复或预防误删除的方案,例如SQL管理系统,将要执行的SQL先交由管理员审核,然后由管理员备份一个镜像数据库,在镜像上执行该SQL,并在执行后还原镜像。这样经过层层把关就可以大大减小出现误操作的几率。
条件:1、误强制删除linux下的数据文件(rm -rf)。2、未重启数据库或操作系统。3、数据库是归档模式
误删oracle数据库中的数据,在不考虑全库备份和利用归档日志情况,怎样快速恢复数据呢?
最近碰到的数据问题还是不少,这个过程中也发现了一些隐患,每次恢复的策略和方法都不大一样,但是最终还是修复了数据。
闪回技术通常用于快速简单恢复数据库中出现的认为误操作等逻辑错误,从闪回的方式可以分为基于数据库级别闪回、表级别闪回、事务
闪回数据库这个特性在很多Oracle DBA眼里就是鸡肋特性,因为谁会因为恢复数据而需要在主库闪回,最后可能丢掉更多的数据,这个观点没错。 但是如果是备库呢,这个特性就顺利成章的满足了绝大多数的恢复需求,无论你是truncate,还是一些drop table的操作都是可以轻而易举的恢复。所以更多的时候我们其实更偏爱于Data Guard基础上的这种数据恢复方式,而原本的逻辑备份exp,expdp,物理备份RMAN就显得有些臃肿了。 拿一个真实的小案例来说明,有一次因为数据查询的SQ
有一次在某微信群里,有人提问以下两条操作还能恢复吗?而且是在没有开归档。紧接着又有人提问数据库是否开了闪回?
由于 PDB 的引入,Oracle 数据库的备份和恢复也发生了很多变化,基于 PDB 级别的表空间、库备份同时被支持。以下通过实际测试介绍一下12c中关于 PDB 的备份恢复过程。 ⑴ 启动归档模式
1。select * from znjtresource.t_device_epolice as of timestamp to_timestamp(‘2019-3-21 15:20:00′,’yyyy-mm-dd hh24:mi:ss’) 2,。insert into znjtresource.t_device_epolice (select * from znjtresource.t_device_epolice as of timestamp to_timestamp(‘2019-3-21 15:20:00′,’yyyy-mm-dd hh24:mi:ss’));
如果一不小心对Oracle数据库中的数据进行了误删除操作,那么如何进行数据恢复呢(不考虑全库备份和利用归档日志)?如果使用的是9i以及之后的版本,那么我们可以采用闪回技术对误删除的数据进行恢复。方式有两种。
以下以oracle数据库为例,介绍关于表中数据删除的解决办法。(不考虑全库备份和利用归档日志)
在前面几篇文章中,我们介绍了 MySQL 的高可用架构。当然,传统的高可用架构是不能预防误删数据的,因为主库的一个 drop table 命令,会通过 binlog 传给所有从库和级联从库,进而导致整个集群的实例都会执行这个命令。
使用PL-SQL操作oracle时,执行完更新语句update tab set name='a' where id='1';
前几天有个同事碰到了一个MySQL数据恢复的问题,他运行了一条update语句,结果忘记了加where条件,结果等反应过来已经晚了。我简单确认了下,是否存在备份,没有,是否开启了日志,没有。所以这个恢复无从谈起。 当然后来他也花了些功夫逐条数据修复,事情过去了,数据恢复的重要性,人为操作的重要性就不言而喻了,但是有些时间工作职责还是需要下移。我觉得还是需要好好总结下数据恢复的问题。我会从以下几个方面来谈。 目录 ⊙ 手工恢复数据的简单示例 ⊙使用开源工具恢复数据的配置 ⊙ 使用开源工具
binlog是记录所有数据库表结构变更(例如CREATE、ALTER TABLE…)以及表数据修改(INSERT、UPDATE、DELETE…)的二进制日志。
如果是使用 delete 语句误删了数据行,可以用 Flashback 工具通过闪回把数据恢复回来。 Flashback 恢复数据的原理,是修改 binlog 的内容,拿回原库重放。而能够使用这个方案的前提是,需要确保 binlog_format=row 和 binlog_row_image=FULL。
技术交流群总是能带来很多实际生产环境遇到的问题,例如,近期就有人遇到user表内容被清空的情况。如果发生了此情况,千万不要慌,更不能隐瞒问题(这位朋友就比较惨,别人删了也没敢告知,结果binlog已经清理了),以免不利于恢复。现在针对几种情况,进行恢复操作的演示。
数据库备份与恢复是数据库管理员必须掌握的。没有任何系统能免遭硬盘物理损坏、粗心用户的错误操作、或一些可能会威胁到存储数据的潜在灾难的侵袭。为了能够最大限度地恢复数据库数据,保证数据库的安全运行,应该选择最合理的备份方法来防止各种故障所导致的用户数据丢失。
在Oracle 18C数据库中,创建PDB时可以同时为PDB创建快照,完整的保存快照创建时间点的PDB数据。PDB快照主要有两个作用:
我觉得你可以把你一整天的工作情况都罗列下来,毫无疑问,你需要是个有心人,你得关心自己的工作情况,把耗时和时间的分配情况都记录下来,便于追溯。
DBA或开发人员,有时会误删或者误更新数据,如果是线上环境并且影响较大,就需要能快速回滚。传统恢复方法是利用备份重搭实例,再应用去除错误sql后的binlog来恢复数据。此法费时费力,甚至需要停机维护,并不适合快速回滚。也有团队利用LVM快照来缩短恢复时间,但快照的缺点是会影响mysql的性能。
对于Oracle的闪回,很多朋友也问过问,到底是怎么玩的?如果自己做过一些闪回数据库的操作,就会发现这个功能非常强悍。 Flashback DML的操作其实还蛮容易理解的,但是Flashback DDDL那可就是另外一个level了,我们大概了解一下MySQL里面的闪回就会发现,真要实现无缝的全闪回,确实有很多的细节和场景需要考虑。而Oracle作为一个成熟的商业软件,是不希望我们了解很多底层的细节的,用着好就行,所以如果你想得到一些闪回更细节的东西,这个渠道就非常的窄,我们之前也测试了两期,做了
在Oracle中,三大文件即控制文件,数据文件,日志文件的丢失与破坏都将需要使用还原或恢复来使数据库正常化。而RMAN还原与恢复
由于运维、DBA的误操作或是业务bug,我们在操作中时不时会出现误删除数据情况。早期要想恢复数据,只能让业务人员根据线上操作日志,构造误删除的数据,或者DBA使用binlog和备份的方式恢复数据,不管那种,都非常费时费力,而且容易出错。直到彭立勋首次在MySQL社区为mysqlbinlog扩展了闪回功能。 在美团点评,我们也遇到过研发人员误删主站的配置信息,从而导致主站长达2个小时不可用的情况。DBA同学当时使用了技术团队自研的binlog2sql完成了数据恢复,并多次挽救了线上误删数据导致的严重故障。不过
第一步:备份网站数据 进入后台—站长—数据库—备份,数据备份类型选择“Discuz!和 UCenter数据”,备份成功以后,数据自动保存在data文件夹下。
大家好,又见面了,我是你们的朋友全栈君。 很多站长第一次做网站的时候,无奈选择了速度不是很稳定的空间,慢慢会发现有很多物美价廉速度相当快的空间 这个时候,站长在网站搬家的过程中就会遇到很多困难,今天老袋鼠给大家详细讲解一下discuz 论坛 搬家的详细过程 第一步:备份网站数据 进入后台—站长—数据库—备份,数据备份类型选择“Discuz!和 UCenter数据”,备份成功以后,数据自动保存在data文件夹下。 第二步:网站文件下载 把整个网站文件打包(虚拟主机管理控制面板一般都有整站压缩和解压的功能,在控制面板选择压缩,压缩之后的文件一般在FTP DB文件夹里面,然后把压缩包下载到本地电脑,如果虚拟主机没有在线压缩功能那就直接使用FTP下载文件到本地保存。 第三步:整理下载到本地的网站文件 1.把下载下来的文件里面的下列文件删除,请完全放心删除掉这几个文件,重新装上的时候会自动产生新的文件。 /install/install.lock (有的下载下来之后就没有这个文件,如果没有就不用管) /config/config_global.php /config/config_ucenter.php /uc_server/data/config.inc.php 2.到官方下载一个Discuz! X3.2的安装包,把 upload里的/install/文件夹复制过来覆盖你下载下来的网站文件。 3.把从官方下载下来的Discuz! X3.2安装包里面的 utility/restore.php 文件放到你网站文件的/data/文件夹内,这是用于数据库还原。 第四步:将整理好的网站文件包上传到新主机空间(放网页资料的文件夹下) 建议压缩之后在使用FTP上传,上传完成之后进入虚拟主机控制面板在线解压,这样可以节约很多时间,目前几乎所有的虚拟主机都有在线解压功能,格式一般是rar格式,不过有的部分虚拟主机如linux主机就只支持.zip格式,所以打包前请注意。 第五步:域名解析及空间绑定域名 进入域名控制面板把域名解析到你新的虚拟主机IP上,然后在进入虚拟主机空间绑定域名。 第六步:重新安装discuz http://你的域名/instal/进行安装,填入你新的虚拟主机数据库名和用户名及数据库密码,注意数据库的数据表前缀和以前一样,一般你之前的数据表如果没有改动的话,你重新安装的时候默认的就是和你以前的一样,所以可以不用改。当你安装的时候可能会提示要你删除data/install.lock这个文件才可以继续安装,那么你可以进入FTP删除之后然后返回安装页面刷新一下再继续安装,这就可以安装了。 第七步:还原数据库 安装成功后,用你安装的时候填写的管理员帐号和密码登录,进入后台—站长—数据库—恢复—数据恢复,选中要恢复的数据然后点击右边导入,点击确定即可恢复数据,为了安全起见当成功恢复数据后进入FTP删除/data/restore.php这个文件。 有时候进入之后数据恢复,发现没有可供还原的数据,那么你可以看到下面这一行文字,那你直接点击你的网址在浏览器当中恢复数据即可,为了安全起见当成功恢复数据后进入FTP删除/data/restore.php这个文件。 您可以在本页面数据备份记录处导入备份恢复数据,也可以通过在浏览器中执行 http://www.你的域名.com/data/restore.php 恢复数据 第八步:检查UCenter能否登陆 提示:1、检查UCenter 访问地址设置是否正确(没有更换域名做第六步安装,一般不会出错) 2、创始人密码和admin管理员密码不是同一个,创始人密码是上面第六步重新安装discuz程序时设置的密码。 第九步:检查UCenter应用是否通讯成功 后台——UCenter——应用管理,查看通讯情况,若通讯失败,请检查通信密钥设置是否相同。 后台——站长——UCenter设置,检查UCenter 通信密钥是否和UCenter应用设置相同 第十步:更新缓存 数据还原成功之后,在后台退出帐号,用你原来的后台管理员帐号登陆,进入后台更新缓存,网站搬家成功结束。
对任何数据库系统而言,对显而易见的故障,应当避免发生本文列出了Oracle常见的故障并给出了解决方案,同时列出了一些日常规划。
这个周末过得相当充实,当我们做一些有意思的事情的时候,就会觉得周末的时间特别长。周天晚上还发烧了,幸亏楼下的药店还开着门,下去买了点儿药,吃完睡了一觉,才感觉缓了过来,满血复活,继续上班。。。
本文分享下对于 my2sql 的一些改进,并且接入到 DBeaver 中供开发便捷使用的一个实际案例。
MySQL binlog集市的事情我们做了有一段时间了,最开始的初衷是异常操作的数据恢复,主要的痛点是如果发生了业务误操作,需要紧急恢复数据的时候,通常这些误操作是对于字典配置数据的变更,而要恢复的时候成本则太高了,举个极端的例子,1T数据量的数据库,要恢复的字典数据最有1M,但是很可能需要恢复1T的数据量作为代价,有点得不偿失,所以,我们对于binlog集市是希望尽可能完整的捕获数据库的数据变化,并且能够闪回恢复。
redo log 和 binlog 是 MySQL 数据库中的两种日志文件,它们都可以用于恢复数据库。但是它们记录的内容、位置、时机、方式和作用都有所不同。
mongodump mongodump是一个MongoDB的备份工具,可以备份整个数据库或者某个集合中的数据,备份出的数据可以用于恢复操作或者数据迁移等。mongodump支持以下参数:
数据库及时备份可以帮助我们在数据库出现异常宕机时及时的使用备份数据进行恢复工作,将因为数据库宕机产生的影响降低到最小。上一篇针对使用xtrabackup工具进行物理备份和数据恢复做了一个详细讲解,本篇主要谈谈如何使用mysql自带的备份工具mysqldump进行逻辑备份和数据恢复。如果还围观看过上一篇文章的可以先行查询上一篇文章关于使用xtrabackup进行数据备份与恢复:Mysql备份与恢复(1)---物理备份。
mongorestore是MongoDB自带的数据恢复工具,用于将mongodump命令备份的数据进行恢复。下面是mongorestore命令的参数说明:
我们都知道,Redis 的数据存储在内存中, 一旦服务器宕机,内存中的数据将全部丢失。因此,对 Redis 来说,实现数据的持久化,避免从后端数据库中进行恢复,是至关重要的。本篇我们详细讲解下 Redis 的三种持久化机制,分别是 AOF(Append Only File) 日志和 RDB 快照 以及 混合持久化。
日常工作中,总会有因手抖、写错条件、写错表名、错连生产库造成的误删库表和数据的事情发生,那么,如果连数据都恢复不了,还要什么 DBA。
前边的在《一条SQL查询在MySQL中是怎么执行的》中我们已经介绍了执行过程中涉及的处理模块,包括连接器、分析器、优化器、执行器、存储引擎等。今天我们来一起看看一条更新语句又是怎么一个执行流程。
点击关注公众号,Java干货及时送达 作者:程淇铭 来源:segmentfault.com/a/1190000020116271 日常工作中,总会有因手抖、写错条件、写错表名、错连生产库造成的误删库表和数据的事情发生,那么,如果连数据都恢复不了,还要什么 DBA。 相关文章 MySQL备份策略:https://segmentfault.com/a/1190000019955399 MySQL数据恢复:https://segmentfault.com/a/1190000020116271 1 前言 数据恢
日常工作中,总会有因手抖、写错条件、写错表名、错连生产库造成的误删库表和数据的事情发生。但是,如果每次删库都跑路的话,怕是再也不好找工作了吧!所以,删库跑路不是上上策。
数据库对企业来说最重要的莫过于其中的数据,所以做好数据库的备份是一个不可或缺的工作。数据库及时备份可以帮助我们在数据库出现异常宕机时及时的使用备份数据进行恢复工作,将因为数据库宕机产生的影响降低到最小。所以,本篇文章主要数据库数据备份与恢复进行介绍。由于MyISAM存储引擎中备份数据是将表保存到单独的文件所以比较简单,所以这里我主要针对InnoDB存储引擎介绍备份与恢复机制。
领取专属 10元无门槛券
手把手带您无忧上云