Replica Set在國內叫做副本集，簡單來說就是一份數據在多個地方存儲。
1.為什么要用副本集，什么時候使用副本集？
有人說一份數據在多個地方存儲占用了大量的額外空間，是一種浪費。
這個說法不能說對也不能說不對，要從不同的角度考慮。如果公司的業務量很少，數據不多，一台服務器就可以搞定，那就不需要將一份數據存儲在多個地方。隨着公司的發展壯大，業務量越來越多，數據也越來越多，這時就需要考慮使用分布式集群的方式來解決了，將數據分散在不同的服務器中。此時仍可以不使用副本，通過將數據分散在不同的服務器中來分散各服務器的壓力也可以跟上公司目前的業務量。如果公司規模進一步擴大，用戶量越來越多，有可能很多客戶要訪問同一份資源，此時就有可能造成存放該資源的服務器壓力過大。副本的必要性就顯現出來了。
2.使用副本集有什么好處？
副本集提供了容錯性，高可用性。當然容災備份，讀寫分離等也使用到了副本。
3.MongoDB Replica Set集群介紹
先上一個典型的 Replica Set圖:
為方便介紹，以下簡稱rs集群
(1).rs集群是由多個Mongod實例節點組成，其中只有一個節點是primary,其它節點是secondary，還有一個是可有可無的仲裁節點。當集群有偶數個節點時，通過會添加一個仲裁節點，如果集群有奇數個節點時，就不需要使用仲裁節點了。仲裁節點不存儲數據，只用於投票選舉出哪個節點是primary，而且仲裁節點不要求有專門的服務器，但不能運行在已經安裝了primary或secondary節點的服務器上，可以運行在應用或監控服務器上(之前看到有人說仲裁節點除了投票外，還可以在primary節點失效后，在secondary節點中再選舉出一個primary，這是不對的，仲裁節點的作用僅僅是有一票之權)。
(2).primary用於接收client的讀和寫請求，並記錄操作日志，secondary用於從primary處異步同步primary的操作日志，並更新自己的數據集。通常情況下secondary不能響應client的讀操作，以免讀取臟數據。但rs集群有多個數據中心時，client可以請求讀取secondary數據，當primay在北京的服務器上，其中一個Secondary在重慶，重慶的用戶在讀取數據時，考慮到地理位置和網速的關系，可選擇只讀primary，primary優先，只讀secondary，secondary優先和讀取最近(nearest)節點的數據。
(3).當primary不能訪問時，剩下的secondary節點中會再選出一個primary節點。
4.RS集群部署示例
(1).有三台服務器，由於是奇數服務器，所以不選擇仲裁節點。
(2).下載MongodDB手動安裝版(我下載的是Linux 64位版本)，並解壓到一個目錄下，將解壓的文件夾名字改成mongoDB,進入mongoDB目錄，新建一個配置文件mongod.conf
#mongod.conf
#數據保存路徑
dbpath=mongodb/data/mongod
#日志保存路徑
logpath=mongodb/log/mongod.log
logappend=true
#后台運行保存的進程pid
pidfilepath=/home/yanggy/mongodb/mongod.pid
#每個數據庫一個目錄
directoryperdb=true
#replica set的名字
replSet=testrs
#綁定IP與Host
bind_ip=server1
port=27001
#日志文件大小
oplogSize=100
#后台運行
fork=true
#不提前加載數據到內存
noprealloc=true
將此配置文件復制到其它服務器中，修改綁定的IP即可，並手動在各服務器建立相應的數據和日志目錄。
(3).在各服務器啟動mongod實例
mongod -f mongodb/mongod.conf
(4).使用mongo連接其中一台服務器
mongo --host server1 --port 27001
(5).初始化rs集群
> cfg = {_id:"testrs",members:[{_id:0,host:"server1:27001",priority:3},
{_id:1,host:"server2:27001",priority:2},
{_id:2,host:"server3:27001",priority:1}]}
輸出:
{
"_id" : "testrs",
"members" : [
{
"_id" : 0,
"host" : "server1:27001",
"priority" : 3
},
{
"_id" : 1,
"host" : "server2:27001",
"priority" : 2
},
{
"_id" : 2,
"host" : "server3:27001",
"priority" : 1
}
]
}
>rs.initiate(cfg)
輸出:
{
"ok" : 1,
"operationTime" : Timestamp(1521190572, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1521190572, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
>rs.status()
輸出:
{
"set" : "testrs",
"date" : ISODate("2018-03-16T08:56:23.948Z"),
"myState" : 1,
"term" : NumberLong(1),
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"appliedOpTime" : {
"ts" : Timestamp(1521190572, 1),
"t" : NumberLong(-1)
},
"durableOpTime" : {
"ts" : Timestamp(1521190572, 1),
"t" : NumberLong(-1)
}
},
"members" : [
{
"_id" : 0,
"name" : "server1:27001",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 220,
"optime" : {
"ts" : Timestamp(1521190572, 1),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("2018-03-16T08:56:12Z"),
"infoMessage" : "could not find member to sync from",
"electionTime" : Timestamp(1521190582, 1),
"electionDate" : ISODate("2018-03-16T08:56:22Z"),
"configVersion" : 1,
"self" : true
},
{
"_id" : 1,
"name" : "server2:27001",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 11,
"optime" : {
"ts" : Timestamp(1521190572, 1),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(1521190572, 1),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("2018-03-16T08:56:12Z"),
"optimeDurableDate" : ISODate("2018-03-16T08:56:12Z"),
"lastHeartbeat" : ISODate("2018-03-16T08:56:22.733Z"),
"lastHeartbeatRecv" : ISODate("2018-03-16T08:56:19.659Z"),
"pingMs" : NumberLong(0),
"configVersion" : 1
},
{
"_id" : 2,
"name" : "server3:27001",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 11,
"optime" : {
"ts" : Timestamp(1521190572, 1),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(1521190572, 1),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("2018-03-16T08:56:12Z"),
"optimeDurableDate" : ISODate("2018-03-16T08:56:12Z"),
"lastHeartbeat" : ISODate("2018-03-16T08:56:22.733Z"),
"lastHeartbeatRecv" : ISODate("2018-03-16T08:56:19.641Z"),
"pingMs" : NumberLong(0),
"configVersion" : 1
}
],
"ok" : 1,
"operationTime" : Timestamp(1521190572, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1521190582, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
可以看到priority值越大的節點越有可能成為primary。
好了，相信大家對Replica Set已經有了初步體驗和認識，如果上文中有什么表述的不准備或者錯誤的地方，歡迎指出，大家共同探討進步。