在 IT 圈内，“删库跑路”已经成为程序员经常提及的一句玩笑话。虽然是玩笑话，但却反映了数据库内数据对企业的重要性。2020年的“微盟事件”就直接让香港主板上市公司微盟集团的市值一天之内蒸发超10亿元，数百万用户受到直接影响。
SQL数据库修复的三大核心技术： 1、磁盘阵列分析重组技术； 2、数据库恢复与修复技术； 3、SCSI盘物理故障开盘技术。
IBM 3650服务器中共有5块 SAS 300GB 磁盘组成一组RAID5磁盘阵列，存储划分为一个LUN、3个分区，第一个分区存放的是windows 2003系统，第二个分区用于存储 SQL Server 2010生产库，第三个分区是备份分区。
2020 年 2 月 25 日，微信的朋友圈大量转载微盟遭遇了系统重大故障（36 小时内尚未恢复核心生产数据）。从而想到本人在两周前处理的一个案例：开发人员误删除了生产数据，本人恢复的一个过程。同时给这个故障的处理过程做一个总结，也对学过的知识做一个梳理，希望对运维的同学们有一个警示作用。
前两天因为没注意的误操作, 直接把某个数据表清掉了, 心慌慌. 怪自己学艺不精, 当时整了一下午也没把数据找回来. 当晚回来闭关研究, 终于在凌晨1点多整出来了, 特此记录, 以备不时之需.
今天发一篇与以往不同的内容，这是一篇来自生产实践的记录。我只是做了一下编辑和修订的工作。
删库跑路的案例不在少数，今年最出名的删库跑路当属微盟，造成公司市值蒸发几十亿，赔偿商家1.5亿元，最终在腾讯云的协助下经过7*24小时的不懈努力，最终找回全部数据。我们都知道，数据就是一个公司的“命根子”，无论什么时候，数据安全都是最重要的。所以我们今天来聊聊数据恢复的几种方式。以mysql为例。
作为《手撕MySQL》系列的第二篇文章，今天介绍一下MySQL的二进制日志（bin log），注意不要和MySQL的InnoDB存储引擎特有的重写日志（redo log）混淆，bin log是记录所有数据库表数据及表结构变更的二进制日志（不会记录查询操作），借助这个日志可以实现：数据恢复和 主从复制（不难理解，因为所有涉及变更的操作都记录了下来，可以追溯）。
故障服务器上一共16块FC硬盘，单盘容量600G。存储前面板10号和13号硬盘亮黄灯，存储映射到redhat上的卷挂载不上，服务器业务崩溃。
MySQL 的二进制日志（Binary Log），通常简称为 binlog，是一种记录数据库中发生的更改的日志文件。它记录了对数据库进行的 INSERT、UPDATE 和 DELETE 等数据更改操作，以及数据库结构的更改（例如，ALTER TABLE）。这些日志文件对于数据恢复、数据复制和数据库的高可用性非常重要。以下是关于 MySQL binlog 的详细介绍：
本次恢复的数据库安装在客户本地服务器上，服务器操作系统为windows2008 r2 。在当前环境内安装有mysql5.6单实例，引擎类型为innodb，表内数据存储所使用表空间类型为独立表空间。未进行数据库备份，未开启binlog。
对于DBA来说，面对误操作带来的数据恢复难度，其实很大。主要有以下几个方面： 误操作的影响范围极大，很可能不是删点，改点数据的操作，有时候可能是让人望而兴叹的truncate,drop操作。 数据恢复时需要确认数据损坏的时间点，依此来作为数据恢复的一个基准，该舍弃多少数据，该如何权衡，非常关键。 一旦信息提供错误，是否经得起反复折腾，我想这个对于绝大多数的数据恢复而言，基本都是一锤子买卖，能恢复已经不错了，还要反复恢复。但是一旦出现这种情况，可不能马上乱了阵脚。 灾备方案好不好，一试便知 自己也
数据库及时备份可以帮助我们在数据库出现异常宕机时及时的使用备份数据进行恢复工作，将因为数据库宕机产生的影响降低到最小。上一篇针对使用xtrabackup工具进行物理备份和数据恢复做了一个详细讲解，本篇主要谈谈如何使用mysql自带的备份工具mysqldump进行逻辑备份和数据恢复。如果还围观看过上一篇文章的可以先行查询上一篇文章关于使用xtrabackup进行数据备份与恢复：Mysql备份与恢复(1)---物理备份。
MySQL日志是在MySQL server上生成的，不管更改哪个存储引擎，这些日志都是需要有的，包括：
今天琢磨一个问题，在平时的工作中如果碰到一些不规范的操作，drop,truncate,delete，恢复起来还是很困难的，drop操作在oracle中如果开启了recycle bin还是基本安全的，delete操作可以借助flashback delete操作，可能有些更细微的操作update，insert等等操作导致了问题，需要做数据修复的时候，这个时候可以使用flashback query来辅助，如果来一个truncate，那就没辙了，其实在truncate操作完成后，一般来说数据还都是在数据文件里的，这
Oracle数据恢复顾问用于当数据发生错误或故障时，进行自动收集数据故障信息，并生成恢复脚本，用于完成数据恢复。数据恢复顾问也可以主动检查故障。 在这种模式下，它可以在数据库进程发现数据损坏并发出错误之前进行潜在的检测并分析数据故障。数据故障可能非常严重。 例如，如果您当前的日志文件丢失，则无法启动你的数据库。 一些数据故障（如数据文件中的块损坏）不是灾难性的他们不会将数据库关闭或阻止您启动Oracle实例。 数据恢复顾问处理这两种情况：当您无法启动数据库时（因为某些情况）所需的数据库文件丢失，不一致或损坏）以及文件损坏时的数据库文件在运行时发现。
Oracle闪回技术从根本上改变了数据恢复策略，利用闪回技术，可以使更正错误的时间大大缩短，而且它简单易用，使用一条短命令便可恢复整个数据库，而不必执行复杂的程序。闪回技术是Oracle数据库独有的特性，支持各级恢复，包括行、事务、表、表空间和数据库范围。采用闪回技术，可以针对行级和事务级发生过变化的数据进行恢复，减少了数据恢复的时间，而且操作简单，通过SQL语句就可以实现数据的恢复，大大提高了数据库恢复的效率。
3 天前，运行的社区系统报告，很多老的历史照片都无法作为附件加载 —— 小鲨鱼，快来解决问题。
SQL Server是一个可扩展的、高性能的、为分布式客户机/服务器计算所设计的数据库管理系统，实现了与WindowsNT的有机结合，提供了基于事务的企业级信息管理系统方案。本次需要进行数据恢复的服务器是一台r520型号存储，共有7块SAS硬盘分别组成RAID1和RAID5两组磁盘阵列。
客户是地产行业客户，云服务器主要部署OA和sql server数据库，由于内部IT薄弱，没有做好安全防护，导致服务器被病毒入侵。
上篇文章（转战MySQL Shell！数据库备份新姿势，轻松搞定备份操作！）简单介绍了使用MySQL Shell进行数据库备份，本文基于上文的备份进行数据恢复演示操作。
作为《手撕MySQL》系列的第三篇文章，今天讲解使用 bin log实现主从复制的功能。主从复制也是MySQL集群实现高可用、数据库读写分离的基石。因为是系列文章，上一篇文章中（传送门）我们已经介绍了在MySQL中查看 bin log的相关状态以及文件信息，并且借助 bin log（二进制日志）实现数据恢复的案例。因此在这篇文章中如有涉及相关知识，将不再赘述。
备份恢复之前和同事投入了一些精力来完善，算是走上了平台化对接的一个开始，在满足功能的前提下，能够基本实现数据全备，增备和DML闪回，但是在性能和可控性方面还是存在不少的改进之处，最近梳理了下已有的备份恢复策略，准备在这个方面能有一定的成绩。
对于数据恢复来说，现在其实缺少一些有效的使用场景来更好的体现业务价值，于是我们就重新考虑了下现有的备份支持能力。
有时我们会遇到操作人员误删或者误更新数据的情况，这时我们迫切希望把原来的数据还原回来，今天我们介绍一个简单的工具来方便的实现此功能。
某公司使用的存储，采用RAID5磁盘阵列，由于未知的原因导致存储忽然崩溃无法启动，RAID5阵列中的虚拟机全部丢失，其中3台虚拟机为重要数据，需要主要针对该3台虚拟机进行数据恢复。
操作系统：CentOS 7.7 MySQL版本：5.7.30，搭建主从 开启binlog，binlog_format=row 备份情况：每天00:00对数据库进行全量备份 恢复原因：某日22:00左右，执行了批量update语句，需要回滚
Flashback恢复数据的原理是通过修改binlog内容，拿回原库进行回放，前提是binlog_format=row和binlog_row_image=FULL。
本次故障环境为4台服务器，每台服务器12块盘分为2组raid,共8组raid。经客户描述共4个节点，其中一个节点故障之后仍在继续使用，第二个节故障之后，进行过一系列的重新上线操作，导致管理存储软件无法使用。 为防止在数据恢复过程中由于部分操作对原始磁盘造成不可还原的修改,导致数据出现二次丢失，对原始磁盘进行镜像备份。北亚工程师进行详细分析，获取到5台节点服务器上的所有硬盘的底层镜像。经过分析，发现底层部分索引位图被破坏。对全部镜像文件进行分析，根据底层数据重组raid，并提取每组raid中的map，对数据map进行分析，根据位图手工索引数据，排除部分损坏位图。客户主要数据为SQL server数据库，经初步检测，索引位图有部分损坏，因此若提取数据卷后数据有损坏，可针对数据库进行修复。 【数据恢复过程】 1.重组RAID 工程师对RAID条带大小、盘序、校验方向的关键信息分析后，判断成员盘离线顺序。分别对十组RAID进行重组，并生成RAID镜像文件。
闪回数据库这个特性在很多Oracle DBA眼里就是鸡肋特性，因为谁会因为恢复数据而需要在主库闪回，最后可能丢掉更多的数据，这个观点没错。 但是如果是备库呢，这个特性就顺利成章的满足了绝大多数的恢复需求，无论你是truncate，还是一些drop table的操作都是可以轻而易举的恢复。所以更多的时候我们其实更偏爱于Data Guard基础上的这种数据恢复方式，而原本的逻辑备份exp,expdp，物理备份RMAN就显得有些臃肿了。 拿一个真实的小案例来说明，有一次因为数据查询的SQ
数据库恢复的先决条件是,定时备份数据库,缩小binlog恢复范围.首先我们备份测试数据库数据:
最近碰到的数据问题还是不少，这个过程中也发现了一些隐患，每次恢复的策略和方法都不大一样，但是最终还是修复了数据。
我们常常听人说，只要你愿意，MySQL 可以恢复至半个月甚至一个月以内的任何一个状态。网上也有很多删库跑路的段子。。。
MySQL的二进制日志（binary log），通常被称为binlog，是MySQL数据库中的一种日志文件，它记录了所有的DDL（Data Definition Language）和DML（Data Manipulation Language）语句事件，这些语句会导致MySQL数据的改变。binlog是MySQL复制的基础，也是进行数据恢复的重要手段。
mysql数据库一主多从的架构，主写从读进行读写分离，专用从库做数据备份，每天0点全备一次，12点增量备份一次，初始阶段数据量很小的情况按此方案，后续数据量大，读写频繁时，再进行相关调整，增加增量备份频次
数据恢复是对数据库进行备份和还原，当数据库因为各种原因被损坏或者无法读取的时候，会造成无法估量的后果，这个时候就需要数据库还原工具，进行还原。
今天和Oracle的一个资深前辈聊了下，聊了不少技术的问题，他也来了兴致，随机提了几个问题来问我，发现看似简单的问题还是有不少的干货，很多东西似懂非懂其实还是没有深入理解，限于篇幅，整理了一部分的问题
当年比尔盖茨说640KB内存管够，结果今天竟然有几TB内存的服务器被用于内存数据库来承载互联网用户高速访问。
上周五面试了字节的第三面，深感数据库知识的重要，我也意识到在平时的学习中，自己对于数据库的学习较为薄弱。甚至在有过一定实习经验之后，依旧因为开发分工的原因，对数据库方面的知识掌握依旧不多。我也相信，很多人对MySQL的 索引、 日志、 多版本并发控制、 ACID等等都只停留在八股文的阶段。
对于任何一个企业来说，数据安全的重要性是不言而喻的。我在开篇词中也曾经强调过，凡是涉及到数据的问题，都是损失惨重的大问题。
在国内不论是使用阿里云、腾讯云还是华为云的云平台版本的 MySQL 数据库，在遇到数据备份恢复的场景，都会遇到需要使用 Percona XtraBackup 工具进行备份还原的需求。
在日常运维工作中，对于数据库的备份是至关重要的！数据库对于网站的重要性使得我们对 MySQL 数据库的管理不容有失！然而是人总难免会犯错误，说不定哪天大脑短路了，误操作把数据库给删除了，怎么办？
通过上面的描述，我们知道一条查询SQL执行的主要过程，客户端执行一条SQL前需要先经过连接数据库、解析器、优化器、执行器等阶段，再由执行器返回查询结果，具体过程可以参考下面的简图。
在日常运维工作中，对于mysql数据库的备份是至关重要的！数据库对于网站的重要性使得我们对mysql数据的管理不容有失！ 然后，是人总难免会犯错误，说不定哪天大脑短路了来个误操作把数据库给删除了，怎么办？？？ 下面，就mysql数据库误删除后的恢复方案进行说明。 一、工作场景 （1）MySQL数据库每晚12:00自动完全备份。 （2）某天早上上班，9点的时候，一同事犯晕drop了一个数据库！ （3）需要紧急恢复！可利用备份的数据文件以及增量的binlog文件进行数据恢复。 二、数据恢复思路 （1）利用全备的
RAID5磁盘阵列，由于未知的原因导致存储忽然崩溃无法启动，RAID5阵列中的虚拟机全部丢失，其中3台虚拟机为重要数据，需要主要针对该3台虚拟机进行数据恢复。
Mysql中的事务的原子性和持久性是由Redo Log实现的。 Redo Log也被称为重做日志。Redo通常用来记录物理日志。Redo Log包含两部分：
1.创建douyin数据库、tbl_douyin_author数据库表、插入测试数据。
最近行情越来越卷了，给大家整理了互联网大厂15道经典MySQL日志面试题，希望大家都能找到理想的offer
问题描述一 断点恢复ERROR 1146 (42S02) at line 35: Table ‘shang.info’ doesn’t exist [root@localhost opt]# mysqlbinlog --no-defaults --stop-datetime='2020-08-23 13:29:04' /usr/local/mysql/data/mysql-bin.000002 | mysql -uroot -p Enter password: ERROR 1146 (42S02) at
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
