XC改造——mysql数据库迁移国产化数据库

最近一直在做XC改造迁移，应用的国产化改造没有什么可说的，记录一下数据库迁移到国产HG数据库的过程，这方面也没有什么公开的工具和文档，需要注意的点也很多，能积累多少是多少吧。

一、数据库选型

近几年国产化的风头很大，各种各样的数据库都面世了，但是如果系统有明确的XC要求，最好是选择相关的政策名录里面的，或者通过安全可靠测评结果的（可能有些数据库厂商也宣称自己符合XC相关要求，但是这块很容易碰到红线，目前也没有行业内普遍认可的标准或名录，公认的就是国家信息安全测评中心的结果，没办法）。

国产化数据库符合要求的不多，不过基本上都是常见的关系型数据库，没有非常冷门的，而且国产化数据库也几乎都是基于开源的数据库封装的，对于有开源使用经验的研发来说，没啥难度。比如很早就出名的达梦、瀚高、人大金仓等。

本次迁移选择的是瀚高数据库，对标的是开源的PG（PostgreSQL），可以说会用PG就可以用HG，在适配测试阶段可以用一个开源的PG先试试，应用改造的难度和工作量也可以随之确定，如果改造难度过大，能够及时更换。在开源的PG改造测试后，我们就正式联系厂商部署HG数据库了（部署需要厂商实施，因为该数据库使用需要License，由厂商的人提供）。基本上数据库选型确定后就代表迁移的工具也确定了，因为各个数据库厂商都会首选自己的迁移工具，虽然有些迁移工具也可以支持其他类型的数据库，但是基本上都是支持开源的，国产的数据库不在他们的支持之列，而且国产化数据库有各种封装和修改，用开源数据库工具很难保证不会出数据异常，后续也找不到技术支持，最好是用数据库厂商给的自家迁移工具。

上云迁移有成熟的方法论，数据库迁移是其中一环，不管是迁移到国产化还是非国产化数据库，整个工作流程是一样的。大致分为四个阶段：信息调研——方案设计——迁移实施——割接演练。

二、信息调研

数据库信息调研的目的是对迁移源端和目标端数据库进行充分的调研，以获得充分的信息用于后续的方案设计和目标端规格设计。

调研内容主要针对源端，包括源端数据库类型、数据库版本、引擎、对外开放端口、IP、资源量、部署模式、数据库数量（分库数量）、模式（schema）数量、表数据大小。另外还需确定binlog开启情况、保留时间、备份情况、保留时间等。

根据实际迁移经验，还需与业务确认哪些库哪些表实时性较高，按实时性要求划分历史数据（冷）、静态数据（温）、实时数据（热），针对不同的数据有不同的迁移策略。

对于目标端调研，主要是目标端数据库类型、版本、引擎、IP、端口、分库策略、表结构对应、部署模式、备份策略、资源量等。为什么要调研这些信息？下面举例说明：

1、数据库类型、版本、引擎、IP、端口：这是数据库的基本信息，不管用什么工具迁移，基本信息必不可少（用户名/密码不属于可公开信息）。

2、分库策略：主要针对数据库架构不同的场景，比如这个数仓迁移的过程就涉及到阿里云ADB和华为云DWS的架构区别，巧的是这次也是mysql 和 pg 的数据库架构

数据仓库架构（一）数仓产品ADB与DWS_adb数仓-CSDN博客https://blog.csdn.net/weixin_53439529/article/details/133922495所以可以直接沿用之前的经验：在PG不分库，而是分schema，database统一用一个大的，schema与mysql的database是对应的，同名即可。

这会产生一个好处和一个坏处：好处是在PG数据库可以同时建测试库和正式库，而且区分非常清晰，因为涉及到应用的改造，所以在测试库修改测试是非常重要的，测试库通过后再用到正式环境里面，极大地提高了改造效率。而且在实际迁移过程中工具的配置是比较麻烦的，database越多越麻烦，根据经验华为的同步工具DTS和HG的迁移工具都是配置到database级别，schema会自动加进去，所以如果只有一个database会极大简化使用过程，mysql这种两级架构的需要重复多次database的配置过程，工作量比较大，特别是分库非常多的应用。

坏处是PG建多个database可能会导致性能下降，这主要针对数据仓库的使用场景，因为数仓的数据量太大，比较合理的方案是正式、测试分不同的数据仓，而不是建到一个仓库中。同时国产化数据库在性能这方面也存在不足，正式和测试建在一个库中，实际使用中切换很慢，而且经常报错。

3、表结构对应：表结构不对应问题主要出现在数据库架构转换的场景，比如 mysql-pg 开源的数据库结构就不同，国产化做了封装后可能会出现更多的不同，数据库厂商可能会宣称可以99%甚至100%对应，但是实测根本不可能。可能会出现的不对应包括但不限于：数据类型，如mysql的数据类型在pg没有对应的类型，迁移工具默认的数据类型与源端不一致，或者在适配过程中发现需要改动的数据类型等。这类问题应该由业务先梳理清楚，如果需要全库修改的就统一在迁移过程中改好，如果是部分库部分表需要修改的就按调研表反馈，归口到数据迁移负责人员。第二种不对应是sql语法不对应，主要是一些sql语法在mysql和pg写法本身就不一样（方言除外），这种问题可以用一个脚本统一梳理出来解决，建议在割接前做，或者业务上明确一个适配完成不再做语法修改的时间节点。第三种是不对应是主键不对应，因为Mysql的主键自增和主键默认值是绑定在主键上的，设置比较简单，而pg的主键自增和主键本身是分开的，主键自增对应到序列，至于序列能否自增是通过设置主键默认值实现的。目前遇到的不对应就这几种，可能还有其他类型，暂未发现。

4、部署模式：主要指数据库单机/主备/集群等部署模式，源端mysql是自建的一个单机数据库，性能和安全性比较一般，在XC环境各种要求比较高，所以换成了主备模式，主库写从库读实现读写分离，这样就需要做一个主备同步策略，间接影响资源的使用。

5、备份策略：备份策略也是由于XC相关的要求较高，源端备份保留1天，但是目标端定的是保留3天，这也是影响资源量的一个因素。

6、资源量：资源量需要在一开始预估出一个大概的数量，因为一些管理原因，我们申请资源和扩缩容都比较麻烦，所以就要求一开始预估尽量精确。通常可以根据源端的资源用量来预估目标端，但是实际迁移过程中随着方案的变化，资源用量也会有变化。比如服务器的CPU/内存，源端是16C64G的裸金属服务器，目标端是虚拟机（超配比CPU1：8，内存1：1），国产化数据库本身需要的内存>32G，因此按两台计算是32C64G。因为迁移工具也部署在了这个服务器上，工具需要的内存大概是10G，每新增一条分库的链路就增加4-5G，所以内存很快就出现不够用的问题。其实最好的方式是申请一台新的服务器给迁移工具使用，而不是占用数据库所在的服务器资源，但是在一开始并不确定数据库本身和工具都需要这么高的资源量，厂商也没有相关的说明，所以后面资源非常吃力。这块要格外注意，国产化的这些工具非常吃资源，但是厂商往往不会明确，一开始问根本也得不到结论，他们只会建议最高的配置。如果是云服务厂商还好，因为以服务形式提供的工具不需要用户准备资源，但是部署形式的工具需要，很坑。

另外，一定要在申请资源之前跟数据库厂商不同团队的人确定好各自需要的资源量（非常重要！！！），他们没有一个统一的核算模型和归口人，用户自己需要有这么一个负责人。假设数据库本身的存储量是500G，目标端磁盘大小应该是：数据量500G*备份3份+当前正在备份1份=2T。这是基础的，但是因为迁移对实时性要求较高，所以申请了厂商的一个同步工具，该工具通过binlog日志重放数据库操作同步数据，源端binlog保留3天（binlog保留也会有大量文件，需要占用存储空间，但是保留时间太短可能会导致同步缺失，所以需要综合权衡），日志重放会重放所有的数据库操作（增删改查），所以会产生非常多的归档文件，这个文件不能随便清理，因为备份还原和主从同步都需要归档文件。由于并发事务太多，500G的数据一天的归档文件就达到300G左右，所以实际上一天的备份数据应该是500+300=800G，备份保留3天总计3.2T。数据库有个log日志文件记录运行情况和报错信息，默认保留30天，后来也是非常大的一个数据量，所以要么修改log记录天数，要么预留出30天的日志存放空间（最高到了500G左右）。HG还有一个很特殊的wal日志存放机制，记录DDL操作，当事务并发很大的时候这个日志也会快速增长，甚至一天能达到300G。一般主库数据同步到备库，数据落盘完成归档，会自动清理，所以理论上是需要保留至少一天的，但是如果出现备份异常，这个就一直不会清理，并且一直上涨。

综上，如果按照最理想的预期准备磁盘，那应该至少是3.2T+500G+300G=4T，已经是500G数据量的8倍，也就是说得按照数据量的8倍去准备磁盘。这还是完全没有预留的情况下，一旦出现异常，由于磁盘空间不够会出现数据库宕机等问题，实际上在过程中确实由于空间不够经常宕机，为了腾出空间把备份策略临时改成了1天，数据库log日志保留改成了7天，而且做了多个任务自动清理工具日志，把磁盘空间使用率稳定在了70-80%（最好是在一开始就预留足够的量，但是这很难预估好）。

先写到这里吧，方案和具体实施整理完再说。信息调研阶段需要输出数据库调研信息表，另外还需要数据库账号权限划分，网络安全规划等，这个在本项目中是另外的业务研发负责，不赘述。