workming 的BLOG
用户名：workming
文章数：126
评论数：236
访问量：1165605
注册日期：
阅读量：5863
阅读量：12276
阅读量：404489
阅读量：1093305
51CTO推荐博文
(1)、针对近期出现的mongodb未授权的安全问题，导致mongodb数据会被非法访问。应安全平台部的要求，需要对所有mongodb进行鉴权设置，目前活动侧总共有4台，用于某XX产品；略过（直接从官方下载二进制包解压到“/usr/local”路径）…..#!/bin/bash##&this&script&start&and&stop&the&mongodb&daemon
##&chkconfig:&&&-&85&15
#&description:&mongodb&is&a&document&key-value&database
#&processname:&mongod
#&config:&&&&&/usr/local/mongodb/etc/mongod.conf
#&pidfile:&&&&&/usr/local/mongodb/run/mongod.pid
#&code&by&rocketzhang
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
mongod="/usr/local/mongodb/bin/mongod"
prog=mongod
OPTIONS="--fork&--config&/usr/local/mongodb/etc/mongod.conf"
&&&&echo&-n&$"Starting&$prog......"
&&&&numactl&--interleave=all&$mongod&$OPTIONS
&&&&RETVAL=$?
&&&&[&$RETVAL&-eq&0&]
&&&&return&$RETVAL
&&&&echo&-n&$"Stopping&$prog......"
&&&&/sbin/killproc&-9&$prog
&&&&RETVAL=$?
&&&&[&$RETVAL&-eq&0&]
&&&&return&$RETVAL
case&"$1"&in
&&&&start&
&&&&sleep&1&
&&&&start&
&&&&echo&$"Usage:&$prog&{start|stop|restart}"&
&&&&exit&1
esac& (1)、账号添加# /usr/local/mongodb/bin/mongo --host XXX.XXX.XXX.XXX --port 27017& & & …..& & ）# vim /usr/local/haproxy/etc/haproxy.conf……#!/bin/sh
#======================================================================
##&MongoDB副本集PRIMARY角色异常监控告警
##&code&by&rocketzhang
#======================================================================
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
MONGO_BIN_PATH="/usr/local/mongodb/bin/mongo"
MONITOR="/usr/local/oms/agent/alarm/BusMonitorAgent"
TOKEN="fengling_mongodb"
TITLE="MongoDB副本集PRIMARY角色异常监控"
SRV_IPADDR="10.153.224.44"
SRV_PORT="27017"
##&S代表TCP协议，U代表UDP协议
PROT_OPT="S"
SCAN_FLAG=0
HOSTS_FILE="/etc/hosts"
for&((i=0;&i&3;&i++));&do&
&&&&RETVAL=`/usr/bin/nmap&-n&-s${PROT_OPT}&-p&${SRV_PORT}&${SRV_IPADDR}&|&grep&open`&
&&&&[[&-n&"${RETVAL}"&]]&&&&SCAN_FLAG=1;break&||&sleep&10
if&[[&${SCAN_FLAG}&-eq&0&]];&then&
&&&&CONTENT="MongoDB集群存在异常，27017端口不可达！"&
&&&&${MONITOR}&-c&2&-f&${TOKEN}&-t&"${TITLE}"&-i&"${CONTENT}"
CURRENT_MONGO_MASTER=`awk&'/fl./{print&$1}'&/etc/hosts`
NEW_MONGO_MASTER=`${MONGO_BIN_PATH}&--host&${SRV_IPADDR}&-ucheck_health&-p'tenmongo$2356'&admin&--quiet&--eval&"printjson(rs.status())"&|&grep&-B&3&PRIMARY&|&awk&-F&':'&'/name/{print&$2}'&|&sed&'s/&"//'`
if&[[&"${NEW_MONGO_MASTER}"&!=&"${CURRENT_MONGO_MASTER}"&]];&then&
&&&&sed&-i&'/fl./d'&${HOSTS_FILE}&
&&&&echo&"${NEW_MONGO_MASTER}&&&&fl."&&&&${HOSTS_FILE}&
&&&&/sbin/service&nscd&restart&&/dev/null&2&&1&&
&&&&CONTENT="MongoDB副本集PRIMARY角色已自动切换，请尽快确认！"&
&&&&${MONITOR}&-c&2&-f&${TOKEN}&-t&"${TITLE}"&-i&"${CONTENT}"
fi&&提取密码：levr本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)mongodb副本集设定连接异常
一台服务器启动
mongod --port=2222 &--dbpath=D:/mongodb1/data/ --replSet shopex/192.168.0.222:3333
另一台服务器
mongod --dbpath=D:/mongodb/data/ --port=3333 -replSet shopex/192.168.0.205:2222
进入mongo 192.168.0.205:2222/admin
db.runCommand({ &replSetInitiate&:{ &&_id&:&shopex&, &&members&:[ &{&_id&:1,&host&:&192.168.0.205:2222&}, &{&_id&:2,&host&:&192.168.0.222:3333&} &] } })
操作结果为 & & & & &startupStatus& : 4, & & & & &info& : &shopex/192.168.0.222:3333&, & & & & &ok& : 0, & & & & &errmsg& : &all members and seeds must be reachable to initiate set& } 当mongo 192.168.0.222:3333/admin
&db.runCommand({ &replSetInitiate&:{ &&_id&:&shopex&, &&members&:[ &{&_id&:1,&host&:&192.168.0.205:2222&}, &{&_id&:2,&host&:&192.168.0.222:3333&} &] } }) 连接成功了。
& 设置通一台电脑上的副本集没遇到这种情况。&
&&提问：这是个别情况，还是普遍情况。
& &如果是个别情况，原因可能是什么？（我连接之前把data文件夹下的东西都删了）mongodb replica set(副本集)设置步骤 - tcrct - ITeye技术网站
博客分类：
网上已经有一大堆的设置步骤的了，根据我遇到的问题，整理一下，如下：
首先先去下载一个mongodb最新版，目前最新版应该是2.6
cd /usr/local/bin
wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.6.0.tgz
mongodb-linux-x86_64-2.6.0.tar
mv mongodb-linux-x86_64-2.6.0/ mongodb2.6
先切换到安装目录，再下载，然后解压，最后改名！
mkdir -p /mnt/mongodb/rs/data
mkdir -p /mnt/mongodb/rs/logs
mkdir -p /mnt/mongodb/rs/config
然后再进入/mnt/mongodb/rs/config目录，新建mongod.conf文件，用来启动mongodb，内容如下：
dbpath=/mnt/mongodb/rs/data
#数据存放目录
logpath=/mnt/mongodb/rs/logs/mongod.log
#日志文件目录
pidfilepath=/mnt/mongodb/rs/mongod.pid
#pid端口文件
port=12345
#mongodb端口
logappend=true
#追加方式写日志文件
journal=true
#启用日志选项，MongoDB的数据操作将会写入到journal文件夹的文件里
oplogSize=2048
#同步操作记录文件大小(MB)
smallfiles=true
#使用较小的默认文件
replSet=dbset
#副本集名称，同一个副本集，名称必须一致
保存退出后，再进入到bin目录下执行：
./mongod -f ../mongod.conf
"info" : "Config now saved locally.
Should come online in about a minute.",
即运行mongodb成功。
如果有多台机器的话，只需重复以上步骤。
如果同一个机器的话，则仅需要将mongod.conf文件作出相应的更改，如更改数据，日志，pid文件，端口等，但replSet的名称必须一致。
创建集合
登录到其中一台已经成功运行mongodb的机器，
cd /usr/local/bin/mongodb2.6/bin
./mongo 127.0.0.1:12345/admin
登录进去，输入以下命令：
config={_id : 'dbset',members : [{_id : 1, host : '192.168.0.1:12345'},{_id : 2, host : '192.168.0.2:12345'},{_id : 3, host : '192.168.0.3:12345'}]}
回车后再输入
rs.initiate(config); #初始化副本集
以上例子，说明一共有三台机器做副本集，并可以用rs.help()来查看rs下有什么命令可以用。
退出，再重新登录，发现提示符已经发生变化，再输入rs.status()可以查看当前的状态。
其中：
"health" : 1, #代表机器正常
"stateStr" : "PRIMARY",& #代表是主节点，可读写，其中有以下几下状态
1. STARTUP：刚加入到复制集中，配置还未加载
2. STARTUP2：配置已加载完，初始化状态
3. RECOVERING：正在恢复，不适用读
4. ARBITER: 仲裁者
5. DOWN：节点不可到达
6. UNKNOWN：未获取其他节点状态而不知是什么状态，一般发生在只有两个成员的架构，脑裂
7. REMOVED：移除复制集
8. ROLLBACK：数据回滚，在回滚结束时，转移到RECOVERING或SECONDARY状态
9. FATAL：出错。查看日志grep “replSet FATAL”找出错原因，重新做同步
10. PRIMARY：主节点
11. SECONDARY：备份节点
至此你应该可以看到一台机为primary,二台机器的状态为secondary, 即完成副本集设置
维护：
添加副本，在登录到主节点下输入：
rs.add("ip:port");
rs.remove("ip:port");
前提是这个ip:port必须是使用了同一个relpSet名称的mongodb实例即可
db.addUser("username","password");
需要在主节点和从节点上的local数据库下，建个相同的用户名和密码的用户，可读写。 从节点连接主节点时，会用存储在local.system.users中的用户进行认证，最先尝试用repl用户，若没有，则用local.system.users中的第一个可用用户。（但网上有些人说会对效率产生影响，这个待验证。知道的朋友请跟帖说一下。谢谢！）
问题：
按以上完成后，导入原有数据后，导入命令
mongorestore -h 127.0.0.1:12345 -d syt --directoryperdb /mnt/mongo_data/
其中/mnt/mongo_data为要导入的json文件，后发现从节点都变成recovering状态。
问题原因
出现这个问题的原因主要是secondary节点同步oplog的速度追不上primary几点的速度，造成一直处于recovering状态。
解决办法：
&&& 首先停掉从节点mongod进程，然后删除目录(rs)下面所有的数据，然后重启mongod进程，这里有一点需要注意，如果有arbiter的mongod进程也需要停掉，启动的时候，先启动replSet的mongod进程，再启动arbiter的mongod进程，启动之后,会自动由recovering状态切换为startup2状态，最后切换为secondary状态
第二种办法就是先将recovering节点下的data目录删除，再将primary里的data都拷贝到该节点下，再重启就好了！操作前，务必要停止所有的mongodb数据库！
当正在startup2状态时，可以查看mongodb.log文件，发现正在不断地导入数据。当出现
[rsHealthPoll] replSet member 192.168.0.2:12345 is now in state SECONDARY
时，说明已经完成导入，状态也变为secondary了。
另一个解决办法是：
&&& 先对主节点机器完成数据导入，再设置为副本集的节点，即上述的步骤不需要重复操作。待数据完成导入，再操作
replica set权限认证
权限认证搞了一天，搞书本上说的须在每个节点上的local数据库里加入repl这个用户，然后在启动的时候加入 --auth参数，开启权限认证，如果经过测试，是不行的。不知道是那里出问题，具体情况是：当启动一个是时候，另外的节点就会全部变成"stateStr" : "(not reachable/healthy)"这样的状态。
后来经过长时间的百度，google，还是google给力，说要用到keyFile这个参数，于是上官网那里看，要生一个keyfile文件，用于节点之间权限认证的。按官网的提示作以下操作：
mkdir -p /mnt/mongodb/rs/config
cd /mnt/mongodb/rs/config
openssl rand -base64 741 & mongodb-keyfile
chmod 300 mongodb-keyfile
官网上的是600的，必须要改为300，如果不是的话， 会在启动的时候mongodb.log里写权限太开放的原因导致启动mongodb失败！切记切记！这里也花了不少时间...
这里先确保你已经安装了openssl，如果没有装,yum install openssl
将mongodb-keyfile 个问题复制到每一个节点对应的目录下，如果之前已经启动的mongodb的话,用mongo进入到终端后，先查看那个节点是主节点，rs.status(); 去到主节点下执行：
#选择需要认证的数据
db.addUser('name','password');
当然，也可以某一个自建的库进行权限认证
db.addUser('test','123456');
提示添加成功后，全部停止，每一节点执行db.shutdownServer();然后对mongod.conf文件添加以下两行：
keyFile=/mnt/mongodb/rs/confile/mongodb-keyfile
最后全部重启即可！
进入主节点终端，输入
db.runCommand({getLastError:1, w: N});
如果没有N，或者小于2，命令就会立刻返回，如果N等于2，主节点要等到至少一个从节点复制了上个操作都会响应命令（主节点本身也包括在N里面）。主节点使用local.slaves中存放的"syncedTo"信息来跟踪从节点的更新情况。
当指定"w"选项后，还可以使用"wtimeout"选项，表示以毫秒为单位的超时。getLastError就能在上一个操作复制到N个节点超时时返回错误(默认情况下命令是没有超时的)。
阻塞复制会导致写操作明显变慢，尤其是"w"的值比较大时。实际上，对于重要的操作将其值设置为2或者3就能效率与安全兼备了。
mongod的主要参数有：
------------------------------------基本配置----------------------
# 安静输出
--port arg
# 指定服务端口号，默认端口27017
--bind_ip arg
# 绑定服务IP，若绑定127.0.0.1，则只能本机访问，不指定默认本地所有IP
--logpath arg
# 指定MongoDB日志文件，注意是指定文件不是目录
--logappend
# 使用追加的方式写日志
--pidfilepath arg
# PID File 的完整路径，如果没有设置，则没有PID文件
--keyFile arg
# 集群的私钥的完整路径，只对于Replica Set 架构有效
--unixSocketPrefix arg
# UNIX域套接字替代目录,(默认为 /tmp)
# 以守护进程的方式运行MongoDB，创建服务器进程
# 启用验证
# 定期显示CPU的CPU利用率和iowait
--dbpath arg
# 指定数据库路径
--diaglog arg
# diaglog选项 0=off 1=W 2=R 3=both 7=W+some reads
--directoryperdb
# 设置每个数据库将被保存在一个单独的目录
# 启用日志选项，MongoDB的数据操作将会写入到journal文件夹的文件里
--journalOptions arg
# 启用日志诊断选项
# 启用IPv6选项
# 允许JSONP形式通过HTTP访问（有安全影响）
--maxConns arg
# 最大同时连接数 默认2000
# 不启用验证
--nohttpinterface
# 关闭http接口，默认关闭27018端口访问
--noprealloc
# 禁用数据文件预分配(往往影响性能)
--noscripting
# 禁用脚本引擎
--notablescan
# 不允许表扫描
--nounixsocket
# 禁用Unix套接字监听
--nssize arg (=16)
# 设置信数据库.ns文件大小(MB)
--objcheck
# 在收到客户数据,检查的有效性，
--profile arg
# 档案参数 0=off 1=slow, 2=all
# 限制每个数据库的文件数，设置默认为8
--quotaFiles arg
# number of files allower per db, requires --quota
# 开启简单的rest API
# 修复所有数据库run repair on all dbs
--repairpath arg
# 修复库生成的文件的目录,默认为目录名称dbpath
--slowms arg (=100)
# value of slow for profile and console log
--smallfiles
# 使用较小的默认文件
--syncdelay arg (=60)
# 数据写入磁盘的时间秒数(0=never,不推荐)
# 打印一些诊断系统信息
# 如果需要升级数据库
-----------------------------------Replicaton 参数--------------------
--fastsync
# 从一个dbpath里启用从库复制服务，该dbpath的数据库是主库的快照，可用于快速启用同步
--autoresync
# 如果从库与主库同步数据差得多，自动重新同步，
--oplogSize arg
# 设置oplog的大小(MB)
---------------------------------* 主/从参数-------------------------
# 主库模式
# 从库模式
--source arg
# 从库 端口号
--only arg
# 指定单一的数据库复制
--slavedelay arg
# 设置从库同步主库的延迟时间
-----------------------------------Replica set(副本集)选项----------------------
--replSet arg
# 设置副本集名称
-----------------------------------Sharding(分片)选项------------------------
--configsvr
# 声明这是一个集群的config服务,默认端口27019，默认目录/data/configdb
--shardsvr
# 声明这是一个集群的分片,默认端口27018
--noMoveParanoia
# 关闭偏执为moveChunk数据保存
# 上述参数都可以写入 mongod.conf 配置文档里例如：
dbpath = /data/mongodb
logpath = /data/mongodb/mongodb.log
logappend = true
port = 27017
fork = true
auth = true
下载次数: 23
浏览 20602
看着挺有技术。可这段，您这文章是自己写的？不懂Linux？文件权限，你一点不了解？官网上的是600的，必须要改为300，如果不是的话， 会在启动的时候mongodb.log里写权限太开放的原因导致启动mongodb失败！切记切记！这里也花了不少时间... 600是对的。 读写权限。其实那文件只读就可以了。可是这300，写跟执行？没用处吧。如果我没记错的话，log里的确是报这个异常的，你可以试试
浏览: 689138 次
来自: 被遗忘的角落...
今天刚遇到这个问题，正好解决了，谢谢！
你的问题怎么解决的，我的是出现了部分回滚的情况。我这边的情况是 ...
最后一句话救了 我
DEFAULT_ERROR(10000, & ...Mongodb副本集理论详解
Mongodb副本集理论详解
编辑日期： 字体：
副本集是一组服务器，其中有一个是主服务器，其余的都是备份服务器，备份服务器只能读不能写。服务器之间通过心跳信息监测彼此是否在线。还需强调一点 一个副本集最多有12个节点，但是同时最多只有其中的7个节点可以进行投票。
一、副本集成员介绍
在复制集中唯一的一个接受写请求的节点，并将写的操作记录到oplog中，供从节点使用
复制主节点的oplog文件并异步的将这些操作应用到自身上，以此保证和主节点的数据集一致。。
投票节点没有数据，只是用来选举主服务器的，投票节点的存在使得复制集可以以偶数个节点存在，而无需为复制集再新增节点。
优先级为0的节点
&永远不能成为主节点，并且不能触发选举，但是具有投票权，并且拥有与主节点一致的数据集，能接受读请求
复制主节点的oplog，并应用到本地保存一致的数据集，但是对于应用程序是隐藏的
是一个优先级为0的节点，永远不能成为主节点，选举时也可以投票
从主节点同步数据，但是要比其他节点的数据要延后。（误操作时能用到）
一个复制集至少需要这几个成员：一个&主节点&，一个&从节点&，和一个&投票节点&。但是在大多数情况下，我们会保持3个拥有数据集的节点：一个&主节点&和两个&从节点&。
二、复制集的高可用
2.1、触发选举的条件
复制集初始化
主节点挂掉
主节点脱离副本集（可能是网络原因）
参与选举的节点数量必须大于副本集总节点数量的一半，如果已经小于一半了所有节点保持只读状态。
2.1、复制集主节点的选举
成员的优先级，优先级越高的从节点越有机会成为主节点
成员不是投票节点，优先级不能为0
成员的opTime不能落后于最新节点10s以上，越接近主节点的时间越有可能成为主节点
2.2、自动化故障切换
复制集成员每2秒向复制集中其他成员进行心跳检测。如果某个节点在10秒内没有返回，那么它将被标记为不可用，开始选举出新的主服务器
三、复制集成员个数
官方说复制集中最好是有奇数个成员，如果有偶数个节点，那就加一个投票节点吧，但是我曾经测试的时候发现偶数个节点也是可以。一直都搞不明白为什么必须是奇数，后来发现我们是不是应该站在更高的角度去看，Mongodb的副本集完全可以跨IDC的的分布式数据库，这里我们举个例子就明白了，假如我们有6个节点，有3个节点放在北京的IDC另3个放在天津的IDC，加入北京IDC到天津IDC这条线路出现问题了，我们在上面提到过触发选举的条件，此时主节点已经脱离了副本集，那么就应该开始选举了，我们现在的情况是每个IDC都有3个节点，不满足节点数量必须大于副本集总节点数量的一半的条件，主节点无法选举出来。 这样大家应该明白了吧，为什么官方说必须是奇数个节点，如果不是需要增加一个投票节点！
理论点就到此结束，下面开始副本集的配置
一、实验环境
Centos 6.5
IP：192.168.1.92 &hostname ：tshare365-master
IP：192.168.1.87 &hostname ：tshare365-slave1
IP：192.168.1.87 &hostname ：tshare365-slave2
二、Mongodb的安装
请参照我之前的博客
三、创建数据目录并启动Mongodb服务（在3台服务器上都执行相同的操作）
mkdir&-pv&/data/{mongodb,log}
/usr/local/mongodb/bin/mongod&--dbpath&/data/mongodb/&--logpath&/data/log/mongodb.log&--logappend&&--replSet&tshare365&&--fork
四、初始化副本集（在master服务器上）
[root@tshare365-master&~]#&/usr/local/mongodb/bin/mongo
MongoDB&shell&version:&2.4.12
connecting&to:&test
Welcome&to&the&MongoDB&shell.
For&interactive&help,&type&&help&.
For&more&comprehensive&documentation,&see
http://docs.mongodb.org/
Questions?&Try&the&support&group
/group/mongodb-user
&&use&admin
switched&to&db&admin
#定义副本集配置变量，这里的 _id:”tshare365” 和上面命令参数“ –replSet tshare365” 要保持一样。
&&config&=&{&_id:&tshare365&,&members:[
...&...&{_id:0,host:&192.168.1.92:27017&},
...&...&{_id:1,host:&192.168.1.87:27017&},
...&...&{_id:2,host:&192.168.1.54:27017&}]
&_id&&:&&tshare365&,
&members&&:&[
&_id&&:&0,
&host&&:&&192.168.1.92:27017&
&_id&&:&1,
&host&&:&&192.168.1.87:27017&
&_id&&:&2,
&host&&:&&192.168.1.54:27017&
#初始化副本集
&&rs.initiate(config);
&info&&:&&Config&now&saved&locally.&&Should&come&online&in&about&a&minute.&,
五、查看集群节点状态
rs.status()
&set&&:&&tshare365&,
&date&&:&ISODate(&T02:46:22Z&),
&myState&&:&1,
&members&&:&[
&_id&&:&0,
&name&&:&&192.168.1.92:27017&,
&health&&:&1,
&state&&:&1,
&stateStr&&:&&PRIMARY&,
&uptime&&:&584,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:44:54Z&),
&self&&:&true
&_id&&:&1,
&name&&:&&192.168.1.87:27017&,
&health&&:&1,
&state&&:&2,
&stateStr&&:&&SECONDARY&,
&uptime&&:&88,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:44:54Z&),
&lastHeartbeat&&:&ISODate(&T02:46:22Z&),
&lastHeartbeatRecv&&:&ISODate(&T02:46:22Z&),
&pingMs&&:&0,
&syncingTo&&:&&192.168.1.92:27017&
&_id&&:&2,
&name&&:&&192.168.1.54:27017&,
&health&&:&1,
&state&&:&2,
&stateStr&&:&&SECONDARY&,
&uptime&&:&88,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:44:54Z&),
&lastHeartbeat&&:&ISODate(&T02:46:22Z&),
&lastHeartbeatRecv&&:&ISODate(&T02:46:22Z&),
&pingMs&&:&2,
&syncingTo&&:&&192.168.1.92:27017&
tshare365:PRIMARY&
我们看到92是主 87,54都是从，如果输出这样的信息就说明Mongodb主从环境就搭建成功了。下面我们测试一下
六、测试副本数据集复制功能
6.1、在主节点上写入数据
tshare365:PRIMARY&&db.tshare365_info.insert({&name&:&tshare365&,&site&:&&}
tshare365:PRIMARY&&db.tshare365_info.find()
{&&_id&&:&ObjectId(&54f7c50ddd157&),&&name&&:&&tshare365&,&&site&&:&&&&}
tshare365:PRIMARY&
6.2、在从节点上查看数据
[root@tshare365-slave1&/]#&/usr/local/mongodb/bin/mongo
MongoDB&shell&version:&2.4.12
connecting&to:&test
tshare365:SECONDARY&&show&dbs
local 1.078125GB
tshare365 0.203125GB
tshare365:SECONDARY&&use&tshare365
switched&to&db&tshare365
tshare365:SECONDARY&&show&collections
Wed&Feb&25&21:58:03.242&error:&{&&$err&&:&&not&master&and&slaveOk=false&,&&code&&:&13435&}&at&src/mongo/shell/query.js:128
tshare365:SECONDARY&&db.tshare365_info.find()
error:&{&&$err&&:&&not&master&and&slaveOk=false&,&&code&&:&13435&}
tshare365:SECONDARY&
What，我们查看数据的时候报错了，这是什么情况？ 在Mongodb副本集中默认都是从主节点上读写数据的，所以这里会出现这样的错误信息，在数据库的读写分离的场景中，我们需要将从库设置成可读的模式
6.3、Mongodb默认是从主节点读写数据的，副本节点上不允许读，需要设置副本节点可以读（在两台从服务器都是需要设置哦）
tshare365:SECONDARY&&db.getMongo().setSlaveOk();
tshare365:SECONDARY&&db.tshare365_info.find()
{&&_id&&:&ObjectId(&54f7c50ddd157&),&&name&&:&&tshare365&,&&site&&:&&&&}
tshare365:SECONDARY&
到此我们看到副本集数据复制是正常的，下面我们就测试一下副本集最牛X的功能，故障自动化转移！
七、测试副本集故障转移
7.1、模拟故障环境
#手动关闭主节点
[root@tshare365-master&~]#&killall&mongod
7.2、在次查看集群状态
[root@tshare365-slave1&~]#&/usr/local/mongodb/bin/mongo
MongoDB&shell&version:&2.4.12
connecting&to:&test
tshare365:SECONDARY&&rs.status()
&set&&:&&tshare365&,
&date&&:&ISODate(&T14:17:01Z&),
&myState&&:&2,
&syncingTo&&:&&192.168.1.54:27017&,
&members&&:&[
&_id&&:&0,
&name&&:&&192.168.1.92:27017&,
&health&&:&0,
&state&&:&8,
&stateStr&&:&&(not&reachable/healthy)&,
&uptime&&:&0,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:53:01Z&),
&lastHeartbeat&&:&ISODate(&T14:17:01Z&),
&lastHeartbeatRecv&&:&ISODate(&T14:09:44Z&),
&pingMs&&:&0
&_id&&:&1,
&name&&:&&192.168.1.87:27017&,
&health&&:&1,
&state&&:&2,
&stateStr&&:&&SECONDARY&,
&uptime&&:&2233,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:53:01Z&),
&self&&:&true
&_id&&:&2,
&name&&:&&192.168.1.54:27017&,
&health&&:&1,
&state&&:&1,
&stateStr&&:&&PRIMARY&,
&uptime&&:&1812,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:53:01Z&),
&lastHeartbeat&&:&ISODate(&T14:17:00Z&),
&lastHeartbeatRecv&&:&ISODate(&T14:17:00Z&),
&pingMs&&:&0,
&syncingTo&&:&&192.168.1.92:27017&
tshare365:SECONDARY&
我们发现1.92的health 状态变成0，说明心跳信息已经检测不到了 集群通过投票选举出了新的主节点1.54，我们发现故障转移是成功的，是不是感觉很强大呢。
7.3、我们启动1.92原来的主节点，查看集群的状态
我们查看从节点的日志发现1.92重新回归集群，并且成为了从节点，看到状态是STARTUP2
Wed&Feb&25&22:21:53.625&[rsHealthPoll]&replSet&member&192.168.1.92:27017&is&up
Wed&Feb&25&22:21:53.625&[rsHealthPoll]&replSet&member&192.168.1.92:27017&is&now&in&state&STARTUP2
Wed&Feb&25&22:21:55.627&[rsHealthPoll]&replSet&member&192.168.1.92:27017&is&now&in&state&SECONDARY
Wed&Feb&25&22:22:07.606&[conn125]&end&connection&192.168.1.92:7962&(2&connections&now&open)
查看集群状态
tshare365:PRIMARY&&rs.status()
&set&&:&&tshare365&,
&date&&:&ISODate(&T11:22:41Z&),
&myState&&:&1,
&members&&:&[
&_id&&:&0,
&name&&:&&192.168.1.92:27017&,
&health&&:&1,
&state&&:&2,
&stateStr&&:&&SECONDARY&,
&uptime&&:&157,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:53:01Z&),
&lastHeartbeat&&:&ISODate(&T11:22:40Z&),
&lastHeartbeatRecv&&:&ISODate(&T11:22:40Z&),
&pingMs&&:&0,
&syncingTo&&:&&192.168.1.54:27017&
&_id&&:&1,
&name&&:&&192.168.1.87:27017&,
&health&&:&1,
&state&&:&2,
&stateStr&&:&&SECONDARY&,
&uptime&&:&2267,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:53:01Z&),
&lastHeartbeat&&:&ISODate(&T11:22:41Z&),
&lastHeartbeatRecv&&:&ISODate(&T11:22:41Z&),
&pingMs&&:&0,
&syncingTo&&:&&192.168.1.54:27017&
&_id&&:&2,
&name&&:&&192.168.1.54:27017&,
&health&&:&1,
&state&&:&1,
&stateStr&&:&&PRIMARY&,
&uptime&&:&2627,
&optime&&:&Timestamp(,&1),
&optimeDate&&:&ISODate(&T02:53:01Z&),
&self&&:&true
tshare365:PRIMARY&
到此故障转移就测试完了，感觉副本集的配置很easy呀！
我们在查看日志的时候看到一个1.92的状态是STARTUP2，下面我详解介绍一下服务器的状态
八、服务器状态
STARTUP：刚加入到复制集中，配置还未加载
STARTUP2：配置已加载完，初始化状态
RECOVERING：正在恢复，不适用读
ARBITER: 仲裁者
DOWN：节点不可到达
UNKNOWN：未获取其他节点状态而不知是什么状态，一般发生在只有两个成员的架构，脑裂
REMOVED：移除复制集
ROLLBACK：数据回滚，在回滚结束时，转移到RECOVERING或SECONDARY状态
FATAL：出错。查看日志grep “replSet FATAL”找出错原因，重新做同步
PRIMARY：主节点
SECONDARY：备份节点
本博客到此结束，感觉副本集的配置还是很简单的，注意是副本集的理论知识，尤其是选举主节点的过程，希望大家好好理解，如果有什么问题，请留言！
本文固定链接:
转载请注明:
作者：tshare365
这个作者貌似有点懒，什么都没有留下。
您的支持是博主写作最大的动力，如果您喜欢我的文章，感觉我的文章对您有帮助，请狠狠点击
您可能还会对这些文章感兴趣！