开发者学堂课程【企业运维训练营之数据库原理与实践课程 ：云数据库备份与恢复（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1201/detail/18306
云数据库备份与恢复
三、数据库备份恢复原理
了解以上概念后，接下来进行原理部分，这里主要讲解逻辑备份、物理备份和快件备份。
1.讲解原理之前，可以先想一下一个问题：
在进行逻辑备份时肯定是涉及很多库表的，比如说在备份 A 表的时候花费了十秒钟，在开始备份 B 表时候就已经是十秒钟以后的数据了，这就导致了数据的不一致，备份的目的是获得一个可用的数据库，所以要保证一致性。
2.接下来讲解上面问题的解决方法。
除了逻辑备份和物理备份有这个问题，备份的文件有很多，如何保证每个文件的一致性？
MySQL 是通过整个事务和日志来保证数据一致性的。
下面重点解决上述问题：
MySQL 的主流引擎是 InnoDB ，也就是一个事务性引擎，事务的四个特性也就是通常所说的 ACID ：原子性、一致性、隔离性和持久性。它能完整的描述出一个事务，通常来说，就是事务有两个状态，成功或者失败，而失败后可以进行回滚。事务和事务之间是隔离的根据不同的隔离级别来判断出数据的不同。事务提交后，数据要保证能存储在磁盘上，不管是发生当机还是其他事件，数据都一直存储在磁盘中。。一致性指通过其他三种特性来共同保证数据的状态或者规则在事务前后的一致性。
3. MySQL 事务的四个特性是如何实现的？
主要是有三个日志文件：Undo log 、Redo log 和 Binlog 。
WAL全称为Write-Ahead Logging，预写日志系统。其主要是指 MySQL 在执行写操作的时候并不是立刻更新到磁盘上，而是先记录在日志中，之后在合适的时间更新到磁盘中。日志主要分为 undo log、redo log、binlog。
（1）Redo log 用来记录某数据块修改后的值，可以用来恢复未写入 data file 的已成功事务更新的数据。主要用来记录某数据块被更新后的值，或者说 MySQL 执行了什么命令导致数据库发生了什么变化，
可以用来恢复未写入 data file 的已成功事务更新的数据。
①数据的持久性
（2）Undo log是用来记录数据被更新前的镜像值，保证数据更新失败能够回滚。
①事务的原子性
②多版本并发控制(MVCC)
（3）Binlog 记录了数据库提交了的所有的 DDL 和 DML 语句。
①Mysgl主从复制
②数据恢复
（4）为什么需要 Redo DB ？
①假设做了一个 Commit 也就是数据落盘，为什么还需要 Redo log ？严格来讲，如果不需要考虑其他东西，Redo log 对于事务或者 MySQL 来说其实不是必要的，有这个东西主要是因为几个点：MySQL 有很多内存结构也就是有很多 buffee ，包括操作系统也有很多 catch ，数据其实是先写入 catch 或者是 buffer ，比如说有很多不是先写到落盘的可能会经过操作性能的 catch ，然后数据库或者系统会异步的将数据刷到磁盘中，这种模式有利于激发数据库的并发能力。但是也有一些问题，比如说当数据库挂了之后，因为 buffer 这种是在内存中的，此时数据会丢失，所以需要一种机制去找回数据，此时 Redo 发挥作用，Redo 其实就是做了什么操作，数据的后进项就会在 Redo 中记录，它是一定会落盘的。如果做数据档之后，就会有一个 recover 的过程，它可以找回丢失的数据和没有落盘的数据。
这里又有一个问题：Redo 是已经落盘的，数据也是已经落盘的，这②两者有什么更加优异的方面？
原来使用的存储都是机械盘，随机 IO 和顺序 IO 的速度差异是非常大的，比如说写数据，因为数据是非常零散的分布在存储中的，所以这也就是随机 IO ，Redo log 中的 log 是往后面写的意思，也就是说它可以把随机 IO 改变成顺序 IO ，此时速度大大提升。
③现在使用的大部分是 SID 盘，它的随机 IO 速度也非常快，但是数据 IO 的话，因为数据非常零散分布的，比如说要更新几个非常零散分布的列值，是不可能一次性 IO 能解决的，写这个数据需要发生多次 IO ，多次 IO 对比顺序 IO ，IO 次数是更少的，也就是说不需要考虑存储量，包括在以后的自运维中需要判断 OPS 也就是 IO 次数，每秒的 IO 次数，这也是一个性能瓶颈。所以说 Redo 的诞生主要是还是为了一个持久性，以及为了提升速度。
（5）为什么需要 Undo log ？
Undo log 主要是记录数据更新之前的值，保证数据能够进行回滚，比如运用于事务的多版本并发控制还有原子性，因为在回滚的时候赶 data 数据，赶数据时候可以在 Undo log 里面找。
（6）为什么需要 Bin log ？
Bin log 其实是在 server 层的，Undo log 和 Redo log 是在存储引擎层的，server 会记录所有提交的 DMI 和 DBL ，主要运用于做主动复制、数据恢复或同步。
（7）为了保证 Bin log 的数据一致性，MySQL 使用的是两阶段提交。
以下是事务提交的整体流程：
假设张三和李四各有500元，张三向李四借100元，这里简化成 A 和 B 两个数据值都是500，A-100和 B+100的事务行为过程为：
首先事务开始，记录 A =100这个数据，A 的前进项也就是 A 数据更新前到 Undo log ，然后记录修改 A =400也就是 A 的落盘项，然后记录 A =400到 redo log ，因为事务写的流程是先写 undo 再写 redo 。B 的数据变化也是先写 Undo 再写 Redo ，这里需要注意 LSN ，它是日志序列号，因为在数据库里面记录数据库一致性的位置就是通过这个实现的，LSN 一般主要存在于 data 数据的 Redo 、数据的 data buffer 以及一个 Redo buffer 。
（8）如何寻找到值？
在数据库里面，输入 show engine innodb status
得到下列代码：
LOG
---
Log sequence numbel 19737215
Log buffer assigned up to 19737215
Log buffer completed up to 19737215
Log written up to 19737215
Log flushed up to 19737215
Added dirty pages up to 19737215
Pages flushed up to 19737215
Last checkpoint at 19737215
Log minimum file id is 5
Log maximum file id is 6
220 log i/o's done. 0.00 log i/o's/second
-------------------
这里有一个 Log sequence numble ，可以看到，在 data buffer 中的号是19737215，里面还有 flush ，请看 checkpoint at ，可以看到这里的checkpoint 的值是19737215，其中，19737215就是在 Log written up to 上数据的一个 data 的 page 值。
注意：事务提交之后其实就已经落盘了，但是如果在已经提交的过程中 crash 了也就是主机挂机了，在它起来的时候，数据库会做一个 recover 的过程。Recover 过程比较简单，主要就是先前滚后回滚，也就是先确认一个 UCR 支持然后进行对比，前滚其实就是事务前进对象，因为要恢复到数据库 crash 之前的那个值也就是前一刻的状态，也就是说可以根据对比 LSN 号在 Redo 中去应用到最新的数据，这时候就可以达到 crash 前一刻的状态，只需要对一些 prepare 状态的事务做一些回滚，这里需要查 Bin log 的值，也就是两阶段提交的一个具体逻辑。然后就是回滚，回滚完成之后数据库就已经正常，recover 过程已经结束，recover 过程其实和物理备份恢复类似
（9）以下是 MySQL 的内存和磁盘的一个结构：
里面包括 changer buffer 等，还有很多细节，可以自行了解。
4.数据库备份方法
接下来重点讲解逻辑备份、物理备份和快照备份的具体原理
（1）三种备份的对比
逻辑备份其实是数据库里面的对象级别的备份，主流工具有 mysqldump 和 Mysqldumper 。mysqldumper 其实就是多线程版的 mysqldump ，有很多改进。物理备份实际上是文件系统层面的备份，比如说简单的 cp 去同步物理文件就算是一种物理备份，非常主流的就是 XtraBackup ，还有 CDM 也是阿里云常用的物理备份。快照备份就是基于存储或者文件系统，比如说 napshot ，不同的厂商会有不同的类似的工具，这个是依赖于存储的。
（2）逻辑备份
以 MySQLdump 为例，这里主要列举它的十个参数，下面将通过演示来讲解它的具体逻辑和流程。
以下是在开通了 general Log 的数据库，这样可以观测到在做备份时候的后台，也就是数据库自身做的动作。
在数据库中输入 show global variables like ’%gene%’ ;
如图，可以看到：
在文件中输入 tail ·f，运行之后可以看到数据库没有做任何状态，这里有两个库，如图：
这两个库分别是 test 2021和2022。输入 use test 2021，可以看到：
里面有两个表。
①先不加参数，把参数 all-datdbases 简化成上面两个库
请看以下代码：
mysql> exit
Bye
[root@iZbp139mvjnm0lp2pi0nfkZ data]#
[root@iZbp139mvjnm01p2pi0nfkZ data]#
[root@iZbp139mvjnm01p2pi0nfkZ data]#
[root@iZbp139mvjnm01p2p10nfkZ data]# cd ..
[root@iZbp139mvjnm01p2pi0nfkZ mysql# cd
root@iZbp139mvjnm01p2pi0nfkZ-]# mysqldump uroot-pRoot@123 --databases test2022 test2021 > all.sql
mysqldump:[Warning] Using a password on the command line interface can be insecure.
[rooteiZbp139mvjnm01p2pi0nfkZ ~]#
[root@iZbp139mvjnm01p2pi0nfkZ -]#
这就是完成了一次备份。
先看备份文件，输入 vi all sql ，现在的逻辑备份就是一个结构，如图：
将数据转换成 sql 的形式，上面只需要执行 sql 和 DDR 即可。现在来看备份过程具体做的动作，这里不需要看前面的状态，主要看初始化 Innodb 开始备份的2022的这个库，如图：
备份时候有 Lock 的 t1，t1是一张表，READ 把这两个表都上锁了，不允许写，然后再去做一些备份。包括另外一个库，做完这些备份后，它是 UNLOCK TABLES 解锁，也就是备份之后解锁，然后再进行备份第二个库也就是2022这个库，流程也是一样的，先对所有的表进行上锁，最后再解锁。所以说不加任何参数进行的流程，就是它把单库下面所有的表加锁，备份之后进行解锁，然后备份下一个库。
这样的方式有一个问题：首先加锁也就是温备之后是不能进行写入的，首先对 A 库进行加锁之后再在 B 库完成加锁，也就是在备份 A 库完成之后才能开始备份 B 库 ，比如说备份 A 库花费了十分钟，那么后面备份的 B 库的数据就是十分钟之后的数据了，这样会导致数据不一致的问题。也就是说这种形式只能保证单库下的数据一致而不能保证多库数据的一致。
②后面还有 single-transaction 这个参数，为了实现数据一致性和锁的问题，刚刚提到了事务，也就是其实完全是可以通过事务完成这些事情。
下面看它的具体过程：首先等备份完成，此时文件肯定是一样的，现在来观察它的具体动作，如图：
首先把 SESSION 设置了一个 RR 的隔离级别，RR 的隔离级别可以解决，一个事务开始之后，是读不到别的数据的，哪怕已经提交了也读不到。所以说第一步设置一个 RR 的可重复的隔离级别很重要，然后第二步的 START TRANSACTION 开了一个事务，然后是一致性快照，也就是说它通过的的是事务的方式去做这个隔离，读取或者获取这个数据。逻辑备份最基本的就是把数据提取过来，关键是如何保证数据的一致性，所以它可以开一个一致性快照读的事务，后面每次 START 的时候都是按照在这个事务里面以保证数据的一致性。
如图：
这里有一个 UNLOCK ，它上面是没有加锁的，也就是说这个 UNLOCK 其实是没有加锁的。
如图：
寻找到应用 DB ，比如说这里的 test 2，之前不加参数会有一个 READ ，
而这里是没有的，也就是说这里没有给它进行加锁。
因此对于 single-transaction ，它是可以保证一致性而且它是通过事务来保证一致性，而且不会涉及只读锁，影响比较小。
③然后再看 Master-data 这个参数，它主要运用于比如说需要知道 bin log 的位置，比如说需要去搭建一个存储关系就需要运用 Master-data ，下面请看过程。
首先等备份完成，如图：
可以看到，这里首先会加一个 FLUSH TABLES WITH READ LOCK ，把整个库的表上只读的锁，然后再把它们设置成 RR 的隔离级别，开启一个一致性读的事务，然后在做完 SHOW MASTER STATUS 之后就给它 UNLOCK ，因为是 Master-data 才给它加一个锁，只有在上锁之后才能获取 bin log 的位点，获取位点之后的流程与之前 transaction 的备份方式一样，但是也有不同，Master-data 会有一个 FLUSH TABLES WITH READ LOCK 这个锁，这个锁非常短因为它只需要获取到 MASTER STATUS 即可
④all-datdbases 是通过事务的形式保证数据的一致性，如果这个库里面非事务引擎的表比如 myisam ，为了保证非事务引擎数据的一致，这里提供了 lock-all-tables 参数，它会锁定所有表，然后去保证一致性。然而 lock-all-tables 参数影响比较大，所以很少被使用，云上的库是不支持 myisam 引擎的，所以以后在做运维和表设计的时候尽量使用事务性引擎的表，因为事务性引擎对备份恢复或者其它有很大的好处。
⑤以下代码请自行了解：
#mysqldump—master-data=2--single-transaction-A-uroot-pRoot@123>a.sql
164518 11:00:59 14 Connect root@localhost on
14 Query /*140100 SET @@SQL_MOOE="**/
14 Query /*140103 SET TIME_ ZONE='+00:0’*/
14 Query FLUSH /*I40101 LOCAL #/ TARLES
14 Query FLUSH TABLES WITH READ LOCK
14 Query SUT SESSTON THANEACTION ISOLATION LEVEL REPFATABLE READ
14 Query START TRANSACTION /*140100 WITH CONSISTENT SNAPSHOT */
14 Query SHOW VARIABLES LIKE "gtid\_mode'
14 Query SHOW HASTER STATUS
14 Query UNLOCK TABLES
14 Query SELECT LOGFILE GROUP_NAME，FILEN_NME，TOTAL_EXTENTS,INITIAL_SIZE,ENGINE,EXTRA FROM INFORMATION_SCHEMA.FILES
WHERE FILE_TYPE=’UND OLOG’AND FILE_NAME IS NOT NULL GROUP BY LOGFILE GROUP NAME,FILE_NAME,ENGINE ORCER BY LOGFILE GROUP-NAME
14 Query SELECT DISTINCT TABLESPACE_NAME,FILE_NAME,LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL SIZE, INGINE FROM
INFORMATION_SCHEMA.FILES WHERE FILE_TYPE=’DATAFILE’OROER BY TALESPACE_NAME, LOGFILE_GHOUP_NAME
14 Query SHOW DATARASES
14 Query SHOW VARTANLES LTEE ‘ndbinfo\_version’
（3）物理备份
接下来看物理备份36：00
①如图，下图是 xtrabackup 的备份流程图：
首先备份开始的时候会 fork 一个备份进程，也会
启动一个 Redo 拷贝线程，因为 Redo 是记录一个数据库做的动作和事务引擎做的动作，是事务的后进项，所以最开始会把它进行拷贝，拷贝时候会监听 Redo 变化，会写到自己的 xtrabackup log 文件中，然后再去拷贝 InnoDB 引擎的文件，比如说每个表是单表单文件，拷贝结束后这个线程就退出了，后面如果有非事务引擎，就需要给全局加一个锁来保证一致，全局备份即备份 myisam 引擎的表数据结束之后，就可以通知 Redo 拷贝线程停止，停止和退出之后才是完全的 Un log 了之前 Redo 的那个锁，只有最终执行完成之后才能全部退出。
注意：事务引擎知道自己做了哪些操作，只需要拷贝它的 Redo 文件即可，但是非事务引擎的表是没有事务的保证也没有 Redo log 的，所以还是会加锁去保证所有数据的一致。
②以上是2.4版本的一个流程，它有锁的出现，在后面更新的版本中用的是 log table backup 这样一个非常轻量的锁，这样就不会有全局被锁定的情况。上述的锁主要是做了这几个动作：备份非事务引擎的表，获取它的 Bin log 位点也就是 position，以及 GTID 、 Redo log 和 LSN ，还有对 Redo 进行刷盘，全部拷贝完成之后才能退出。
③这里拓展增量备份流程的讲解，如图：
首先找到上次备份的 to_lsn 从该点开始备份增量数据，这个增量数据其实就是之前提及的 binlog 。
④ Xtrabackup 的备份流程将在后面进行具体的演示。
（4）快照备份
①快照备份原理
快照备份的原理是基于存储和文件系统的，不同类型的快照及工作原理不同，主要快照技术有:
1、Copy-on-write 复制写
2、Redirect-on-write 重定向写
3、Clone or split mirror 克隆或镜像
4、Copy-on-write with background copy后台拷贝的复制写
5、Incremental 增量快照
6、Continuous data protection持续数据保护
②这里主要讲解 Copy-on-write 复制写的原理，如图：
COW 快照备份
创建快照，初始化时只创建用来描述源数据块位置的指针信息(元数据)
跟踪原数据变化，在覆盖前，复制旧数据到预留的快照卷空间，更新快照指针数据。
解析：首先，当发起快照备份时，只需要初始化一个一个指针，这个指针主要指向源数据块，然后跟踪原数据变化，在覆盖前，比如说需要写入一个数据，它会在写入之前把 Redo 的数据拷贝到预留的快照空间中，复制旧数据到预留的快照卷空间，然后更新快照指针到新的快照卷的数据，也就是数据更新了，把这个数据拷贝到其他的地方，指针也随之改变。
③快照读取
当读取的时候，没有变更的数据直接从数据卷也就是原来的地方读取，变动了的数据直接从快照卷读取。其实就是读取了指针，也就是扫描了最开始的源数据指针然后把它读取出来即可。
④复制写的优势
空间开销很小：如果数据不更新，就可以直接在源数据中读取，或者说更新的特别少，只需要在备份这个更新数据的前进项即可，所以它的空间开销特别小。
速度快：它的速度特别快。日常生活中使用的不是存储，可能是主机的快照。开始备份的时候只需要创建一个指针数据即可，它只依赖存储的空间大小，哪怕空间很大它的速度也是很快的，它备份的数据也是非常大的。
影响小：因为它的速度快，持续时间比较短，以及它不会有很多锁，所以它的影响是比较小的。
⑤复制写的缺点
会有一点影响数据卷的性能，但影响很小：因为在每次数据更新的时候都会把数据拷贝一份到预留的快照卷中，所以对写入的性能有一定影响，不过影响很小。
（5）恢复到任意时间点的流程
如图：
①找到恢复时间点前最近的一个全量备份集
②全量备份集还原至新数据库
③应用 binlog 增量数据直到指定的时间点
解析：恢复到任意时间点需要一个全量的备份加一个增量的备份。全量类似于之前提及的 recover 过程，也就是把数据提取出来然后去做 recover 过程，把它全量恢复出来之后得到一个位点，再去找增量数据，一个一个应用它的增量数据即可。这里提及了 binlog 的一些位点比如 position 和 datetime 还有 GTID ，这些都可以做一些位点的参考。也就是说，恢复到任意时间点的流程就是：先做一个全量备份的恢复，然后应用增量数据直到某一个时间点。
（6）逻辑、物理和快照备份方式的对比
①备份对象：
逻辑备份的备份对象更精细，可以自定义表和库，或者更精细到某个条件段的数据。
物理备份是实例或者 DB 级别的。
快照备份是数据库实例级别，它对整个数据库涉及到的存储做一个快照。
②备份效率：
逻辑备份需要经过 MySql Server 层到存储引擎层才能把数据读取出来，然后才能存储，所以它的备份效率最低。
物理备份只需要拷贝文件而且做的额外操作也比较少，所以它的备份效率高。
快照备份基于存储，不需要拷贝很多数据，它只需要生成一个快照指针，所以它的备份效率最高。
③恢复效率：
逻辑备份是把恢复的一条条数据再应用到其他的库中，所以它执行的特别慢，恢复效率也很慢。
物理备份直接把整个实例做 recover ，所以它的恢复效率很快。
快照备份是在存储里面做恢复，它只需要做快照指针的转换，所以它的效率非常快。
④备份影响：
逻辑备份的执行时间很长，开销也很大，因为它是 SQL 级别并且有锁，而且还会抢占 CPU 也就是内存资源，所以它的的备份影响很大。
物理备份的备份影响比较小。
快照备份的备份影响很小。
⑤备份数据量：
逻辑备份是逻辑数据备份出来的，不会有数据碎片，它的备份数据量比原库小。
物理备份的备份数据量和原库一致。
快照备份只需要预留一个快照卷，把更新的数据的前进项保存下来即可，所以它的备份数据量很小。
⑥兼容性：指备份结果集恢复到库种的类型
逻辑备份可以恢复到绝大部分不同版本不同种类的数据库，或者进行一些数据转换，也就是可以恢复到绝大部分的存储引擎。
物理备份依赖于数据库版本和架构，它需要保持一致。
快照备份依赖于存储和文件系统，它需要在内部去做恢复。
注意：如今云上已经提供了可下载的快照备份，也可以转换之后把它下载出来。
⑦操作复杂性：
逻辑备份的操作只需要一个命令或者是一个简单的 SQL 即可，它的操作是最简单的。
物理备份中的 xtrabackup 不使用工具也是需要很多参数的，包括在做恢复时候也有很多参数需要考虑，而且还非常依赖于目标库的一个环境，所以它是操作较为复杂。
快照备份的原理基于存储，提供线程的能力，个人操作是比较简单的，但是原理较为复杂。
⑧数据库规模推荐范围：
逻辑备份的数据库规模范围是 MB~百 GB ，最大能到百 G 级别，再大的范围开销时间也长，所以不推荐比百 GB 更大的范围。
物理备份是主流的一个备份方式，它最大能到 TB 级别。
快照备份推荐云盘版实例，快照备份基于存储，本身需要具备这种能力，云上云盘默认使用快照备份，它也是非常高效和稳定的一种方式。
四、云上备份恢复能力与场景
1.云数据库 RDS 备份恢复流程
如图，以下是云数据库 RDS 备份恢复的流程：
解析：首先，可以看到，这里有 Full backup 和增量备份。就像最开始提及的：对一个实例做一个备份恢复需要合理的安排全量和增量备份的频率。这里做了七天三次的全量备份，其它时间用于做增量备份，三次全量备份然后其它时间全部做增量备份是一个频率比较高也比较合理的值。云上做备份时候，比如高可用的、有节点的在被全量备份是在 slave 上做的，增量备份比如备份 binlog ，不管是在 master 还是 slave ，每个节点都会做备份。不管是全量还是增量备份，都会直接被上传到 OSS ，上传之后，包括本地的一些 binlog 其实是可以删除了的，所以云上也提供了一些参数可供选择，比如管理本地保留文件的时间以减少空间的占用。上传到 OSS 之后数据已经就在上面了，这里还提供了一些一键化功能比如快速恢复到某个时间点，这个功能其实就是按照之前提及的恢复流程做的，它可以很快的恢复到一个时间点，
2.云上恢复能力及场景
(1)恢复全量数据(克隆实例)：将实例任意时间点的数据完整地恢复/克隆到全新实例
(2)库表恢复：将指定库/表恢复到原或新实例到任意时间点
如果客户只需要把某一个库或者表恢复到指定的时间点比如需要查问时间点或者数据都可以通过这个实现。
(3)应急恢复(沙箱实例)：DBS 基于 Copy Data Management(CDM) 技术，将数据快速恢复至独立的 DBS 沙箱实例
如果有很多测试或者是很多应用场景就可以通过它实现。
(4)DMS 数据追踪恢复： DMS 按需找到目标时间段内的相关更新，汇总生成逆向的回滚语句，追踪完的数据可批量生成回滚脚本，最终执行到数据库中完成数据的修复。
主要是 DMS 提供的一个功能，假设客户误删了一个数据，恢复数据的正常的流程是需要先恢复整个全量备份然后再恢复到指定任意时间点，把数据恢复之后再进行拷贝。但是这里 DMS 提供了一个方法：只需要给出删除操作的动作和做删除操作的时间点，DMS 会去找 binlog ，反向生成回滚 SQL ，追踪数据之后只需要将回滚 SQL 再次应用回去即可。相当于就是去 binlog 里面找到回滚数据，这取决于 binlog 的保持时长，不同的管控模式下 binlog 的保存时长不一样，这可以参考下面的备份范围，如图：
同时，可以看到数据追踪的速度是很快的，恢复全量数据比较慢，恢复库表的速度也很慢。这三种方式提供了一键式恢复的功能。
3.RDS Mysql 其它数据备份/恢复技术
（1）Recycle Bin ：临时将删除的表转移到回收站，可以通过命令直接恢复。
在其它很多商业化数据库中都有这种回收站的功能，Mysql 也实现了这种功能，它在开启这个功能之后，比如当删除了一条数据或者一张表之后，它会在__recycle_ bin 这个 DB 下面把原来的表挪到这里，然后生成一个_InnoDB__private id 对象，索引也会移过去。这里其实是提供了一个 DMS recycle 工具包去做一些操作，比如看回收站有哪些表或者是清除和恢复表。
（2）以下提供了一些参数和命令：
参数 |
说明 |
loose_recycle_bin |
是否打开回收站功能，包括 session 级别和 global 级别。 |
loose_recycle_bin_retention |
回收站保留时间，单位:秒。 |
loose_recyce_scheduler |
是否打开回收站的异步清理任务线程 |
loose_recycle_scheduler_interval |
回收站异步清理任务线程的轮询间隔，单位:秒。 |
loose_recycle_scheduler_purge_table_print |
是否打印异步清理现场工作的详细日志。 |
管理 Recycle Bin |
说明 |
call dbms_recycle.show_tables(); |
展示回收站中所有临时保存的表 |
call dbms_recycle.purge_ table(‘<TABLE>’); |
手动清理回收站中的表 |
call dbms_recycle.restore_table('<RECYCLE_TABLE>','<DEST_DB>',’<DEST_TABLE>’); |
恢复回收站内的表 |
解析：第一个是回收站的开启命令，它有 session 和 global 级别；然后是 recycle_bin_retention，也就是回收站的保留时长，超过这个时长会被删除掉；然后是回收站异步清理线程；还提供了清理间隔；最后管理这些的有 purge_table、reserve_table 等等，它们会进行查看删除和恢复的过程。若有条件可自行进行测试。
4.RDS Mysql 其他数据备份/恢复技术
接下来讲解 RDS SQL 的闪回功能
（1）Native Flashback：通过 SQL 语句查询或恢复指定时间点的数据，保证在误操作后可以快速获取历史数据。
对比之前回收站功能，假设需要查询某一个数据，不是删除了表或者其他，而是通过 SQL 可以直接查询过去某个时间点的数据。具体的语法其实就是：SELECT … FROM <表名> AS OF TIMESTAMP <表达式>，也就是可以让数据库自己去找历史时刻的数据值。原理其实也很好理解，就是 Undo 去记录数据前进项，比如有一个闪回原点，此时 Update 了一张表到100，记录这个前进项到 Undo 上面。然后 T2时刻 Commit 了，但是过了某一段时间需要查找 T3时刻 A 的值，因为当时它已经是100了但是需要查 T1 时刻的值也就是50，在查的时候会对比它的 LSN 值也就是日志序列号，如果发现数据页 LSN 时间大于 T1 就说明数据页是在 T1 后修改过了的，然后需要在 Undo 中查找修改前的值，对比之后就能在 Undo 里面找到原来的 A 等于50这个值。其实它是依赖于 Undo 来做的。
（2）前提条件：不支持跨 DDL 的历史版本数据查询，仅支持 innodb 引擎的表。
闪回有一定的条件，不支持跨 DDL 的历史版本数据查询，也就是说如果 Update A 等于100之后再做表结构变更是不行的。因为闪回基于 Undo ，所以它仅支持 innodb 引擎的表。
（3）以下提供了一些参数供参考：
名称 |
说明 |
INNODB_RDS_FLASHBACK_TASK_ENABLED |
描述:Native Flashback的功能开关。 |
INNODB_UNDO_RETENTION |
描述： undo 记录的保留时长，超出该时长的 undo 记录无法查询，单位:秒。 |
INNODB_UNDO_SPACE_SUPREMUM_SIZE |
描述： undo 表空间可占用的最大磁盘空间，单位: MB 。占用空间超过这个值时，忽略 INNODB_UNDO_RETENTION 参数强制清理undo记录。 |
INNODB_UNDO_SPACE_RESERVED_SIZE |
描述:预留的 undo 表空间大小，单位:MB。在 INNODB_UNDO_RETENTION 参数非0的情况下，将使用这部 分空间尽可能多地保留undo记录， |
解析：第一个是功能开关，然后是 RETENTION 也就是 Undo 记录的保留时长，如果 Undo 保留的时间不够长，那么在 Undo 中查询时候，数据的前进项有可能已经被覆盖了，也就是说能查询到多久以前的数据依赖于 Undo 的保留时长。Undo 保留时长越长，占用的空间就越大，所以要考虑空间占用或者是空闲空间的情况，这里提供了一个参数，也就是最大占用磁盘空间的值，磁盘空间不能超过这个值，INNODB_UNDO_RETENTION 和 INNODB_UNDO_SPACE_SUPREMUM_SIZE 这两个参数在安全范围内提供时间最长的历史查询。
