在開始建立測試環境之前，我們先來看一下 MongoDB 如何支援 HA/LB 等需求。MongoDB 共有三種方式可用來支援 LB，分別是 Master/Slave、Replica Set 與 Sharding，而其中 Master/Slave 與 Replica Set 更可以同時提供 HA 的能力。Replica Set 與 Master/Slave 架構類似，都是屬於 Replication 的方式，也就是同一筆資料會同時存放在多個資料庫節點當中。儘管有多個資料庫節點在同時運作，但是 Master/Slave 與 Replica Set 都僅支援單一 Master，也就是說在這許多的資料庫節點當中只有一個節點 (也就是 Master) 是可以被寫入的。而其他不是 Master 的節點，就僅能用來讀取資料。
如果要同時支援多重寫入的需求，目前僅能透過 Sharding 的方式來達成。不過 Sharding 跟常見的多重 Master 不同 (如 MySQL 的 MMM)，並不是所有的資料庫節點都可以當做 Master，而寫入其中的資料會自動複製到其他節點。Sharding 是把一個 Collection 的資料，根據某鍵值 (這個特殊的鍵值又稱為 Shard Key) 的內容，將這個 Collection 內的資料分別儲存到不同的節點。因此一個單純的 Sharding 架構，是沒有具備 HA 的能力。當然，Sharding 可以 (也應該) 搭配 Replica Set 來達到 HA 的功能。
回到 Master/Slave 與 Replica Set 身上，兩者雖然都是 Replication 的架構，但是 Replica Set 支援自動切換 Master 的功能，所以能夠達到自動 HA 的需求。而 Master/Slave 的方式，一旦 Master 出現異常，必須經由手動的方式才能讓 Slave 變成 Master 並繼續提供相關服務。因此，除非是在很特殊的狀況下 (例如超過 Replica Set 所支援的節點上限)，否則應該是盡量採用 Replica Set 的架構，而非 Master/Slave。
在 Replica Set 的架構下，節點可分為三種形式，分別是
- 標準節點 (Standard)
標準節點可以參與 Primary 的投票，也可以被選為 Primary，沒有被選為 Primary 的節點通稱為 Secondary。Primary 就是 Master，可以同時用來作為寫入與讀取之用，而 Secondary 僅能用來作為讀取之用。 - 被動節點 (Passive)
被動節點可以參與 Primary 的投票，但是不能被選為 Primary 。被動節點也僅能用來作為讀取之後。 - 仲裁節點 (Arbiter)
仲裁節點跟被動節點同樣可以參與 Primary 的投票，而且也不能被選為 Primary。跟被動節點不同的是，仲裁節點本身並不存放任何資料。
為什麼會有這麼多類型的節點？因為MongoDB 希望在因網路斷線而失效時，除了能夠避免兩個(或多個) Primary 所造成的不一致現象，同時還能夠確保最多的服務不受到影響。
舉例來說，如果某個 Replica Set 有三個標準節點+兩個被動節點，一旦 Primary 當機失效後，剩下的兩個標準節點與被動節點就會選出一個新的 Master。根據前面的節點類型說明，新的 Primary 將由剩下的兩個標準節點中選出，而選擇的依據則是根據節點的優先權與資料的更新程度。
但是如果今天發生的問題不是 Primary 失效，而是因為網路斷線而造成五個節點一分為二呢？如果原本的 Primary 剛好在擁有較多節點的那個區塊，則什麼事也不會發生 (除了另外一個區塊的節點無法更新資料)。但是如果原本的 Primary 所在的區段擁有較少的節點，那麼這個 Primary 就會自動降為 Secondary，而另外一個區段內的節點則會選出一個新的 Primary。
說完了 MongoDB Replica Set 的基本觀念，在下一篇文章當中我們就來實際建立一個可以運作的 Replica Set。
沒有留言:
張貼留言