国产数据库选型后,如涉及对已有系统改造可能需要进行历史数据的迁移,如从原有数据库将数据迁移到国产数据库,一般通过什么样的技术方案能使迁移对业务的影响最小化?
数据的迁移一般根据业务影响要求、数据量大小方面来选择相关的迁移方案。
一般国产数据库都会带有相关的迁移工具,或者一些开源的迁移工具。通过迁移工具迁移是十分简单方便的。通常的迁移工具都是有全量迁移和增量同步的,然后再来一个全量校验。例如OceanBase的OMS工具就支持全量迁移、增量同步、全量校验流程,这些都是在一个迁移任务里,图形化操作是非常方便的。
迁移方案简单的一句话是能够停业的情况下,通过工具一次性迁移,减少增量数据导致的数据不准确。由于停业窗口有限,不能停业的就通过迁移工具全量迁移+增量同步+全量校验流程。
注意事项:但要清楚每种迁移工具都是有局限性的,例如存储过程、触发器、无主键表、外键这些迁移要多加小心,有些工具可能不支持,需要充分测试。数据的校验不只要工具的校验,还要针对重要业务表进行业务数据的校验(例如sum(余额))。
这种迁移一般有三种方式:
1 全量离线迁移:需要停业务来保障一致性,建议设置好并发度,加快速度。例如分区表的多个分区都应该搞起并发来。
2 增量离线迁移:这种需要结合业务属性,找到不再修改的历史数据先行迁移,然后在增量迁移剩下的数据。操作较为复杂,需要业务支持。
3 同步复制迁移:这种依赖异构数据库之间有产品做数据同步,那么这种方式最快,最终切换一下就好。
首先应该评估 数据库 的兼容性,如果没有解决主要的兼容性问题,即使完成了数据迁移也会影响实际使用。
在评估兼容性的同时可以考虑迁移方案,数据量小的环境使用备份恢复的方式可以完成;数据量大的一般借助厂商提供的数据迁移工具实现迁移
可以用OceanBase 的OMA 迁移评估工具先跑一遍,看下代码影响的程度,有一些老系统可能需要涉及到部份代码的改造比如像Proc*C 之类的,可以根据跑下来的迁移评估报告来进行迁移评估以及迁移策略的制定
收起在将历史数据从原有数据库迁移到国产数据库时,为了使迁移对业务的影响最小化,可以考虑以下技术方案:
无论采用哪种技术方案,都需要在迁移前进行充分的测试和验证,以确保数据的准确性和完整性,并且需要对业务进行充分的规划和准备,以最小化业务的影响。此外,还需要注意数据安全和隐私保护,确保数据不会被泄露或丢失。