公司高可用性和升级的一些思考

简介: 1、LINUX AS 4.4 32BIT 10.2.0.1升级到LINUX AS 5.0 64BIT 10.2.0.1 升级的主要思想是使用RMAN OPEN状态下全备,然后加上归档日志文件进行恢复,最后使用脚本utlirp.sql和utlrp.sql来完成升级,使用热备的原因是可以节约大量的生产库停机时间,我们可以事先完成RESTORE,最后的任务就是RECOVER了。

1LINUX AS 4.4 32BIT 10.2.0.1升级到LINUX AS 5.0 64BIT 10.2.0.1

升级的主要思想是使用RMAN OPEN状态下全备,然后加上归档日志文件进行恢复,最后使用脚本utlirp.sqlutlrp.sql来完成升级,使用热备的原因是可以节约大量的生产库停机时间,我们可以事先完成RESTORE,最后的任务就是RECOVER了。

2、数据中心搬迁

 --1DB 搬迁

   我们可以使用DATA GUARD来进行SWITCH,主库变备库,备库变主库,这样是要事先做好准备建立好DATA GUARD,停机时间将会大量减少,需要做的只是进行切换。

 --2APP 搬迁

   APP搬迁只有把文件拷贝回来进行然后进行重建,需要咨询APP是否有类似DATAGUARD的功能,如果有也可以大量缩短停机时间。

3、容灾

 --1DB容灾

   使用DATA GUARD对数据文件进行保护,模式可以采用最大可用性和最大性能如果可以我们可以引入BROKER FSFO来自动进行故障切换需要咨询这个组建是否稳定。

   使用RAC在实例级别做容灾并且负载均衡,但是是否使用RAC根据升级后的服务器负载而定,如果确实一台服务器不能很好的支持,需要使用CLUSTER来进行负载均衡。

但是当业务量达到一定的程度后我们的数据库构架会成为如下的构架:

 

也就是RAC+DATA GUARD的构架方式

--2APP容灾

   需要咨询,APP 也有ORACLE APPLICATION SERVER DISASTER RECIVERY的功能,但是我们没有使用过。

4、存储

1、新建立数据库数据文件放到我们的磁盘阵列中去,分离I/O

并且磁盘阵列盘阵的性能比本机磁盘要好,并且可靠性强,其他

DB文件比如控制文件、日志文件、归档文件我们放到本地磁盘。

2、中间件的文件放到本地磁盘。

3、对于DB的物理备份和逻辑备份及APP备份我们可以专门从磁盘整列中划一部分作为备份区域。

4、对于核心业务系统做了RAC过后我们可以使用ASM+RAC的模式,但是为了提高性能需要使用专门的阵列(新购买),

   可以咨询下ASM是否稳定。

目录
打赏
0
0
0
0
91
分享
相关文章
|
10月前
|
Redis热升级秘诀:保证高可用性的技术方案
Redis热升级方案允许在不中断业务的情况下,实现数千级别Redis的无缝更新。通过构建Redis Shell程序保存数据库状态,封装动态连接库,以及在运行时加载新版本库,保持客户端连接,该方法确保了业务连续性和高可用性,且升级仅需几毫秒,显著提升了系统效率。
741 6
系统健康长期“三高”:实现高性能、高可用性和高稳定性的关键要素
大家想必都知道在人类健康领域,我们常常警惕“三高”带来的风险,三高是一个不健康的意思,而在数字化世界中,恰恰相反,系统的高性能、高可用性和高稳定性代表着系统的健康和卓越运行,是一个健康的概念。作为开发者怎么能让我们开发的系统保证长期“三高”,那么本文就来简单讨论一下如何让系统长期维持理想的“三高”标准,以及“三高”在实际业务场景中的真实性,并探索一下在技术负责人角色中使用“三高”来评价系统开发工作的可行性等内容,欢迎大家在评论区留言交流。
440 1
系统健康长期“三高”:实现高性能、高可用性和高稳定性的关键要素
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.2故障分体系
439 0
《云上业务稳定性保障实践白皮书》——二. 理论概念——2.2 故障
《云上业务稳定性保障实践白皮书》——二. 理论概念——2.2 故障
210 0
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.1故障发现
《云上业务稳定性保障实践白皮书》——三.故障管理体系——3.故障管理全流程——3.3.1故障发现
242 0
如何设计一个高可用的运营系统
概述 一个产品业务的发展总是离不开运营二字。随着业务快速的发展以及新业务的扩充,运营需求越来越大,并且很多时候需要追热点,因此在有限的资源下,如何做到快速、准确、灵活、稳定的满足日趋增多的运营需求,成了个问题。
4255 0
如何在大促中做好系统高可用
本文就围绕大促来谈谈,如何在非预期的情况下,始终保持我们的系统工作在最优解?
如何在大促中做好系统高可用
高可用互联网系统稳定性建设实践指南
自己以及带领团队曾经负责较多不同的互联网服务系统,如几十万应用数&亿级流量的云计算平台、年营收将近千亿的广告系统、亿级用户千万级日活的用户系统、亿级交易额的交易系统、算法在线离线工程系统等相关系统或子系统,整体而言无重大故障,达到定级故障数也很少,线上稳定性保障在一个不错的水位上。阶段性总结下我自己从团队技术负责人视角做好稳定性建设的实践性思考和简要思路,为感兴趣的技术同学提供一个实践指南。 我的团队稳定性建设思路包括了3大技术要素:良好的系统架构和实现、完备的团队研发运维流程机制、技术同学良好意识和能力,以及1个业务要素:良好的研发项目管理。
高可用互联网系统稳定性建设实践指南
3+1保障:高可用系统稳定性是如何炼成的?
影响系统稳定性的架构设计有哪些?一个可持续保障的研发运维流程机制是怎样的?如何培养团队技术人员的意识和能力?本文作者以团队技术负责人的视角,从三大技术要素和一个业务要素,分享在稳定性建设上的实践性思考和简要思路。希望对同学们有所启发。
3+1保障:高可用系统稳定性是如何炼成的?
云原生下,如何保障业务系统的高可用性?
本文章由阿里云高可用产品的产品经理牛兔在阿里云社群直播中,从云原生角度来讲解如何保障业务系统的高可用性。
1917 0
云原生下,如何保障业务系统的高可用性?