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%（最好是在一开始就预留充足的量，但是这很难预估好）。
先写到这里吧，方案和详细实施整理完再说。信息调研阶段需要输出数据库调研信息表，别的还需要数据库账号权限分别，网络安全规划等，这个在本项目中是别的的业务研发负责，不赘述。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。