数据库双活,如何解决几十公里延时带来的性能问题?

参与45

4同行回答

anikikonganikikong课题专家组数据库运维工程师中国民生银行
几十公里的延时主要表现在两方面,一个是存储双写延迟,一个是节点通信延迟。从存储延时来说首先要做到本地读。这个在GPFS文件系统里是可以做到的。其次是增大缓存,减少同步写的次数。对于数据库里的大对象,最好使用inline的方式放在常规表空间里,或者存放在开启了文件缓存的表...显示全部

几十公里的延时主要表现在两方面,一个是存储双写延迟,一个是节点通信延迟。
从存储延时来说首先要做到本地读。这个在GPFS文件系统里是可以做到的。其次是增大缓存,减少同步写的次数。对于数据库里的大对象,最好使用inline的方式放在常规表空间里,或者存放在开启了文件缓存的表空间里。对于数据库日志,一定要设置足够的日志缓冲池,避免因为缓冲池不够发生的同步写。
在通信的延迟上,我们需要做到的是尽量减少通信。所以要想办法解决热点数据问题。同时能够本地访问和缓冲的都要想办法实现。例如推荐采用客户端偏好链接。基于current member来组织表和数据等等。

收起
银行 · 2017-09-15
浏览4796
  • 有个问题,由于CF节点只有一个,对于写来说,必然存在两个站点的DB2 MEMBER都同时需要通过RDMA访问CF节点GBP,本地来说,问题不存在,跨站点RDMA访问的话,这个通信耗时和性能是否需要重点关注?
    2017-09-15
  • 你说的非常正确,跨站点的member和CF通信需求是双活环境调优的关键。所以这个就是重点关注的对象,要减少这种交互。数据库提供了mon_get_cf等相关表函数能够抓取CF的功能和耗时,进而分析是什么操作最慢,能不能减少或者调整。
    2017-09-15
liuhefromoracleliuhefromoracle数据库管理员Oracle
我从Oracle数据库层RAC说一下吧,个人比较喜欢用ASM,用ASM可以解决一部分性能问题,之所以说一部分是因为ASM也只能解决"读"的问题;由于距离产生的延迟,那么最好的办法就是不缩短距离,这个好像是废话,但是对于Oracle ASM的 redundancy来说其实是可以做到的,比如创建Oracle ASM的磁...显示全部

我从Oracle数据库层RAC说一下吧,个人比较喜欢用ASM,用ASM可以解决一部分性能问题,之所以说一部分是因为ASM也只能解决"读"的问题;

由于距离产生的延迟,那么最好的办法就是不缩短距离,这个好像是废话,但是对于Oracle ASM的 redundancy来说其实是可以做到的,比如创建Oracle ASM的磁盘组的时候选择的是Normal redundancy的方式,那么磁盘组就会至少有2个failure group ,而我们可以把2个failure group里的物理盘手工的划分到不同的物理位置,一般双活都有2个机房,那么一个failure group里放一个机房的磁盘,另外一个fialure group里放置另外一个机房的磁盘,这样双活也就实现了,但是随即而来的问题就是物理距离的增加和光信号的衰减和传输的性能降低,Oracle ASM考虑到提升一部分功能,在参数里提供了asm_preferred_read_failure_groups这个参数,也就是说当做物理读的时候每一个机房里的节点(RAC节点)都可以配置自己优先读的“机房” ,这样可以保证“读”不受“距离”的影响,但是“写” 是必须要在双节点都完成的,所以对于ASM来说对于“写”也没有特别好的办法解决距离产生的延迟。 当然这个时候如果RAC的节点的使用和划分以及应用层的布置是都慎重考虑的,否则有可能会出现本来业务应该登陆节点1 而因为配置问题缺被随机分到了节点2,那这个时候反而适得其反。

收起
IT咨询服务 · 2017-09-15
浏览4631
renou2012renou2012数据库管理员KE
数据双活和网络延迟的性能问题是一个很难平衡的问题常见的方案是采用专线连接,更快的服务器,优化的网络基础设施和应用,而且几十公里的距离只能算同城,对于数据双活而言并不是很大的问题,当然也可以选择较近的距离作为数据中心位置...显示全部

数据双活和网络延迟的性能问题是一个很难平衡的问题
常见的方案是采用专线连接,更快的服务器,优化的网络基础设施和应用,而且几十公里的距离只能算同城,对于数据双活而言并不是很大的问题,当然也可以选择较近的距离作为数据中心位置

收起
金融其它 · 2017-09-15
浏览4825
匿名用户匿名用户
数据写到主服务器,commit时复制到从服务器。复制完毕commit完成。只有commit有性能问题,是批量操作性质,可以把通信开销降到最低。但是如果有锁,锁的传递需要时间。复制时如果从服务器失效,操作应该依然成功,要在主服务器记录从服务器遗漏事务。待从服务器复活,回复遗漏事务。如...显示全部

数据写到主服务器,commit时复制到从服务器。复制完毕commit完成。
只有commit有性能问题,是批量操作性质,可以把通信开销降到最低。
但是如果有锁,锁的传递需要时间。
复制时如果从服务器失效,操作应该依然成功,要在主服务器记录从服务器遗漏事务。待从服务器复活,回复遗漏事务。
如果写几千条记录到主服务器,这期间没有复制开销。在commit时复制,产生一个批量传输,开销是很小的。
但是如果主机从机都在录入数据,他们之间是否有重复记录是不易检测的。一个办法是commit时检测,重复数据导致commit失败。如果在恢复遗漏事务时发生重复记录啦,唯一的办法是抛弃重复记录。
所以主从系统需要阶段性一致性检查,如果有不一致数据,以时间戳最新的为准。

收起
银行 · 2017-09-15
浏览4388

提问者

haozhangsir
系统工程师银华
擅长领域: 存储灾备双活

问题来自

相关问题

相关文章

问题状态

  • 发布时间:2017-09-15
  • 关注会员:5 人
  • 问题浏览:8521
  • 最近回答:2017-09-15
  • X社区推广