mongodb副本集（linux）的搭建

.创建副本集
3台虚拟机虚拟机的ip地址
Test1 192.168.126.149 (初始计划设定其为slave)
Test2 192.168.126.150 (初始计划设定其为master)
Test3 192.168.126.151 (初始计划设定其为arbiter ，即仲裁服务器)
2.为副本集取名weijh
配置151启动文件：

dbpath=/usr/data/mongodb/data/db
port=27017
logpath=/usr/data/mongodb/log/mongodb.log
logappend=true
journal=true
fork=true
replSet=weijh/192.168.126.150

配置149 启动文件：

dbpath=/usr/data/mongodb/data/db
port=27017
logpath=/usr/data/mongodb/log/mongodb.log
logappend=true
journal=true
fork=true
replSet=weijh/192.168.126.150

配置150启动文件：

dbpath=/usr/data/mongodb/data/db
port=27017
logpath=/usr/data/mongodb/log/mongodb.log
logappend=true
journal=true
fork=true
replSet=weijh/192.168.126.151,192.168.126.149

配置结束后，重启服务
3、 在浏览器打开链接
http://192.168.126.150:28017/
http://192.168.126.151:28017/

4：初始化副本集
登入任意一台机器的MongoDB执行：因为是全新的副本集所以可以任意进入一台执行；要是有一台有数据，则需要在有数据上执行；要多台有数据则不能初始化。（随便连接一下哪个服务器都行，不过一定要进入admin集合）
use admin

rs.initiate({"_id":"weijh","members":[
 {"_id":1,
 "host":"192.168.126.150",
"priority":1
},
{"_id":2,
 "host":"192.168.126.151",
 "priority":1
 }
 ]})

“_id”: 副本集的名称
“members”: 副本集的服务器列表
“_id”: 服务器的唯一ID
“host”: 服务器主机
“priority”: 是优先级，默认为1，优先级0为被动节点，不能成为活跃节点。优先级不位0则按照有大到小选出活跃节点。
“arbiterOnly”: 仲裁节点，只参与投票，不接收数据，也不能成为活跃节点

显示如图，则表示正确

{
	"info" : "Config now saved locally.  Should come online in about a minute.",
	"ok" : 1
}

 rs.status()

{
	"set" : "weijh",
	"date" : ISODate("2019-05-06T13:25:01Z"),
	"myState" : 1,
	"members" : [
		{
			"_id" : 1,
			"name" : "192.168.126.150",
			"health" : 1,
			"state" : 1,
			"stateStr" : "PRIMARY",
			"optime" : {
				"t" : 1557149060000,
				"i" : 1
			},
			"optimeDate" : ISODate("2019-05-06T13:24:20Z"),
			"self" : true
		},
		{
			"_id" : 2,
			"name" : "192.168.126.151",
			"health" : 1,
			"state" : 2,
			"stateStr" : "SECONDARY",
			"uptime" : 32,
			"optime" : {
				"t" : 1557149060000,
				"i" : 1
			},
			"optimeDate" : ISODate("2019-05-06T13:24:20Z"),
			"lastHeartbeat" : ISODate("2019-05-06T13:25:00Z")
		}
	],
	"ok" : 1
}

二.增删节点
把149服务加入到副本集中：

rs.add("192.168.126.149")

副本集的配置

rs.conf()/rs.config()

rs.conf()
{
	"_id" : "weijh",
	"version" : 10,
	"members" : [
		{
			"_id" : 1,
			"host" : "192.168.126.150"
		},
		{
			"_id" : 2,
			"host" : "192.168.126.151"
		},
		{
			"_id" : 3,
			"host" : "192.168.126.149"
		}
	

2.删除149服务

rs.remove("192.168.126.149")

3：添加仲裁节点

把149节点删除。再添加让其为仲裁节点：

rs.addArb("192.168.126.149")
rs.conf()

rs.conf()
{
	"_id" : "weijh",
	"version" : 12,
	"members" : [
		{
			"_id" : 1,
			"host" : "192.168.126.150"
		},
		{
			"_id" : 2,
			"host" : "192.168.126.151"
		},
		{
			"_id" : 3,
			"host" : "192.168.126.149",
			"arbiterOnly" : true
		}
	]
}

上面说明已经让149服务器成为仲裁节点。副本集要求参与选举投票(vote)的节点数为奇数，当我们实际环境中因为机器等原因限制只有两个(或偶数)的节点，这时为了实现 Automatic Failover引入另一类节点：仲裁者（arbiter），仲裁者只参与投票不拥有实际的数据，并且不提供任何服务，因此它对物理资源要求不严格。
通过实际测试发现，当整个副本集集群中达到50%的节点（包括仲裁节点）不可用的时候，剩下的节点只能成为secondary节点，整个集群只能读不能 写。比如集群中有1个primary节点，2个secondary节点，加1个arbit节点时：当两个secondary节点挂掉了，那么剩下的原来的 primary节点也只能降级为secondary节点；当集群中有1个primary节点，1个secondary节点和1个arbit节点，这时即使 primary节点挂了，剩下的secondary节点也会自动成为primary节点。因为仲裁节点不复制数据，因此利用仲裁节点可以实现最少的机器开 销达到两个节点热备的效果。
4.主节点添加数据
db.test.insert({“name”:“2”,“age”:“2”});
db.test.find()

weijh:PRIMARY> db.test.insert({"name":"2","age":"2"});                                                                                                                                                                
weijh:PRIMARY> db.test.find()
{ "_id" : ObjectId("5cd037bcb169f54f247fdacf"), "name" : "22", "age" : "22" }
{ "_id" : ObjectId("5cd0dd31d27018729f6098be"), "name" : "22", "age" : "42" }
{ "_id" : ObjectId("5cd14a6f7a520e220ad9aad2"), "name" : "2", "age" : "2" }
{ "_id" : ObjectId("5cd155fa3faf7fbda4b3e8d2"), "name" : "2", "age" : "2" }

5.副节点查看数据

weijh:SECONDARY> db.test.find()
error: { "$err" : "not master and slaveok=false", "code" : 13435 }

读写分离
首先这是正常的，因为SECONDARY是不允许读写的， 在写多读少的应用中，使用Replica Sets来实现读写分离。通过在连接时指定或者在主库指定slaveOk，由Secondary来分担读的压力，Primary只承担写操作。对于replica set 中的secondary 节点默认是不可读的：
大部分web应用都用数据库作为数据持久化工具,在并发访问频繁且负载压力较大的情况下,也能成为系统性能的”瓶颈”,即使使用本地缓存等方式解决频繁访问数据库的问题,但仍会有大量的并发请求访问动态数据,”读写分离”是一种被广泛采用的方案

“读写分离”,机制首先将那些使用CPU以及内存消耗严重的操作分离到一台或几台性能很高的机器上,而将频繁读取的操作放到几台配置较低的机器上,然后,通过数据同步机制,实现多个数据库之间快速高效地同步数据,从而实现将”读写请求”按实际负载情况进行均衡分布.
rs.slaveOk()

weijh:SECONDARY> rs.slaveOk()
not master and slaveok=false
weijh:SECONDARY> db.test.find()
{ "_id" : ObjectId("5cd037bcb169f54f247fdacf"), "name" : "22", "age" : "22" }
{ "_id" : ObjectId("5cd0dd31d27018729f6098be"), "name" : "22", "age" : "42" }
{ "_id" : ObjectId("5cd14a6f7a520e220ad9aad2"), "name" : "2", "age" : "2" }
{ "_id" : ObjectId("5cd155fa3faf7fbda4b3e8d2"), "name" : "2", "age" : "2" }
weijh:SECONDARY>