在云原生时代，企业纷纷踏上技术革新的征途，其中一项关键举措便是从传统Oracle数据库向云原生兼容的MySQL迁移。这一转变虽充满机遇，但也伴随着一系列挑战。本文将聚焦于云原生架构中去Oracle的五大痛点，并分享实战经验与解决方案，助你平稳过渡，迈向云原生的未来。
1. 多应用共库共表问题
在微服务架构中，应用和服务往往需要各自独立的数据库资源来保证数据隔离和安全性。然而，在迁移前，可能存在多个应用共享同一数据库甚至同一表的情况，这不仅增加了数据访问的复杂性，还可能引发数据冲突和安全漏洞。
解决方案：
静态SQL扫描：使用工具自动扫描应用的代码库和数据库配置文件，识别和分离应用的数据库依赖。
动态SQL监控：部署监控工具，实时追踪和记录动态SQL查询，确保所有应用都有独立的数据库资源。
2. ETL数据抽取
企业数据仓库依赖ETL流程从各个应用数据库中抽取数据进行分析。Oracle数据库向云原生数据库的迁移需要重新评估和调整ETL策略。
解决方案：
设立数据资产管理机制，明确数据库迁移计划，包括结构变更、主键调整，以及ETL流程的适时更新，确保数据流的连续性和准确性。配套相应的数据资产管理评审通知机制，例如应用数据库如何迁移(是否修改表结构，主键是否发生变化等)，以及什么时候迁移，ETL什么时候从新库抽取数据等等
3. 主键管理
Oracle数据库能够支持极大规模的单表数据存储，而MySQL等云原生数据库在单表容量上有一定的限制。单表可能超过3千万条跑起来就已经吃力了，因此往往面临分库分表。在迁移过程中，需要解决主键冲突和数据一致性问题，例如：分库分表后的MySQL表新增数据的主键与从orac1e迁移过来主键(原sequence)冲突的问题 ，
解决方案：
引入应用层生成唯一ID，而非依赖数据库自增。可以采用远程服务或本地算法（如雪花算法）生成全局唯一ID，保持自增长原则以优化索引性能。
注意算法细节，如雪花算法的时间戳部分可能导致未来的主键长度增加，需提前规划。例如：如果使用雪花算法，需要关注雪花算法生成ID的长度，如果时间是雪花算法生成的一个因子，可能在将来的某个时间点，主键长度会加一，导致数据插入不到表中
4. 数据迁移与一致性
数据迁移不仅仅是将数据从Oracle复制到云原生数据库，还需要处理实时数据的更新，确保数据的一致性。
解决方案：
如果业务允许，暂停服务进行数据迁移，简化过程。否则，实施双读双写策略，确保数据在两个数据库之间实时同步。
5. 应用双读与双写
双读双写是确保数据一致性的重要策略，但实现起来较为复杂，尤其是在SQL语句转换和数据验证方面。
解决方案：
利用工具进行高效的双读双写对比验证，减少人工验证的工作量，提高数据质量和迁移效率。
双读相对简单，通过异步读取两个数据库并比较结果；双写则需确保数据在两个数据库中的实时一致性，可能需要定制化的数据同步逻辑。
在云原生转型的道路上，“去O”不仅仅是技术上的迁移，更是企业IT架构和运维策略的全面升级。通过精心规划和实施上述策略，企业可以顺利过渡到云原生数据库，享受更高的灵活性、扩展性和成本效益。
