BDB JE HA系列之主節點轉換

在一個HA的組裡面，由于所有對資料庫的更改都是在主節點上面，然後由它将所做的更改分發到各個副節點，導緻主節點上的負擔非常重，是以選擇組内計算能力最強的節點做主節點是順理成章的事情。

那麼一旦加入一個新的節點，它的運算能力比現有的主節點能力更強，使用者肯定是希望将這個新節點設定為主節點，這就需要一種能夠讓使用者随意的在兩個節點之間轉換master角色的功能，整個過程如下：

1.指定的副節點要趕上目前的主節點，在這期間主節點可以繼續響應寫操作，如果副節點的最新資料在這個過程完成之後還落後于主節點上的最新資料，則轉換失敗

2.當副節點趕上主節點之後，阻止目前主節點上事務的送出或復原，這樣是為了保證副節點上擁有最新的資料

3.副節點再次驗證其是否擁有最新的資料，如果沒有，則該轉換失敗

4.調用選舉協定廣播一個Result資訊，該資訊的内容就是推選指定的副節點為主節點

5.原來的主節點轉換成副節點，但是需要經曆一個恢複的過程，也就是說舊主節點會崩潰并重新啟動

為什麼一定要保證副節點要擁有和主節點一樣的資料呢？這是因為如果新推選出的主節點的資料比其它的副節點的資料還要老的話，也就是出現了資料不一緻的情況，而且副節點無法通過同步主節點來解決這種不一緻的狀況，導緻副節點必須将那些在主節點上不存在的資料進行復原，也就是所謂的硬恢複(Hard Recovery)。除了硬恢複之外，還有軟恢複，我會在其它的文章裡講述這兩者的差别。

一旦出現這種情況，就意味着目前的組除了主節點之外，有可能其它的副節點全部崩潰，該組就無法提供資料服務，是以如果副節點沒有趕上主節點，則轉換失敗，主節點不會被轉換。

保證副節點趕上主節點相對比較簡單，設定一個countdownlatch，這個latch隻有在指定的副節點趕上主節點之後才會釋放。檢驗一個節點是否趕上主節點，隻需要檢查兩個節點上最新的表示目前事務結束的日志是否一緻，如果一緻則表示副節點趕上了主節點。

在副節點趕上主節點之後，為了保證主節點上不會再有新的資料更新，需要阻止在主節點上事務的送出或復原(包括使用者啟動的事務和内部事務)。為什麼隻需要組織事務的送出和復原呢？因為隻有這兩種日志點才會被用來校驗主副節點是否一緻，其餘的資料可以通過軟恢複復原。

以上的措施可以保障主節點在一定的時間内被副節點趕上。

但是在HA中還有另外一個問題需要解決：如何處理一個主節點轉換為副節點？這是由于在主節點上還有一些事務沒有送出或復原，這些事務是在主節點轉換為副節點之前啟動的，是以用于更改資料的權限，如果不處理，會導緻主副節點的不一緻。處理這個問題的最好辦法就是将主節點crash，然後再做恢複，這樣就可以讓那些資料不一緻性消失。