开发者学堂课程【关系型数据库ACP认证课程：快速学习 PolarDB-云原生关系型数据库的解析与实践（下）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/927/detail/14621
三、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 去进行数据迁移的时候，这些注意事项基本上都是成立的。
首先，创建原集群和目标集群，或者原库和目标库，创建原集群或者目标集群，另外还有一个小的约束条件，就是我们创建目标集群的时候，在选择存储空间时，一般，我们要不小于原集群的存储空间，这样才能确保我们迁移的成功。更好的情况是推荐我们目标集群的选择的存储空间要比原集群的存储空间要略大一些，因为它可能会有一些中间数据，临时数据，这样能够确保我们迁移的成功率。
第二，增量数据进行迁移的时候，需要原集群开启 Binlog ，这就要求我们原集群里面的 Binlog 日志进行保留，一般来讲， DTS 它会要求本地 Binlog 日志的保留的时间，应该要大于20小时以上的，默认应该是七天。不改的话，默认是七天，有改的话，那最好是给它改回去。因为，如果没有 Binlog ，增量的迁移肯定就会出现一些丢失的情况，所以可能会出现一些极端情况下，会有一些像数据不一致的，或者丢失的情况会出现。
迁移失败的任务， DTS 会自动去触发， GPS 自己本身具有一些高可用的能力，并且，它也会有一些失败自动重试调度的一个能力。
业务切换到目标集群的时候，需要先停止或释放迁移任务，避免原端的数据覆盖目标集群的数据。
用于数据迁移的最后账号需要有补写权限。
（4）数据迁移：RDS 迁移至 PolarDB
只是场景不同，整个套路基本是一样的。通过 DTS 把 RDS 的数据迁移到 PolarDB ，同样也是利用了全量、增量、结构，这三个争议的过程。从账号的权限上来看，还是一样的，就是对于这个原始力，是需要读写，目标实例，其实我也是需要有一定的读写的一些权限，我们后面会有一些表格列出需要的权限。
上图列了几个阶段，其实这些整体的套路基本上是这样的，就是这么一个过程。首先我们在 DTS 上创建一个迁移的任务。
然后，我们在这些任务里面的第一步，配置资源实力和目标实例的一些信息，原库的信息，数据库的信息，原库的信息需要选，实力类型： PolarDB、RDS 等，接入的实力的地区：阿里云上，然后是实例 ID，其实选择地域以后，它自己会帮你侦测出来，你就选择你的原库或者目标库就可以了，最后的账号跟密码应该提前设置好。然后通过测试链接点一下，测试通过以后就可以通过授权白名单到下一步，因为访问数据库都是需要有白名单的，所以里面的原实例的信息，目标集群的信息，因为从 RDS 到 PolarDB ，所以原实例就是原 RDS 的实例，目标集群就是目标的 PolarDB 的集群。如果是 PolarDB 到 RDS ，就反过来原集群的信息、目标实例的信息是一样的，这过程就是配置源的信息测试有没有，通过配置目标的信息测试有没有通过，然后授权白名单进入下一步。
下一步，我们要选择迁移的类型跟对象。迁移类型包括全量、增量跟结构这三种迁移的类型。迁移的对象包括整个库或者若干个库，若干个表，就是你的库表列都可以作为迁移的对象，这个力度都可以这么去选择。
再下一步就是预检查，并启动。迁移任务在正式被启动的时候，之前会先进行一些预检查，会有一些预检查项，只有所有的预检查项目全部通过以后才会正式的启动迁移的任务。
如果检查失败，它就会告诉你失败的一些详情，我们就要根据这个失败的提示去进行一些修复的动作。
然后，预检查全部通过，进度显示百分百以后，就会到下一步，确认DTS 的购买信息，然后我们可以选择小中大，不同的性能的迁移规格。因为不同的规格的迁移的性能的速率是有一些不一样的，费用也不一样。我们可以根据业务场景来进行选择，之后，购买以后点击启动，这个迁移的任务才真正启动。然后等待数据的迁移到同步的完成就可以了。
（5）数据迁移：本地 MySQL 迁移至 PolarDB
过程基本上我们在前面的讲解，大家可以看到套路都是一致的，就是我可以利用 DTS 来实现本地不停服的情况下，利用 DTS 三个阶段的有机组合，就能够实现数据迁移到目标 PolarDB 的集群上。
迁移的顺序，正常来讲就是结构先迁，再迁全量的数据，然后再迁增量的数据，之后，实现同步的效果。
关于权限的要求，基本上与上图差不多。对于原实力来讲，结构迁移，只需要有查询权限就可以。同样的全量迁移，也是只需要有查询权限就可以了。有增量迁移的话就需要有一些书法权限和一些复制权限。对于目标端来说，肯定都是需要有读写权限。从权限上，基本都是这样的。
（6）数据迁移：PolarDB 迁移至 RDS
从 PolarDB MySQL 版本迁移到 RDS MySQL 版本，过程也是一样，包括结构迁移、全量迁移、增量迁移。为了保证迁移数据的一致性，在开始迁移之前，我们建议停止写入数据到 PolarDB 的集群。另外，目标实例的存储空间，应大于 PolarDB 集群的已使用空间。
你说我的业务不能停，那我能不能实现接近于不停机的迁移呢？其实理论上也是可以实现的。只是说对于DTS三个阶段的控制，我们自己就要特别的小心。
（7）数据迁移：ECS 自建 MySQL 迁移至 PolarDB
ECS 自建 MySQL 迁移至 PolarDB ，库存其实都是类似的。
关于 PolarDB 的数据迁移，其实万变不离其中，我们就是好好的、灵活的去利用我们 DTS 的功能，就能够实现上面所列举的这五类的场景。无论是从 RDS 迁到 PolarDB ，或者是从 PolarDB 迁到 RDS ，或者是自建库迁到 PolarDB，或者是其他的云数据库迁到 PolarDB，或者是 PolarDB 之间进行互相迁移都是可以的。
四、PolarDB数据同步
PolarDB 的数据的同步。
PolarDB 结合 DTS 的数据库同步功能，我们也同样的提供了多种数据的同步的方案。可以实现，比如从 RDS 同步到 PolarDB 或者是从 PolarDB 同步到 RDS ，或者是 PolarDB 之间进行数据同步，或者 PolarDB 同步到比如其他的一些数据仓库或者 ADB 。 ADB 也是通过协议的，所以可以直接同步过去。所以，不同的上云，迁云同步的业务需求。其实 PolarDB 结合我们的阿里云设计程序和DTS都是比较方便的实现。
1、PolarDB通过Binlog实现实时同步
第一个是 PolarDB ，它主要是通过 Binlog 实现实时同步的。因为，它是完全兼容这个开源的 MySQL 的数据协议的。默认情况下，它是使用了物理日志来代替 Binlog 。但是，因为整个 MySQL 的生态很多时候是用 Binlog 代替做数据的同步或者传输。所以，为了跟这个生态相融合， PolarDB 也提供了开启 Binlog 的功能，方便我们去连接到 ES、ADB 这种分析型数据库等等。我们也可以搭建 PolarDB 到 RDS、RDS 到 PolarDB 或者是 PolarDB 之间的数据的实时同步。
在这块里面，有几点要注意一下，
开启 Binlog 以后， Binlog 空间也是属于我们 PolarDB 集群存储空间的一部分，所以它也会占用一部分的存储。
Binlog 默认保留的时间是两周，超出两周以后 Binlog 的文件会被自动删除。
开启 Binlog 以后会导致写的性能下降，读的性能是不受影响的。这个地方隐含是个什么意思呢？就是我们开启 Binlog 也好，甚至是比如我们通过 DTS 迁移也好。我们发现它其实都是会占用我们的源库，或者比如 ITTS 的话，可能会占用目标库的一定的读写资源，所以它就有可能会导致，我们的源库或者目标库的数据库的负载是会有一些上升的。
有一个隐含的条件就是我们在进行 Binlog 的同步，或者数据迁移的时候，我们就要考虑到数据库是不是会由于性能被影响，导致我们出现一些问题。尤其是我们一些规格比较低，或者规格不低，但是业务量非常的大的情况下，比如源库有大量的慢车口，或者是没有见索引，或者存在死锁等等，导致源库的计算量很大，负载很高。这时候，我们再去开启 Binlog 或者这时候再用 DTS 迁移同步的时候，那么毫无疑问，那是会给我们的数据库的压力进一步去提升的，甚至压力提升到一定的程度上，会导致我们的数据库可能就挂了。
这里面有个隐含的条件就是我们在做同步或者迁移的时候，需要去考虑去评估，我们的源库的性能，目标库的性能。
一个比较简单的准则，我们尽量都在业务的平峰期、低谷期的时候进行数据的迁移或者同步的操作。会更好一点。
2、数据同步：RDS与PolarDB之间数据同步
从 RDS 到 PolarDB 之间的进行数据同步，同样呢也是通过 RDS 实现的。
数据同步其实就是增量数据的同步。那么利用 DTS 数据同步的能力，就可以很容易去实现实时的同步。
RDS 跟 PolarDB 之间的数据同步大致可以从同步架构上分为两大类型。
一个是单向的同步。就是由原端到目标端进行单向的同步或者是双向的同步，就是两个实例之间去进行双向同步，你同步我，我同步你。
在单向同步的这个架构里面，有这么几种情况，一个是一对一的单向，A 到 B。
一个是比如一对多的单向，也是一种，或者级连的单向同步啊。级连的单向同步就是 A 同步到 B ， B 再同步到 C ，所以在这里面，我们如果要实现这个效果，我们发现，我们至少要买三个实例，就是要有一个原实例跟两个同步实例。一对多的话就是实例 A 同步到多个B C D 。这种情况下一对多，就要购买多个同步实例，三个 B C D 。应该是三个实例。
还有多对一，多对一也是可以的，比如 B 到 A ， C 到 A 或者 D 到A ，这是多对一的单向同步。双向同步，就是目前只支持两个 MySQL 数据库之间的双向同步暂时还不支持多 MySQL 数据库之间的两两双向同步。
这是关于 RDS 跟 PolarDB 之间进行数据同步的一些讨论，事实上 PolarDB 之间的数据同步的讨论，其实架构也是跟这个基本是一致的，或者是 RDS 跟 RDS 之间数据同步的架构其实基本上也是一致的。
五、回顾与总结
首先，介绍了 PolarDB 的产品简介。产品简介里面主要有三个小节，一个是产品的综述， PolarDB 是一个阿里云自研的新一代的云数据库，它本身是计算跟存储是分离的。深度百分百的兼容 MySQL 的协议。然后 PolarDB 的一些产品的序列，给大家介绍了集群版、单节点、历史库、多组架构等等。然后，又讲了 PolarDB 的一些应用场景，比如，在一些业务的高并发的场景、一些大容量的场景，或者是一些 A P跟 TP 相结合的一些新形态。
在功能概览这块就是先列了一下，基本管理里面的一些要点。那这块我们是在基本管理去展开的。在第二个小节里面介绍了 PolarDB 的一些架构跟核心技术，架构上有几个特点，易写多读、读写分离，然后 PolarDBFS 共享的分布式存储，计算与存储分离等等。
核心技术比如 PolarDB 的物理复制的一些技术、切换的一些技术和存储的一些技术。昨天很大的一部分的篇幅是在 PolarDB 基本管理这块儿，我们分别从 PolarDB 的实例管理、账号管理、连接数据库的方式，比如我们设置白名单，然后通过一些 DMS ，或者通过程序，通过一些手段，去连接到 PolarDB 上面来。 PolarDB 的一些参数，我们可以进行设置。 PolarDB 也提供了一些监控与诊断的一些页面，我们可以看到一些实时性能，锁分析、空间分析等等。
关于 PolarDB 的一些安全，因为大部分阿里的产品大讨论安全都是事前可以做什么，事中有什么安全机制，事后有什么安全机制。 PolarDB 的核控心的管理。 PolarDB 的访问与存储，讲了 PolarDB 的访问方式，可读可写的方式或者只读的方式。地址有集群地址和主地址。 PolarDB 也有数据库代理，数据库代理也支持读写分离，负载均衡、连接池等等能力。存储类型主要讨论了数据保存的费用问题，计算包、资源包。最后讲了数据备份与恢复、迁移与同步。
