Toggle Navigation
首页
活动
线上分享
线下沙龙
XCOPS大会
DAMS峰会
原创风采
企业专栏
专家专栏
年度MVP
企业直聘
下载
关于我们
社群介绍
社群架构
顾问委员会
热门文章
人肉运维100次后,年底出了P0级故障……
2023-11-16
关于国产数据库我不得不说
2023-08-05
分库分表,可能真的要退出历史舞台了!
2023-01-30
京东科技全链路故障诊断智能运维实践
2023-05-08
较ClickHouse降低50%成本,湖仓一体在B站的演进
2023-04-19
活动预告
即将开始
2024 DAMS 中国数据智能管理峰会 -上海站
时间:2024-11-22
形式:线下活动
即将开始
2024 XCOPS 智能运维管理人年会 -广州站
时间:2024-05-24
形式:线下活动
即将开始
直播预告 | 聚焦监控、可观测性、故障管理、高可用体系的运维变革实践
时间:2024-05-08
形式:线上分享
即将开始
无线优化技术专场丨得物技术沙龙
时间:2024-05-26
形式:线下沙龙
已结束
DBA从入门到实践
时间:2024-03-27
形式:线上分享
已结束
立即报名!OceanBase数据库城市行-粤港澳站 盛大开启!
时间:2024-03-20
形式:线下活动
已结束
2024首场沙龙|上海 · 得物技术沙龙-「稳定生产」专场报名开启!
时间:2024-03-10
形式:线上分享
已结束
攻坚关键业务系统——OceanBase金融行业交流会
时间:2024-02-27
形式:线下活动
已结束
官宣|硬核阵容曝光!PolarDB开发者大会全议程公布
时间:2024-01-17
形式:线下&线上大会
已结束
百度数据中台技术沙龙——探索AI时代的数据中台
时间:2024-01-13
形式:线上分享
已结束
中国MySQL生态年会盛大开启!
时间:2024-01-05
形式:线下沙龙
已结束
【deeplus线上分享342期】OUIC协议详解: 特性、适用场景及落地实践
时间:2023-12-20
形式:线上分享
已结束
立即报名 | 24位大咖齐聚,2023全球AI前沿科技大会完整议程公开
时间:2023-12-09
形式:线下活动
已结束
【deeplus线上分享341期】货拉拉微服务架构演进与数据库中间件、DevOps建设之路
时间:2023-12-08
形式:线上分享
已结束
Flink Forward Asia 2023 主会场
时间:2023-12-08
形式:线上分享
查看更多
迁移式升级的一点思考
杨建荣
2016-10-13 16:20:28
目前有一个很实际的需求,因为硬件老化严重,需要能够借助一次维护时机把数据库迁移到一台较好配置的机器上,避免潜在的硬件故障导致的业务停顿,也算防患于未然吧。
本来这个事情不是很紧急,但是因为硬件故障导致的问题防不胜防,踩过几次坑,就会有些经验教训,在这种情况下维持现状就是一个潜在的炸弹。
当前的硬件环境是Solaris,Oracle 10gR2 单实例,数据量在800G左右。我大体想了下,主要的目标有以下几个。
1.借助这次维护的时机,能够把数据库升级至11g
2.升级的过程需要尽可能保留一个较短的时间窗口,计划在2个小时以内完成
3.有较好的解决方案去演练整个过程,多次总结,提高迁移的效率,保证质量
4.有完善的回退计划,能够支持回退场景下业务平滑过渡
5.目前对于跨平台没有明确的要求,可以继续使用Solaris,也可以考虑跨平台,但是影响范围要小。
大体就是如上的要求,这是我的想法,也得我自己想办法来落实这些问题:)
有以下几种方式可以做,不过都是在评估和考虑。
exp的方案肯定是pass,这个数据量迁移2个小时是完全不可能。
expdp的方案2个小时也是无法达到,有两个瓶颈,一个是CPU使用的瓶颈,导出dump,导入dump得依赖于系统资源,二是主库还得备有额外的空间,三是网络的瓶颈,传输dump这个地方无法控制,而且因为硬件老化,网卡在大批量并发的情况下出现故障那就悲剧了。
OGG的方案可行性高,之前和几个兄弟讨论过,先在备库的基础上基于SCN做全量同步,再设定数据同步的频率从主库同步,这样第一次的初始化对于主库的压力大大降低。不过有个问题是服务器实在是年岁已高,不能完全保证在主库,备库折腾一番,服务器还依旧吃得消。当然这个也是借口啦,OGG也得花一些时间才能玩得转。高效,可控的基础是熟练掌握它。
使用XTTS的方案也不错,技术实现上肯定是妥妥的。这种方案的一个瓶颈还是在于网络的带宽,而且XTTS的方案实现在10g版本上还没有亲自尝试过,如果试水,还是有一些风险。
使用DBUA的方式来升级,也是一个不错的方案,先使用Data Guard切换,然后直接升级至11g,图形的方式或者是命令行的方式均可。这种方式的优点很明显,升级前的检查和准备足够充分,升级数据库的时候就会平滑许多,自己也这么参与过不少的案例。这种方案和数据量就没有太大的关系了,升级的本质就是升级数据字典,所以这部分的时间主要就花费在升级上。
还有一种方案自己也在琢磨中,那就是Data Guard+TTS,实现的思路大体是备库上创建一个11g同名的数据库,然后原来10g的数据库Failover变为主库,导出元数据,然后修改11g数据库的配置,导入元数据,这个过程中出了系统表空间外,数据表空间不动。这样就可以直接避免文件迁移带来的很毒瓶颈和限制。
这几种方案个人比较喜欢最后一种,先说维护窗口,如果免去了拷贝数据文件的时长,那么导出导入的过程就会很快,应该比手工/图形方式升级数据库还要快。如果保证能够反复演练,可以合理利用备库的闪回功能,failover之后闪回照样能够修改为物理备库正常应用日志,为了方便演练,可以拷贝一份数据的镜像,随时启用,这样10g,11g的库都可以正常运行。一旦出现灾难,直接把连接切到原来的主库端去即可。
关注
DBA
plus社群,了解更多技术干货文!