全库数据迁移,咨询个靠谱的解决方案。

2020-04-02 16:00:25 +08:00
 xiaoleis

将 A 数据库的数据全部迁移至 B 数据库:

  1. 均为 Oracle 数据库
  2. B 库表结构的字段精度、唯一约束、主键都可能有改动。 表名一致。
  3. 涉及大约四千张表。
2691 次点击
所在节点    数据库
35 条回复
zlowly
2020-04-02 22:50:21 +08:00
17 楼是比较稳妥的方案。
特点是业务系统停机时间比较短,特别是用 OGG 来追平数据,可以较好的适应对你需求里的 B 表结构可能发生变更这个特殊点。
hantsy
2020-04-02 22:55:42 +08:00
找 Oracle 吧,有 Oracle 数据库,应该有服务可以打折吧。
yiyi11
2020-04-03 05:22:04 +08:00
17 楼方案加一
公认标准方案。
我试过几 T 的数据量都是这样迁移,不过只有几十张表,单表高达 21 亿条数据,依然很稳。
xiaoleis
2020-04-03 09:03:58 +08:00
@slyang5
@saximoer 计划的停机时间是 一晚上, 晚八点到早八点
xiaoleis
2020-04-03 09:06:53 +08:00
@zlowly
@yiyi11 现在统计的结果是有 700 多张表发生了结构变更。如果因为结构变更,数据冲突无法插入,就不好办了。
xiaoleis
2020-04-03 09:08:10 +08:00
@hantsy 要是有经费。 ^-----^
boshok
2020-04-03 09:22:44 +08:00
@psirnull 可以
realpg
2020-04-03 11:15:19 +08:00
都选 oracle 了还能没有经费……
realpg
2020-04-03 11:16:55 +08:00
另外,也不是不能没有经费。
如果没有经费,这个迁移项目最值钱的精髓就是方案设计了……
方案做万无一失,怎么也值几十 K
会做的人不可能让你白嫖或者打折
LightLolo
2020-04-03 12:11:07 +08:00
可以 dump 分表分块导出
可以 OGG 同步搞
可以用 kettle 做数据抽取
slyang5
2020-04-03 17:12:35 +08:00
@xiaoleis 你不是都 停机导数据了么? 会什么会有结构变更???
zlowly
2020-04-05 03:27:11 +08:00
@xiaoleis 对于如果因为结构变更,数据冲突无法插入,最坏的结果,也就是 B 库不能用而已,这个时候还没切换,A 库还是正常提供业务的,顶多就是浪费了时间而已,慢慢再梳理调整 B 库数据结构罢了。
zlowly
2020-04-05 03:56:58 +08:00
大约的流程就是
0 、准备好 B 库以及变更数据结构脚本,A 、B 库上安装 OGG 并做好相关配置
1 、A 上启动 OGG 抽取投递进程
2 、A 库上导出数据,传输到 B 库导入
3 、B 库上运行变更数据结构脚本
4 、B 库上启动 OGG 应用进程
5 、停止业务应用,等待 A 、B 库上 OGG 完成所有抽取投递应用
6 、更改业务数据源到 B 库
7 、启动业务应用
可以看到这种方案只在最后三步才需要停顿业务,前面实施时间完全可以很充裕(特别是 2T 数据量的导入导出一个周末,稍微不顺利还真不一定搞得定),所以真正对业务影响比较短。这些过程,应该先进行演练,最后三步用业务测试环境来进行最后验证。如果 AB 数据结构变化过大,单靠 OGG 也不一定能适应,就还需要其它方案来弥补。
xiaoleis
2020-04-07 16:04:04 +08:00
@zlowly 感谢回复。已经在做技术方案, 实际的情况可能比描述的还要复杂。
065535
2020-04-18 19:18:49 +08:00
阿里的 DTS,很棒的迁移工具

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/658695

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX