开发者学堂课程【关系型数据库 ACP 认证课程：【视频】-PolarDB-云原生云关系型数据库的解析与实践（下）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/927/detail/14621
【视频】-PolarDB-云原生云关系型数据库的解析与实践（下）
（2） Redo 日志备份
Redo 日志是指记录生成备份集后的增量数据，称之为Redo日志。精确到某个时间点恢复数据，这两者都是缺一不可的。
同样我们是可以设置数据备份跟Redo日志备份的一个备份策略都是在备份设置的这个页面里面进行设置的。
我们能设置比如数据自动备份的频率、常规的还是增强的、数据文件保留的时长比如一级备份默认是七天，然后二级备份关闭状态时可以打开自己设置一些保留的时间。像日志备份保留的时间默认是七天等，这些都可以做一些设置。
可能有的同学会关心一些费用的问题。费用的一些问题，目前是在PolarDB 的备份和恢复的功能都可以免费进行使用。但是，备份文件是需要占用一定的存储空间，因此有一级跟二级备份的区别，还有日志备份，这几种手段。所以这三者之间它们的单价会有一些小小的差异。一般来讲在整个阿里云的生态里面关于存储的费用，单价学都是比较低的。
二、PolarDB 恢复
1、PolarDB 数据恢复概述
数据恢复对应的场景就是数据可能会出现某种误操作或者一些系统故障导致数据出现问题。
比如我们误删表误删库，甚至夸张一点从删库到跑路。把集群给删掉或者可能由于程序的一些 bug ，然后对一些数据进行了错误的操作，比如一些机制上的问题、程序设计的一些问题、 bug 导致更新的结果都是错误的。
这时候我们需要对数据进行一些回滚、恢复。 PolarDB 是支持按照时间点或者按照备份集进行恢复。事实上就是说我们在不同的场景里面我们可以选择的备份恢复的方式，其实就是这几个元素的组合。比如我们可以通过集群整体恢复的方式恢复整个集群，这是一种数据恢复的方式。
从方法上看，我们通过集群恢复整个集群可以选择按时间点来恢复或者按照备份集进行恢复。如果按集群来恢复的话这个力度太粗了能不能基于库表的方式，指定库或者指定表的方式来进行恢复，这个其实也是支持的。
如果我们要恢复的时间点刚好是我们某个备份集的时间点那就可以直接基于库表，然后按备份集进行恢复。如果恢复的时间是在备份集发生的其他的时间，我们就可以选择按时间点恢复。
所以无非就是，库表恢复跟集群恢复还有时间点恢复跟备份集恢复，这两个条件两两交叉。这就是我们的 PolarDB 数据恢复的时候能选择的一些操作，其实就是这四种。
整体来讲，恢复数据的时候，集群是可以恢复七天内的任意时间点，并且是基于 Redo 日志。数据的恢复是基于全亮的快照备份加 Redo ，是全亮加增量。全亮是指定的，刚好是那个时间点或者是你指定的任何时间点，然后去找离它当前最近的备份集先做一个全量的恢复。指定时间点跟备份集之间的差值通过 Redo 日志进行回放。
整个数据恢复的一个整体机制就是全亮加增量的一个机制。在这个过程当中，尤其是 Redo 日志，它其实是一个写入跟更新很频繁的操作。因为它要进行回放，就是原来数据库怎么操作， Redo 重新去回放一次。所以这个对我们的数据库的IO是有一定的影响的，大家用的时候可以去评估考量一下。我们可以选择集群地全面恢复，也可以选择库表级别的恢复。
2、PolarDB 恢复操作
（1）、全量恢复
全量回复是指把全量的历史数据恢复到一个新的机器集群并且验证数据以后再通过把恢复后的数据迁移到原集群的方式。就是我们会生成一个临时的克隆实力，然后在上面进行数据的校验或者做一些数据的修正。然后我们再通过 DPS 把数据迁移回原集群完成数据回溯。
（2）、库表恢复
库表恢复是指恢复指定的部分的库或者部分的表到原集群，比如游戏的业务里面，游戏有时候可能因为一些规则设计不合理，导致了一些可能出现被玩家刷装备、刷金币等情况，有可能会进行回档，回档有时可能说不是整个数据库都回，可能只需要恢复某些发现有漏洞利用漏洞玩家的数据。这时候我们就可以使用，库表级别的恢复的方式。所以其实恢复的操作就是两个条件跟两个条件交叉使用就可以了。
3、备份集恢复（全量/库表）
上图页面最上面这一段就是备份与恢复的那个页面的列表。我们要怎么去恢复，首先一定是备份集一定要事先存在或者点击按时间点去恢复或者点击恢复到新的集群指是按备份集恢复。无论是哪个，最后都会跳到以上页面。
如果是按备份集，有个下拉框让我们来选择哪个备份集。如果是按时间点的话，那就会让我们去选择恢复的时间点。页面的下方会有一些参数让我们进行选择，比如我的地域、可用区 pc网络相关的一些信息。然后选择的创建出来的临时的克隆实例，它的节点的规格、节点的个数等。
进行备份集恢复的时候，有几个注意事项。首先，库表恢复里面的从备份集里面的恢复，只支持从一级备份的备份集来恢复，二级备份目前暂时不支持；库表恢复只会恢复指定的表。操作的时候要确认我们选择的表，因为只有我们选择的比较才会被恢复并且有个隐含的限制就是集群内的表要小于五万张超过五万张的时候，现在有一个上限就是不能使用的。那么库表恢复不支持恢复触发器，那么也不支持恢复外件，这个需要要注意一下。右边的截图是说这时候，相当于我们选中的库跟表才会被进行恢复，在底下下方会显示出来。按时间点进行恢复的话。页面其实是很像的。
4、时间点恢复（全量/库表）
如果按时间点那底下就会让我们选择时间。下方的参数其实也是一样的，就是地域信息、可用区信息、信息网络的信息、节点的信息、结点的个数等等，这些都是一样的。同样的如果是全量的话那它直接就恢复了，如果是库表的话那还要选择恢复哪些库、哪些表，然后提交操作等待恢复完成就可以了。
后续的操作就是创建出了一个新的临时的克隆实力，我们需要登录到这个新的克隆的集群，要连接到这个新的集群。然后验证数据是不是正确的或者要不要做一些操作，确认没有问题以后，再通过DPS把数据导回到原集群里面，这样的话就完成了我们的整个数据的回溯动作。时间点恢复关于库表恢复的一些约束限制跟上述注意事项一样。
三、PolarDB 数据迁移
1、PolarDB 数据迁移方案概览
PolarDB 本身提供了多种的数据的迁移，其实包括后面的同步，提供了多种的迁移跟同步的方案可以满足我们一些比如上云、千云跟同步的一些需求，比如我们支持从RDS 迁移到 PolarDB 或者从PolarDB 迁移到 RDS ，其实两者是两个方向，就我到你你到我两个方向；也可以支持我们自建的数据库迁移到 PolarDB 或者是第三方的云数据库迁移到 PolarDB 。比如我是在一些其他的友商的云水库里面迁移到 PolarDB 里面来，甚至是 PolarDB 之间的数据迁移都可以支持并且可以在不影响业务的前提下平滑的实现迁移。
平滑的迁移的核心是利用阿里云的数据传输服务 DTS ， DTS 的功能主要就是三个阶段，数据迁移部份的功能主要有三个阶段，第一个叫做结构迁移，就是我们把原数据库的一些库表里面的对象的结构定义，迁移到目标库上面，比如像表、视图、存储过程、触发器、函数等等像这些结构性的东西啊ddl语句，先迁移过去。然后，全量的迁移就是会把原数据库当前那个时间点的存量数据全部的迁移。在迁移的过程当中，其实原库是不进切的，也就是存的数据很多。那么这时候，原库可以不进切的，因为在迁全量数据的过程当，原库的一些变化的增量数据增量更新，会被DTS缓存下来，这时候会有增量迁移，当全量结束以后会有增量更新，通过增量更新就可以实现在某一个时间点，原库跟目标库两者之间能实现实时同步的效果。原库数据跟目标库之间的数据能实现实时的同步。这时候我们在做一个前端的业务去做一个数据库的割接的工作就可以了。这样就能够实现平滑的数据的迁移。
（1）数据迁移：一键升级
PolarDB 支持把 RDS MySQL 这个版本一键升级到 PolarDB MySQL 引擎。就是原来可能购买的是 RDS ，但现在可以通过 RDS的控制台上的一键升级的按钮就可以直接把原来的RDS升级为PolarDB 。升级后的 PolarDB 集群跟原来的 RDS 里的账号、数据库、 IP 白名单还有一些必要的参数都会被保留，甚至原来的数据库的连接地址都是一模一样的，所以这个升级对于我们的业务是无感知的。但你可能会有一段时间不能访问，就是说我们业务程序上是不需要做修改的，那么就可以很方便的升级到 PolarDB 里面，并且这个过程是不需要我们去控制DTS去触发一些任务。我们只需要在 RDS 工作台点一键升级，然后就可以完成整个经历的过程，所以这个过程里面数据是零丢失的。并且停机的时间是比较短的，迁移过程，仅闪断一次。就是真正的从 RDS 切换到 PolarDB 的时候，访问链路是变化的。所以这时候必然会有一次闪断，在闪断前还是比较容易解决的。我们的业务里面有自动重联的机制其实就可以了。
上一代 RDS 原生的关系数据库的这种方案可能在面对我们在云原生时代，可能 PolarDB 会更好的来去支持我们的业务，能够提供更好的性能。所以我们可以选择一键升级，整个过程背后其实还有一句话要讲的就是升级到 PolarDB 以后原来的 RDS 怎么办。其实升级过去以后，我们原来的RDS不再需要，比如跑了一段时间，发现我们的业务跑的已经很稳定了，这时候不再需要原来的 RDS 。我们可以去申请这个原有的 RDS 的退款，我们可以通过工单的方式去申请这个退款，这样可以平滑的整个迁移过去。
一键升级对RDS的版本有一些小小的要求，因为 RDS 有很多的分支、很多的版本。目前支持一键升级的都是高可用版的，单机基础版是不支持的，支持的是5.6、5.7的高可用版。另外有一个小的地方要注意，就是如果 RDS 的高安全模式已经开通的话，那么这时候，我们一键升级的时候，需要在 RDS 里面创建一个高权限账号，或者是先把这个代理状态关闭，切换为高性能模式，才能进行一键升级，有这么一个要求。
（2）数据迁移：一键克隆
一键克隆和一键升级有点像，是把当前的 RDS MySQL 上面的数据一键克隆到新的 POLARDB MySQL 集群里面，这个操作会新建一个跟源 RDS 实例的数据一模一样的 POLARDB 集群，同时，它也会包含原来的 RDS 实例里面的账号、数据库、 ID 白名单和一些其他必要的参数。与一键升级不同的是，一键升级是支持增量数据同步到POLARDB 集群的，而一键克隆是增量数据是不同步的。
一键克隆的方案的亮点是这个过程是不需要成本的，这些数据也是零丢失的，所以两者的区别就是对增量数据的处理上有一些区别。所以，无论是升级还是克隆，两者要能够正常去发起的前提约束是一样的，跟一键升级的约束是一样的，同样也要求这个 RDS 必须是高可用版的5.6、5.7的。并且，它必须是属于没有打开数据库代理模式的，还有一点就是原库的元素的引擎，数据库的表引擎必须是 INNODB ，其实 RDS 里面默认的就是 INNODB ，所以一般问题不大。
（3）数据迁移：PolarDB 之间数据迁移
同样通过 DTS 实现，就是从 DTS 把一个 PolarDB 集群的数据迁移到另外一个 PolarDB 集群里面，整个过程也是利用 DTS 数据迁移的三大阶段的能力结构迁移，全量迁移跟增量迁移。这三个阶段只要有机的组合就能够实现接近于临停机的动作。
通过 DTS 数据迁移的过程里面有一些必要的注意事项。上图列的注意事项，并不是说只有在 PolarDB 之间进行数据迁移的时候才是这样子的，我们使用DTS去进行数据迁移的时候，这些注意事项基本上都是成立的。
