RAC環境配置好以後，在server上生成的tnsnames.ora裡面，負載均衡預設是開啟的。一直對RAC的負載均衡不大明白。比如，RAC本身的負載均衡的依據是什麼，是基於連線數，還是基於server的cpu佔有率，如何徹底關閉掉RAC的負載均衡。
關閉負載均衡的原因，有可能有下面幾個：
1，RAC的最佳實踐之一，就是把不同的模組訪問不同的node，這樣可以減少很多同步方面的工作，減少nodes之間通訊量。
2，有的客戶可能是從原有系統升級到RAC的，各個節點機器配置不一定相同，雖然Oracle不建議這樣做，但是有些時候客戶聽到RAC的概念之後，總是希望幾臺server一起工作，其實經過我們測試，如果機器配置差別較大，在沒有把不同業務模組分開訪問不同node的情況下，這樣的搭配比單獨使用高配置機器的效能還差。當然主要原因是同步問題。所以如果Oracle負載均衡機制不理想的話，還不如將其關掉，手動進行負載均衡，某些情況下，可以減少同步需求。
這次在Oracle產品展示區當面請教了一下Oracle工程師這方面的問題，不過好像說法好像也不完全一致。

關於負載均衡的依據：
工程師A說僅僅基於連線數，另外一位工程師B說是連線一瞬間的server cpu佔有率。
關於徹底關掉負載均衡：
需要把客戶端tnsnames.ora中的load_balance設定為off，並且把remote_listener設定為空。

回來之後又google了一下，另外找到了一篇metalink的文件，Note:226880.1
configuration of load balancing and transparent transparent application failover
還有一篇文章：http://www.unixblog.net/mixer/?2005/12/15/1
看了這兩篇文章之後，有些明白這個問題了，首先要搞清幾個概念：

?

客戶端負載均衡：客戶端tnsnames.ora的配置（英文是節選Note:226880.1）
The client load balancing feature enables clients to randomize connection
requests among the listeners. Oracle Net progresses through the list of
protocol addresses in a random sequence, balancing the load on the various
listeners. Without client load balancing, Oracle Net progresses through the
list of protocol addresses sequentially until one succeeds.? This normally is
referred to connect-time load balance.?
如果開啟客戶端負載均衡，則在連線的時候會隨機的選擇配置中的ADDRESS來進行連線，這一步可以理解為完全不考慮server端負載情況的，雖然不是基於連線數的，但是“隨機”的結果，應該是連線數相對平均的。這可能就是工程師A所說的，根據連線數。

伺服器端負載均衡：初始化引數remote_listener的配置（英文是節選Note:226880.1）
In a shared server configuration, a listener selects a dispatcher in the following order:
1. Least-loaded node
2. Least-loaded instance
3. Least-loaded dispatcher for that instance
In a dedicated server configuration, a listener selects an instance in the following order:
1. Least loaded node
2. Least loaded instance
（這個地方有點疑問，就是沒搞清這裡面的node和instance啥區別，一個node上不是一般就是跑一個instance嗎？汗...）
如果配置了remote_listener，在INSTANCE_ROLE都是PRIMARY_INSTANCE的情況下，listener會把連線route到負載低的節點上。這可能是B所說的，基於系統負載。

?

如果要徹底關掉負載均衡，需要三個工作
1.在客戶端的tnsnames.ora，設定load_balance=off。關閉客戶端負載均衡，連線會先到第一個address，但是可能被轉發。
2.伺服器端，設定remote_listener=''，如果這裡不設定，連線可能被轉發。
3.確保不同的應用伺服器訪問不同的節點，或者不同的模組訪問不同的節點。如果不進行修改配置，是按照tnsnames.ora裡面的address順序進行連線，不出錯的情況下，始終是第一個列出的節點。
如果僅僅修改tnsnames.ora而不把remote_listener設定為空，那麼即便在連線字串裡面指定了SID，仍然不能保證就是連線的那個SID，因為listener可能根據負載，把連線route到另外一個節點。不過這一點我還沒有來得及實際做一下確認，只是兩位工程師都是這麼說。

?

但是設定了remote_listener為空就有個比較大的損失，就是好像不可能再實現TAF，不知道有無兩全的辦法。

??? 關於兩節點RAC，機器配置差別比較大的那個案例，如果以後觀察到效能差是因為RAC，如果沒有其他手段再最佳化，那麼我想這樣做一下：
??? 兩個節點的remote_listener都設定為空，關閉掉伺服器端負載均衡。一臺應用伺服器的客戶端負載均衡開啟，另外一臺應用伺服器的客戶端負載均衡關閉並且連線到配置比較好的那臺db server上，這樣的效果就是：一臺應用的連線全部到好一點的機器，另外一臺應用的連線，有接近一半的連線是到好一點的機器上。也算是手工負載均衡了一下。因為我看到至少對9i來說，所謂的伺服器端負載均衡好像不怎麼有效。
或者用另外的辦法：
??? 兩個應用伺服器的tnsnames.ora中把客戶端負載均衡都關掉，remote_listener不變，並且修改兩臺機器的INSTANCE_ROLE，這樣，所有的應用連線都是到PRIMARY_INSTANCE，這樣基本上就沒什麼需要同步的東西了，但是另外一臺server實際上也就基本空閒了。這時候的好處就只剩下高可用性了。

?

不過還有個問題沒有搞懂：
如果只設定了一個節點為PRIMARY_INSTANCE，那麼TAF是否有效，還是隻有Connect-Time Failover有效。據我憑空想，因為remote_listener是存在的，所以TAF應該是有效的，但是需要驗證一下。?

?

另外，http://www.unixblog.net/mixer/?2005/12/15/1?中提到：“但是客戶不需要load_balance，問題就一直卡在這裡：一旦在DESCRIPTION下，定義了多個地址，即使用(load_balance= off)關閉了client端的負載均衡，但伺服器端的負載均衡仍然自動生效；如果不定義多個地址，又無法實現connect-time failover。” 這裡有點懷疑，伺服器端負載均衡與多個address有無關係？我認為應該只是與remote_listener有關係，只要這個引數存在，伺服器端負載均衡都是在作用的。這點也需要驗證一下。那篇文章後面說的不定義多個地址實現connect-time failover的方法是正確的，因為根據上文的metalink文件，(failover = on)是可以放在DESCRIPTION_LIST節，也可以放在address節，推薦放在address。

?

10g的RAC比9i有了很大改進，特別是在節點間同步的問題上。據Oracle人講，11g又有很大提高，期待11g RAC的效能表現。?

發表:

今天又看到一篇文章：http://yangtingkun.itpub.net/post/468/283474?

這裡引用一段：

首先，TAF是針對SESSION和SELECT的，它不支援事務的切換。其實想想也是有道理的，當連線的例項發生了故障，客戶端的連線發生了切換之後，SESSION資訊、INSTANCE資訊以及其他很多事務依賴的東西都不存在了，Oracle為了保證事務的完整性和一致性，必要要求使用者回滾事務。
第二，SELECT模式的TAF只對不包含任何事務處理的查詢有效。一旦使用者執行了修改操作，SELECT模式也無法在TAF之後將進行一半的查詢完成。
最後，如果啟用了TAF功能，那麼程式必須要新增處理ORA-25402錯誤的能力，否則一旦發生TAF切換，程式將一直報錯，而無法再進行任何操作。

這裡需要注意一下。

[zt Oracle RAC 負載均衡 --Oracle OpenWorld2007

相關文章