Deepgreen & Greenplum 高可用（二） - Master故障轉移

書接上文，今天來談一談master節點的故障轉移。

一、首先從理論上來講，要達到master節點的單點保障，master standby要與master部署在不同的伺服器上。當master節點故障時，同步程式停止，此時手動在master主機激活standby。激活standby時，同步日志被用來恢複master最後一次事務成功送出時的狀态。另外，在激活standby主機同時，可以指定一個新的standby。

下面我們開始實驗：

1.首先給原有叢集添加standby

2.通過sql檢視現有master及standby master狀态

3.模拟master故障并切換到standby

4.切換完成後，在新master主機上連接配接資料庫并運作analyze

至此，切換完成。

二、與mirror一樣，因為standby一般不會單獨占用一台機器，通常部署在某個segment節點之上，是以長期使用standby接管服務，會導緻standby主機争搶segment執行個體資源。通常在原master修複後，應盡快切換為原叢集狀态，下面我們來做這個實驗。

1.首先在原standby主機（現已經承擔master服務）上，執行如下指令，将standby初始化到原master主機（剛修複的問題機器）

2.在目前承擔master服務的standby主機上停止master服務

3.在原master主機上重新激活master服務

4.激活之後，通過下面指令檢視狀态

5.一旦狀态正常，便可将原standby主機重新初始化

至此，叢集已經恢複到原始狀态，這裡面關于原master、現master、原standby和現standby的概念，有點繞，需要認真品味。

三、最後分享另外兩個與standby相關的操作

1. 同步standby并更新到最新的同步

2.删除standby

備注：

standby可以輕松添加和删除，然而mirror卻隻允許添加，不允許删除。

需要注意，master的熱備standby需要手工激活，并且使用不同的通路ip；而segment的鏡像卻可以自動切換。

end~~