|
答这个问题，首先我们要理解去 Oracle 架构改造的本质是什么？去 Oracle 架构改造的本质其一是让系统架构具备在线更换数据库的能力，无论去 Oracle 的目标库是 MySQL，或是其他的关系型数据库，最终都是要解决这样一个问题。
在线更换数据库到底难在哪里，会遇到哪些问题呢？
1. 如何无感知的实时动态数据的迁移？
首先数据库作为交易型系统最核心的组件没有之一，这一点对于数据库的重要性评价一点都不夸张。当前大部分知名的网站和系统都是 7x24 小时对外提供服务，数据库也是 7*24 小时无时不刻处理着大量的读写服务，要实现去Oracle 就意味着你要在一个 Oracle 库还在对外提供服务的时候，在某个时间点让一个 MySQL 库快速替换掉 Oracle 库，并平稳的接管 Oracle 的所有服务。
不同于无状态的系统组件切换把流量切走即完成切换工作，而数据库作为有状态的系统组件，如何设计一套从应用改造、到数据同步、再到数据库流量切换的稳妥去 Oracle 方案，可以非常谨慎的把一个正在对外提供服务，数据处在实时变化状态的 Oracle 库上的数据无缝的方式迁移至 MySQL 中。
2. 如何管理和协调好高频迭代的去 Oracle 改造和功能改造？
其次去Oracle 架构改造的主体工作是对应用层代码的重构，特别对 DAO（数据访问层）的重构，对于某些复杂的系统来说，重构的时间会持续数月甚至更久。在这段漫长的去Oracle 改造时间窗口里，不但 Oracle 库的数据在动态发生变化，对于一个处在高速迭代中的网站和系统来说，应用的功能代码也在不断发生变化。如果 A 团队在为应用做去 Oracle架构改造，而这个期间 B 团队在不断的给应用开发新的功能，如何进行去 Oracle 的工作拆分可以有效的管理和协调好两个开发团队的编码和上线节奏呢。
3. 如何稳妥落地数据库流量的在线切换？
当某个库的应用去Oracle 改造完成并上线后，会实施生产环境 Oracle 的流量切换到 MySQL 上。在这个切换过程中，如何确保 Oracle 上的最后一笔事务提交成功，并同步到 MySQL 后完成数据一致性校验，且针对这个 Oracle
（编辑：信阳站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
