4个节点的RAC的优缺点问题

alantany

不分业务的话，3个，通常足矣。
我们这面的的单业务用的是6-nodes......性能很不好。

jj_kin

原帖由 anycall2010 于 2009-6-6 10:13 发表


上述问题，我也听一个IBM高级顾问提到过。我现在对多节点有几个疑问：
1.从管理角度来说：节点越多，DLM要协调各个节点资源竞争就越困难，这样会严重影响集群的性能。这点好像和ORACLE曾经吹嘘的RAC的LB功能，似乎有些背离？
2.从维护角度来讲：节点越多，那么节点出问题的几率就越大，那么在维护方面，就变得越困难？
3.从RAC本质原理来讲：节点越多，RAC实现cache fusion的时候，会不会出现更多的诸如：并发读，读并发写，写并发写等等的问题？而且多个节点实现的是share-dsk模式，写入磁盘的时候，会不会产生磁盘争用问题？

Re：
1、LB是在cluster外围用来提高系统的吞吐和节点利用率，跟内部节点的资源争用是两码事，怎么谈背离？

2、cluster里因为多节点肯定维护要变复杂，不管cluster是share什么都是这样的趋势，无非是谁做的更好的事情

3、RAC是share disk，但是某个时间点上，某块数据最终是有一个节点负责写入磁盘的，不是多个节点同时写同一个数据块；应此，所谓磁盘争用问题如果在rac下存在，那么在单instance下也会存在； 同时处理事务的节点增多必然带来磁盘IO的增长，所以要解决读写磁盘的IO快慢，而不是怪安装了rac为啥读写磁盘变多了。

yueyangflash

业务分割的话，用单台的不好吗？
毕竟RAC也蛮贵的！
不理解做业务分割为什么还用RAC！

hiber_zhu

做单台就没容灾了

eagle3250

有个master node,不会随着节点增加而导致竞争大量增加,最多就是3-way

wolfop

能折腾了，业界原来有过4节点的OLTP实验，在关键系统，当然是以失败而告终了。
用来做DSS也是没办法的办法。

wolfop

原帖由 tolywang 于 2009-6-6 08:42 发表
目前只用过 3 节点的， 原来看IBM的一份文档， 说由于Oracle是shared-disk 模式的Cluster,  节点越多处理其间的通信以及Lock 处理上面就没有shared-nothing 的 DB2 Cluster ( 当然DB2 Shared-nothing 也只是逻辑上的)来得好 。

DB2的share nothing只适合用在DSS，做OLTP一塌糊涂，比RAC还不如。本质上和多节点RAC一样的问题，以太网的带宽、延迟等待远远不如本机内存。
真的牛B的数据库集群式DB2 FOR Z上面的Share everything的集群，不过估计平时也没什么机会接触了。

wolfop

原帖由 yueyangflash 于 2009-6-8 17:11 发表
业务分割的话，用单台的不好吗？
毕竟RAC也蛮贵的！
不理解做业务分割为什么还用RAC！

避免全局事务，偶然的跨节点访问开销不算太大，高可用咯，就这个几个好处。

wolfop

原帖由 anycall2010 于 2009-6-6 10:13 发表


上述问题，我也听一个IBM高级顾问提到过。我现在对多节点有几个疑问：
1.从管理角度来说：节点越多，DLM要协调各个节点资源竞争就越困难，这样会严重影响集群的性能。这点好像和ORACLE曾经吹嘘的RAC的LB功能，似乎有些背离？
2.从维护角度来讲：节点越多，那么节点出问题的几率就越大，那么在维护方面，就变得越困难？
3.从RAC本质原理来讲：节点越多，RAC实现cache fusion的时候，会不会出现更多的诸如：并发读，读并发写，写并发写等等的问题？而且多个节点实现的是share-dsk模式，写入磁盘的时候，会不会产生磁盘争用问题？

磁盘争用还真不是问题，问题是cache-fusion中的乒乓效应。

oracle_man

我这里的生产库有2个是4节点的数据库,而且db_block_size设置成16K，当并发性高的时候(OLTP系统)，经常出现生产缓慢的现象,主要原因是buffer busy global cache,以及cache-fusion造成cluster wait比较高,遇到这种状况的时候，烦死了，之前我还在这发了个贴子叫'buffer busy global cache造成系统缓慢'说的就是我们这4节点的问题。