​

從這一篇開始，我們要踏上MongoDB進階之路啦，想想還有點小開心呢。一筐豬鎮樓。

​

引入複製集

我們先來想一個場景，如果本地專案使用MongoDB，都是下載，安裝，連線一條龍服務。這實際也就是單點模式，那如果我們專案要上線了，這個時候還是一個數據庫，就可能出問題。比如我們寫了個淘寶（噓，假裝是個大牛），雙十一那天晚上，資料庫掛了，emmm，這秒秒鐘損失多少錢啊，不敢想象，這個時候，可能你就拜拜啦。所以我們要把這種可能性扼殺到搖籃裡面，這就有了複製集的用武之地。

瞭解複製集

複製集也就是多個數據庫，一個掛了，其他的還能頂上，而不至於系統掛。具體的邏輯圖如下：

​

複製集裡面節點主要包括三類，上面已經知道啦有兩種，分別是主節點和從節點，還有一個是投票節點。

他們各自的作用：

主節點：寫操作。

從節點：複製主節點的資料，提供讀操作。

投票節點：在主節點出現故障的時候，系統會在從節點中自動投票選舉新的主節點。這個投票節點就是在這個投票選舉情況下使用的。

複製集的特徵

1.主節點唯一不固定

我們從上面的圖上就可以看出來這個特徵，也就是當主節點沒有啥問題的時候，從節點不會成為主節點，且也不會有新的主節點，這說明了唯一性。當主節點出現問題了，從節點鐘的一個會成為主節點，這說明了不固定性。

2.大多數原則

當前複製集中，存貨節點的數量必須大於節點總數的1/2，這樣才能觸發選舉。這是為什麼，等我學習了再說，先放著哈。

3.從庫無法寫入

這邊從節點是不能寫入的，MongoDB有嚴格的控制。