当数据库节店之间出现较多gc等待事件的时候,表现慢的不光是跨节点访问的那些表,数据库的整体表现都是受影响的。因此在extend rac架构下即使一边是纯写入操作,另一个中心纯粹的读操作,如果造成的gc很高的话,仍然是会有数
通常都会有的,例如应用集群里的日志文件的共享,业务文件的共享,解决方案也比较多。有的企业有专门的文件传输平台或者业务总线,可以提供应用节点间的文件互通,除此之外,还可以考虑使用nas进行共享,但是性能相对较差点,GPFS是
发表一下个人见解,数据库同步和存储同步虽然说都是双中心复制的可用方案,但是从技术稳定性来说,存储的同步复制以及存储双活相比数据库的复制更为成熟,只是存储的复制在切换时,切换操作要复杂的多,可能导致RTO时间变得很长
个人认为只要应用支持短连接或者自动重连,数据库的RAC方案在连续性方面相对优于HA,HA切换必然有数据库的关闭和启动过程,特别是对于体量比较大的数据库,重启一次可能时间会更长
如果是采用拉伸集群extend rac架构,双中心数据库节店间的心跳网络质量是关键,心跳网的带宽以及稳定性必须要得到强保证。可以考虑2-3个运营商线路的裸光纤线路绑定方案,并且可以配合波分设备提高带宽,服务器端也可以做好
个人感觉一套还是两套运行,主要需要考虑的还是网络质量,如果网络质量有保证,单套扩展的架构属于双中心的紧耦合架构,架构上比较简单清晰,双中心间的业务分发策略、业务间的访问关系配置也相对比较简单,但是单集群的风险在于
双活带来连续性提升的同时,往往因为需要对远端进行数据复制造成一定的性能损耗,这个性能损耗视不同的复制方式会有区别,如果采用异步模式则基本可以忽略。对于重要的应用系统,需要把数据安全性和系统连续性摆在第一位的,宁
也要区分当生产库不可用的原因,如果是生产库非正常宕机并且无法拉起的时候,则需要进行数据库的failover操作强制将备库设置为读写库。此时如果应用是基于dns配置链接串的,则需要修改dns将域名指向备库应用才能连接上,如果
应该来说现在市场上能提供存储双活解决方案的厂商很多,从华为,HDS,EMC、3par等等各大存储厂商的主流存储设备到vplex,svc等虚拟化存储网关,都可以提供双活存储解决方案。
应该是说有双中心应急和灾备需求的应用,都可以考虑
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30