從這一篇開始，我們要踏上MongoDB進階之路啦，想想還有點小開心呢。一筐豬鎮樓。
引入複制集
我們先來想一個場景，如果本地項目使用MongoDB，都是下載下傳，安裝，連接配接一條龍服務。這實際也就是單點模式，那如果我們項目要上線了，這個時候還是一個資料庫，就可能出問題。比如我們寫了個淘寶（噓，假裝是個大牛），雙十一那天晚上，資料庫挂了，emmm，這秒秒鐘損失多少錢啊，不敢想象，這個時候，可能你就拜拜啦。是以我們要把這種可能性扼殺到搖籃裡面，這就有了複制集的用武之地。
了解複制集
複制集也就是多個資料庫，一個挂了，其他的還能頂上，而不至于系統挂。具體的邏輯圖如下：
複制集裡面節點主要包括三類，上面已經知道啦有兩種，分别是主節點和從節點，還有一個是投票節點。
他們各自的作用：
主節點：寫操作。
從節點：複制主節點的資料，提供讀操作。
投票節點：在主節點出現故障的時候，系統會在從節點中自動投票選舉新的主節點。這個投票節點就是在這個投票選舉情況下使用的。
複制集的特征
1.主節點唯一不固定
我們從上面的圖上就可以看出來這個特征，也就是當主節點沒有啥問題的時候，從節點不會成為主節點，且也不會有新的主節點，這說明了唯一性。當主節點出現問題了，從節點鐘的一個會成為主節點，這說明了不固定性。
2.大多數原則
目前複制集中，存貨節點的數量必須大于節點總數的1/2，這樣才能觸發選舉。這是為什麼，等我學習了再說，先放着哈。
3.從庫無法寫入
這邊從節點是不能寫入的，MongoDB有嚴格的控制。
至此正文内容就已結束了，感謝您看到這裡。
如果本文對您有一點幫助，希望能得到您一個點贊👍哦
您的認可才是我寫作的動力！
如果需要轉載，請在開頭标明原文位址。