开发者学堂课程【关系型数据库 ACP 认证课程：【视频】-PolarDB-云原生云关系型数据库的解析与实践（下）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/927/detail/14621
【视频】-PolarDB-云原生云关系型数据库的解析与实践（下）
首先，创建原集群和目标集群，或者原库和目标库，创建原集群或者目标集群，另外还有一个小的约束条件，就是我们创建目标集群的时候，在选择存储空间时，一般，我们要不小于原集群的存储空间，这样才能确保我们迁移的成功。更好的情况是推荐我们目标集群的选择的存储空间要比原集群的存储空间要略大一些，因为它可能会有一些中间数据，临时数据，这样能够确保我们迁移的成功率。
第二，增量数据进行迁移的时候，需要原集群开启 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 的一些应用场景，比如，在一些业务的高并发的场景、一些大容量的场景，或者是一些AP跟TP相结合的一些新形态。
在功能概览这块就是先列了一下，基本管理里面的一些要点。那这块我们是在基本管理去展开的。在第二个小节里面介绍了 PolarDB 的一些架构跟核心技术，架构上有几个特点，易写多读、读写分离，然后 PolarDBFS 共享的分布式存储，计算与存储分离等等。
核心技术比如 PolarDB 的物理复制的一些技术、切换的一些技术和存储的一些技术。昨天很大的一部分的篇幅是在PolarDB 基本管理这块儿，我们分别从 PolarDB 的实例管理、账号管理、连接数据库的方式，比如我们设置白名单，然后通过一些 DMS ，或者通过程序，通过一些手段，去连接到 PolarDB 上面来。 PolarDB 的一些参数，我们可以进行设置。 PolarDB 也提供了一些监控与诊断的一些页面，我们可以看到一些实时性能，锁分析、空间分析等等。
关于 PolarDB 的一些安全，因为大部分阿里的产品大讨论安全都是事前可以做什么，事中有什么安全机制，事后有什么安全机制。 PolarDB 的核控心的管理。 PolarDB 的访问与存储，讲了 PolarDB 的访问方式，可读可写的方式或者只读的方式。地址有集群地址和主地址。 PolarDB 也有数据库代理，数据库代理也支持读写分离，负载均衡、连接池等等能力。存储类型主要讨论了数据保存的费用问题，计算包、资源包。最后讲了数据备份与恢复、迁移与同步。
