Oracle RAC如何避免腦裂

bebeOracle CSSD(Cluster ServicesSynchronization Daemon)進程通過兩個互相獨立的心跳信號來監控集群節點的健康狀況：network heart beat和disk heart beat

網絡心跳：集群里每一個節點的CSSD進程的一個線程每秒會通過inteconnect發送一個TCP協議心跳信號給RAC里面的所有節點（包括自己）。如果心跳信號傳輸出現問題，TCP協議的自我矯正機制會重新傳送數據包。這種情況下，oracle不會關注傳輸細節。

磁盤心跳：集群里每一個節點的CSSD進程會在voting磁盤的特定位置的數據塊通過讀寫數據維持心跳信號。此外，每個節點還會監控其它節點CSSD進程維護的心跳信號數據塊。如果發現某個節點在指定的時間內沒有寫入磁盤心跳，這個節點就被判決為死亡。如果一個節點處于未知狀態，其它節點也會被通過更新它的voting disk上的kill block狀態的方式把它驅逐出集群。

總的來說，網絡心跳每秒都會發起，如果一個節點超出了參數css_miscount time設定的時間沒有響應，就會被踢出集群。類似的，集群里的每個節點每秒讀寫voting disk特定區域，出現超時響應的節點也會被踢出集群。下面是節點面臨的心跳可能出現的狀況及后果：

腦裂: 在RAC環境里，所有的oracle實例都是通過高速私有網絡互相通訊的。這個私有網絡的鏈路都應該配置成冗余的，并且僅用于實例之間的oracle數據塊傳輸。以含有運行在兩臺機器上的2個實例組成的RAC集群為例，當RAC集群里服務器運行正常，兩個實例本身也運行正常的情況下，兩個oracle實例不能夠通過私有網絡互相通訊時，如果不做預防，兩個實例會各自獨立的運行并對外提供服務。由于兩個實例失去了互相之間的通訊，都會認為對方已死，從而不再使用原有的保護共享數據的機制，這會導致共享數據混亂。這就是腦裂。

IOfencing：如果操作系統正常但是oracle實例出現故障導致時，recovery進程可能會把之前故障實例殘留的寫操作執行。由于在這種情況下寫操作無法保持正確的寫入順序，他們可能會導致數據混亂，所以必須阻止。所以，在集群環境里，如果一個節點故障，必須阻止它對共享存儲的寫操作。這種方法稱之為IO fencing。

簡單多數原則：為了維持RAC集群正常運行，配置的仲裁盤必須有一半以上數量正常運行。

下面兩個實例用來理解當心跳出現問題時，仲裁盤的作用機制。

例子1，如下圖，三個節點的集群，配有3個仲裁盤. Node3與其它兩個節點的網絡通訊（network heartbeat）中斷。但是，CSSD進程通過讀仲裁盤狀態發現所有的節點都可以寫仲裁盤,這說明出現了腦裂。于是節點1和節點2就會更新仲裁盤上的節點3 kill block狀態。然后節點3的CSSD進程通過讀仲裁盤上對應的kill block，知道自己應該退出集群。于是執行IO fencing，然后關閉自己。

例子2，配有3個仲裁盤的雙節點集群，disk heartbeat出現問題，導致節點1可以訪問2個仲裁盤，節點2可以訪問1個仲裁盤。這時基于簡單多數原則，節點1（兩個仲裁盤）會發出自殺指令給節點2。這樣節點2就會退出集群。

例子2中更進一步的問題，如果出現一個仲裁盤故障導致兩個節點都不能訪問它，但是另外兩個仲裁盤對兩個節點都可訪問。這種情況下，如何判定該退出哪個節點？此時，由于兩個節點可以訪問的仲裁盤滿足簡單多數原則，如果此時Network heartbeat正常，RAC會正常運行，不會踢出任何一個節點。如果不幸，又有一個仲裁盤故障導致它不能被兩個node訪問，又會發生什么？

此時，網絡正常，但是仲裁盤低于簡單多數，所以RAC必然重構，但是兩個節點條件一致。RAC會選擇保留最低節點號的節點，在這個案例中，就是node1被保留，node2被踢出。

本文大部分內容來自需要科學上網的英文網站https://nitishanandsrivastava.wordpress.com/，我對其做了裁剪和引申。