一种迁移式升级的方案考虑

目前遇到了一个问题,目前的是一主两备的环境,但是主库,备库中的存储空间都不足。而且硬件环境相对要老旧一些。想扩容难,系统版本老旧想升级也难。
数据库是基于10gR2,有异地灾备。但是因为10gR2的dataguard没有灾备的感觉,其实感觉和一个主库没有什么明显的差别。而且一旦发生问题,切换以后,硬件的限制瓶颈还是解决不了,所以化被动为主动,可以提前预警,提前规划和考虑。
现在是一主两备,但是备库目前的情况不容乐观,所以需要扩容一下,升级操作系统版本,目前为6U5,重新规划磁盘分区,在新分区中采用了SSD来提高性能。

所以我们需要一台配置要好一些的机器来顶过来,接替目前的系统的工作。配置完成之后就是下面的图形所示。
当然因为重做系统,需要重新搭建第二个备库,这个时候可以根据第1个备库来复制生成第二个备库。

所以需要做一些前期工作,保证这个时间要尽可能短。开始迁移式升级的时候,先做一个switchover,即主从切换。

这个时候备库1对于切换之后的库来说是不可用状态,但是对于原来的主库还是有用的。稍后解释。
switchover之后开始升级切换后的主库至11.2.0.4.0

这个过程就是没有任何的灾备情况,升级成功之后就需要重构备库,这里有一段的空白。
升级完成之后,开始重构备库,那么这个时候,可以分批分步来构建,首先通过online的方式构建第一个备库,然后基于第一个备库来构建第二个备库。
完成之后的示意图如下:

而一旦升级失败,需要有回退方案,原来的主库立即做failover,这个时候备库2是不可用状态,需要重新同步备库1

以上大体就是这个方案的一些思路,里面还是有很多的细节需要考虑,目前的停机维护时间比较短,所以也在思考有没有更好的方法来做。

时间: 2024-07-30 12:11:51

一种迁移式升级的方案考虑的相关文章

迁移式升级的测试(二)

在之前写的一篇博文中,自己是打算对一台数据库使用Data Guard+TTS的方式来完成数据迁移和升级的工作,整体的思路如下. 备库Failover之后,导出元数据,然后同一台服务器上的11g的数据库中导入元数据,这样就避免了传输文件的时间消耗.从而达到快速迁移升级的目的. 具体的操作步骤如下所示: 1.在备库端需要开启闪回 这个也是为了能够在迁移失败的情况下,能够迅速回退,马上重构主备库的环境. 2.在开启闪回数据库之后,记录一下SCN的信息,留作后面备用.    select current

迁移式升级的一点思考

目前有一个很实际的需求,因为硬件老化严重,需要能够借助一次维护时机把数据库迁移到一台较好配置的机器上,避免潜在的硬件故障导致的业务停顿,也算防患于未然吧. 本来这个事情不是很紧急,但是因为硬件故障导致的问题防不胜防,踩过几次坑,就会有些经验教训,在这种情况下维持现状就是一个潜在的炸弹. 当前的硬件环境是Solaris,Oracle 10gR2 单实例,数据量在800G左右.我大体想了下,主要的目标有以下几个.     1.借助这次维护的时机,能够把数据库升级至11g     2.升级的过程需要尽

迁移式升级的测试(三)

还是继续昨天的任务,今天会把剩下的工作都做完,给个交代. 昨天完成了Data Guard切换,然后Failover备库,导出了元数据信息作为TTS的准备,亮点就在于导入的部分.无需挪动数据文件,这是补充数据字典信息即可. 这个工作的一个重点内容就是如何保证数据字典信息的完整性. 在目标环境11g中需要创建相应的用户,这一点还是很有技巧的.如果采用impdp的形式直接导入用户,这样不妥,因为我们有设置profile,有临时表空间,默认表空间的信息. 比如下面的用户创建语句:    CREATE U

测试环境的迁移式升级和数据整合

很多时候,大家工作中都会有一种被动的思维,那就是能不动就不动,从求稳的角度来看无可厚非,但是从风险的角度来说,还是有待商榷的.如果存在风险,还保持原样很可能就是一个不定时炸弹. 这不手头有一套环境,按照以前的标准是根本入不了我的法眼的,但是因为是测试环境,小问题比较多,存在容灾风险,但是这么多年一直这样,也就默然接受了. 这套环境硬件配置很低,基本上和我的笔记本配置差不多,可能还略差一些,在上面跑着3个数据库实例,其中一个是11g的,2个是10g的.两个10g的数据库实例数据量都不大,几十G而已

迁移式升级的测试

之前写了一篇文章分析了目前存在的一个问题和改进思路. 当前的硬件环境是Solaris,Oracle 10gR2 单实例,数据量在800G左右.想迁移到另外一台服务器上.大体的需求如下:     1.借助这次维护的时机,能够把数据库升级至11g     2.升级的过程需要尽可能保留一个较短的时间窗口,计划在2个小时以内完成     3.有较好的解决方案去演练整个过程,多次总结,提高迁移的效率,保证质量     4.有完善的回退计划,能够支持回退场景下业务平滑过渡     5.目前对于跨平台没有明确

阿里推出业界首个非侵入式热修复方案Sophix,颠覆移动端传统发版更新流程!

阿里巴巴对Android热修复技术已经进行了长达多年的探索. 最开始,是手淘基于Xposed进行了改进,产生了针对Android Dalvik虚拟机运行时的Java Method Hook技术,Dexposed.但这个方案由于对底层Dalvik结构过于依赖,最终无法继续兼容Android5.0以后ART虚拟机,因此作罢. 后来支付宝提出了新的热修复方案Andfix.Andfix同样是一种底层结构替换的方案,也达到了运行时生效即时修复的效果,并且重要的是,做到了Dalvik和ART环境的全版本兼容

业界首个非侵入式热修复方案Sophix重磅推出,颠覆移动端传统更新流程!

横空出世 阿里巴巴对Android热修复技术已经进行了长达多年的探索. 最开始,是手淘基于Xposed进行了改进,产生了针对Android Dalvik虚拟机运行时的Java Method Hook技术,Dexposed.但这个方案由于对底层Dalvik结构过于依赖,最终无法继续兼容Android5.0以后ART虚拟机,因此作罢. 后来支付宝提出了新的热修复方案Andfix.Andfix同样是一种底层结构替换的方案,也达到了运行时生效即时修复的效果,并且重要的是,做到了Dalvik和ART环境的

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发

Scrum 求助编辑百科名片:http://baike.baidu.com/view/1528674.htm    敏捷软件开发模型--SCRUM Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发.包括了一系列实践和预定义角色的过程骨架.Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员. 目录 简介 Scrum创始人简介 历史 Scrum的特性 Scrum中的角色 Scrum会议 文档 展开 简介 S

Openstack 使用migrate进行数据库升级实现方案详细介绍_OpenStack

Openstack 使用migrate进行数据库升级实现方案详细介绍 OpenStack中随着版本的切换,新版本加入一些数据库表或者增加字段等是必然的事情,如何比较容易的进行这些数据库升级的适配和管理,这里就要用到oslo_db中的migrate了,这里以为M版本的heat为例,讲解一下migrate管理db的原理. 我们使用migrate需要用到的主要包含以下两部分:1.versions里面的为版本号+数据库适配脚本:2.migrate.cfg为migrate需要用到的配置文件,两部分的命名是