1.前言
A云Polardb-x 1.0现已全面升级为Polardb-x 2.0，但Polardb-X 1.0有其自有特色，仍然有很多企业在使用Polardb-X 1.0方案。那么，当这些企业想将业务系统迁移至腾讯云时，该如何进行数据库选型？怎么样进行数据同步？其中又会涉及到哪些问题呢？
2.A云Polardb-X 1.0介绍
Polardb-X 1.0原先叫DRDS，与Polardb-X 2.0相比，最大的区别是DRDS实际上是一个分库分表的中间件，通过在后端挂载RDS Mysql或Polardb来对外提供服务。Polardb-X 2.0是元原生分布式数据库。
Polardb-X 1.0 架构如图所示：
Polardb-X 1.0架构Polardb-X 1.0的架构中，大量功能依赖外围管控系统完成，例如：
- 扩容，使用内部一个叫精卫的组件来进行
- 元数据，一个地域内会共享一个叫Diamond的存储
- 主备探活、切换，依赖一个叫ADHA的组件
- 等等
3.腾讯云数据库选型
了解Polardb-X 1.0的基础架构后，我们来看数据库迁移的场景。以某一客户为例，该客户使用的场景是Polardb-X 1.0 Polardb的部署架构，数据量将近1个T。决定迁移腾讯云后，在进行数据库迁移及选型时，主要考虑以下几种架构：
- shared nothing架构，代表的是腾讯云TDSQL Mysql数据库，特点是简单开放，稳定可靠。
- NewSQL架构，具备水平伸缩能力，代表的是TiDB，在云上需要自己去搭建及维护，没有PaaS服务。
- 云原生数据库，代表的是TDSQL-C，存算分离架构，具备极致弹性能力。
考虑到数据库的重要性及维护的便利性，如果是自建数据库TiDB需要客户自己去部署、运维，会耗费比较大的精力，无法发挥云计算的优势，建议客户排除TiDB。同时，基于客户应用对于分布式数据库的需求，最终选择TDSQL Mysql。
4.数据库迁移
在确定数据库选型后，我们通过调研发现A云DTS和腾讯云DTS都不支持从A云Polardb-X 1.0同步到腾讯云TDSQL Mysql。既然无法使用工具实现跨云的分布式数据库同步，该怎么办呢？查阅A云文档后，我们决定换一个思路，通过设置一个中间库，先将数据从A云的Polardb-X 1.0数据同步到RDS Mysql，然后再使用腾讯云DTS将数据同步至腾讯云的TDSQL Mysql。思路如下：
数据库迁移方案但是仔细查看A云DTS的帮助文档可以发现，DTS并不支持Polardb-X 1.0挂载Polardb的场景同步到RDS Mysql，只支持Polardb-X 1.0挂载RDS Mysql的场景。好在A云Polardb-X1.0在控制台上提供了数据导出功能，可以自动将数据通过导出的方式同步到RDS Mysql，支持全量 增量。经验证，该工具可以满足数据同步的需求，并且同步的数据没有异常。具体步骤如图。
完成数据从Polardb-X 1.0到RDS Mysql的同步后，剩下的步骤就简单了，可以使用腾讯云DTS工具进行RDS Mysql到TDSQL Mysql的数据同步。
5.TDSQL Mysql和Polardb-X 1.0的适配问题
前面已经对Polardb-X 1.0迁移到腾讯云TDSQL Mysql的方案进行了介绍。实际项目落地过程中，除了数据的同步和校验，还遇到了很多其他问题，在此列出，供大家参考。
5.1. 全局二级索引问题
A云Polardb-X 1.0支持全局二级索引功能。全局二级索引（Global Secondary Index，GSI）支持按需增加拆分维度，提供全局唯一约束。每个GSI对应一张索引表，使用XA多写保证主表和索引之间数据强一致。
全局二局索引主要解决的是什么问题呢？
如果查询的维度与逻辑表的拆分维度不同，会产生跨分片查询。跨分片查询的增加会导致查询卡慢，连接池耗尽等性能问题。GSI能够通过增加拆分维度来减少跨分片查询，消除性能瓶颈。
解决方案：
以前的TDSQL Mysql不支持全局二级索引功能（现在已支持，可以申请使用），可以让客户基于业务进行压测，验证没有全局二级索引时是否影响性能。本项目经实际测试，TDSQL Mysql即使没有全局二级索引时，完全不影响性能，比之前时延更短。现在，TDSQL Mysql已经支持了全局二级索引功能。
5.2. binlog订阅问题
现在越来越多的企业部署了大数据平台，进行数据的分析及决策。那么，大数据平台怎么从关系型数据库（如mysql）同步数据呢？有过数仓开发经验的同学很容易想到sqoop，但sqoop是一个离线同步工具，适配的是T 1的场景。如果需要对Mysql中的数据进行实时分析该怎么办呢？
此时有几种方案，一种是用flink或腾讯云oceanus等流计算工具，通过Mysql CDC（change data capture）机制捕获变更数据。第二种是比较常见的方案，通过Cannal/Maxwell等工具订阅Mysql binlog，然后同步到kafka，再经过flume等清洗后同步至数据仓库。
回到本案例场景，A云的Polardb-X 1.0支持标准binlog订阅，支持通过Cannal/Maxwell等工具订阅，而腾讯云的TDSQL Mysql分片IP地址不对外暴露，暴露的是代理IP地址，无法使用开源工具订阅，要解决该问题，主要有三种思路。
方案1，使用腾讯云DTS订阅功能。原理是通过对TDSQL Mysql分片row格式的binlog日志的解析，将binlog事件封装成消息存储至分布式消息队列kafka集群中，供第三方的消费者进行消费，其原理如图：
但是此种方案需要进行一定的应用改造，如果迁移周期比较短，会导致没有时间进行充分的认证。所以在本项目实际落地过程中，采用了非标方案2（不建议采用该方案，客户迁移期过度后，改为了方案1）。
方案2，将分片的主节点手工绑定IP地址，然后进行订阅。但此方案有一个巨大风险，由于是手动分配的IP地址，如果分片内的主备切换后，会导致订阅失败，从而影响数据业务。
方案3，将TDSQL Mysql数据同步至MariaDB后，再进行订阅。经验证，该方案由于腾讯云MariaDB会产生一些特殊的binlog，导致maxwell无法解析，最终由于消息堆积，造成订阅失败。
所以最终迁移过程中使用方案2，迁移完成后改为方案1进行TDSQL Mysql的订阅。
参考链接：
Polardb-X 1.0和Polardb-X 2.0 对比：https://zhuanlan.zhihu.com/p/333458136
Polardb-X 2.0 ：https://www.alibabacloud.com/help/zh/doc-detail/311498.html
Polardb-X 1.0：https://www.alibabacloud.com/help/zh/doc-detail/311498.html
Polardb：https://help.aliyun.com/document_detail/58764.html
