风险控制方面考虑，例如白名单灰度迁移，回退方案等？
迁移过程中风险必须是可控的，由于是对于重要在线业务系统，一方面要确保业务系统尽可能短暂的影响，又要确保出现问题能够快速应对或者回退，该问题难点在于涉及数据库的切换，如果只涉及应用，那么可以通过灰度发布实现，出现问题也可以及时回退，而数据库的迁移是否可以借鉴类似的思路...显示全部
查看其它 1 个回答yata52的回答
目前我们接触到的国产数据库厂商暂时还做不到同时双向同步，即同一个表内的数据Oracle的变更向国产写，同时国产的变更向Oracle写。但是目前都实现了单向同步， Oracle的变更向国产写没问题， 切换之后国产的变更向Oracle回写也没有问题。针对快速回切，实践中我们会用这两种方式：
1、针对核心系统，切换后开启反向实时同步。上线前准备好回切方案，数据库部分主要是涉及序列的变更和数据校验脚本。数据库切换之后立刻开启反向回退，保障国产数据库内的变更可以准实时的写回原Oracle数据库。由于中间件切换异构数据库的数据源需要重启，所以切换后老应用的中间件数据源不调整，仅从F5中摘掉，需要回切时候完成数据库切换动作后直接把老应用挂回F5。
2、针对可自行稽核并补录数据的系统，我们是直接在新环境搭建新库并按照业务团队的要求导入某一时间的数据，业务切换后数据库层不提供数据实时同步服务，直接将Oracle数据库的表空间设为只读避免流量没有切干净。