MongoDB 副本集(类似高可用)
1.节点类型
standard：常规节点，它存储一份完整的数据副本，参与选举投票，有可能成为活跃节点。
passive：存储了完整的数据副本，参与投票，不能成为活跃节点。
arbiter：仲裁节点，只参与投票，不接收复制的数据，也不能成为活跃节点。
2.参数说明
--dbpath 数据文件路径
--logpath 日志文件路径
--port 端口号，默认是27017.我这里使用的也是这个端口号.
--replSet 复制集的名字，一个replica sets中的每个节点的这个参数都要用一个复制集名字，这里是1905.
--replSet 这个后面跟的是其他standard节点的ip和端口
--maxConns 最大连接数
--fork 后台运行
--logappend 日志文件循环使用，如果日志文件已满，那么新日志覆盖最久日志。
3.创建副本集
环境说明:
ip:192.168.3.206 #standard节点
ip:192.168.3.210 #standard节点
ip:192.168.3.201 #仲裁节点
4.安装方法
参照http://blog.csdn.net/liu331095659/article/details/37870323来安装。安装成功后，不要用博客上面的启动命令。
5.启动方法
启动第一个standard节点（ip:192.168.3.206)
/usr/local/mongodb/bin/mongod --dbpath=/data/mongodb/ --logpath /data/logs/mongodb/log.log --logappend --port=27017 -replSet 1905 -maxConns=2000 -fork
启动第一个standard节点（ip:192.168.3.210)
/usr/local/mongodb/bin/mongod --dbpath=/data/mongodb/ --logpath /data/logs/mongodb/log.log --logappend --port=27017 -replSet 1905 -maxConns=2000 -fork
启动arbiter节点，也就是仲裁节点 （ip:192.168.3.201)
/usr/local/mongodb/bin/mongod --dbpath=/data/mongodb/ --logpath /data/logs/mongodb/log.log --logappend --port=27017 -replSet 1905 -maxConns=2000 -fork
6.shell初始化副本集
启动了以上服务器后，日志告诉你副本集没有初始化。
连接其中一台standard(192.168.3.206)节点服务器。初始化命令只能执行一次
db.runCommand({"replSetInitiate" : {
"_id" : "1905",
"members" : [
{
"_id" : 0,
"host" : "192.168.3.206:27017"
},
{
"_id" : 1,
"host" : "192.168.3.210:27017"
}
]}})
rs.status()
{
"startupStatus" : 3,
"info" : "run rs.initiate(...) if not yet done for the set",
"ok" : 0,
"errmsg" : "can‘t get local.system.replset config from self or any seed (EMPTYCONFIG)"
}
如果通过rs.status()得到上面结果。说明还没有得到副本集合的配置信息，然后执行下面语句
config_rs={_id:‘1905‘,members:[{_id:0,host:‘192.168.3.206:27017‘},{_id:1,host:‘192.168.3.210:27017‘}]}
rs.initiate(config_rs);
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}
表示已经得到副本集合了。
7.测试副本集
7.1查看副本集合
rs.status()
{
"set" : "1905",
"date" : ISODate("2014-07-16T03:11:53Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "192.168.3.206:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 4777,
"optime" : Timestamp(1405480230, 1),
"optimeDate" : ISODate("2014-07-16T03:10:30Z"),
"electionTime" : Timestamp(1405480240, 1),
"electionDate" : ISODate("2014-07-16T03:10:40Z"),
"self" : true
},
{
"_id" : 1,
"name" : "192.168.3.210:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 81,
"optime" : Timestamp(1405480230, 1),
"optimeDate" : ISODate("2014-07-16T03:10:30Z"),
"lastHeartbeat" : ISODate("2014-07-16T03:11:53Z"),
"lastHeartbeatRecv" : ISODate("2014-07-16T03:11:53Z"),
"pingMs" : 0,
"syncingTo" : "192.168.3.206:27017"
}
],
"ok" : 1
}
7.2加入仲裁节点
执行以下命令：
rs.addArb("192.168.3.201:27017");
{ "ok" : 1 }
我们可以再次查看当前状态：
rs.status()
{
"set" : "1905",
"date" : ISODate("2014-07-16T03:18:58Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "192.168.3.206:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 5202,
"optime" : Timestamp(1405480659, 1),
"optimeDate" : ISODate("2014-07-16T03:17:39Z"),
"electionTime" : Timestamp(1405480240, 1),
"electionDate" : ISODate("2014-07-16T03:10:40Z"),
"self" : true
},
{
"_id" : 1,
"name" : "192.168.3.210:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 506,
"optime" : Timestamp(1405480659, 1),
"optimeDate" : ISODate("2014-07-16T03:17:39Z"),
"lastHeartbeat" : ISODate("2014-07-16T03:18:58Z"),
"lastHeartbeatRecv" : ISODate("2014-07-16T03:18:58Z"),
"pingMs" : 0,
"syncingTo" : "192.168.3.206:27017"
},
{
"_id" : 2,
"name" : "192.168.3.201:27017",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 79,
"lastHeartbeat" : ISODate("2014-07-16T03:18:57Z"),
"lastHeartbeatRecv" : ISODate("2014-07-16T03:18:58Z"),
"pingMs" : 0
}
],
"ok" : 1
}
rs.status()通过这个命令，可以查看各个节点的ip、角色已经是否正常
我们看到已经成功配置。
7.3查看活跃节点：
db.isMaster();
{
"setName" : "1905",
"setVersion" : 2,
"ismaster" : true,
"secondary" : false,
"hosts" : [
"192.168.3.206:27017",
"192.168.3.210:27017"
],
"arbiters" : [
"192.168.3.201:27017"
],
"primary" : "192.168.3.206:27017",
"me" : "192.168.3.206:27017",
"maxBsonObjectSize" : 16777216,
"maxMessageSizeBytes" : 48000000,
"maxWriteBatchSize" : 1000,
"localTime" : ISODate("2014-07-16T03:23:18.798Z"),
"maxWireVersion" : 2,
"minWireVersion" : 0,
"ok" : 1
}
可以看到现在192.168.3.206:27017为活跃节点。
检测是否配置成功
7.4模拟故障
可以强制primary和standard节点角色互换，从而验证是否能够实现副本集功能
进入主节点后执行下面命令
rs.stepDown()
执行完成后：
db.isMaster()
{
"setName" : "1905",
"setVersion" : 2,
"ismaster" : false,
"secondary" : true,
"hosts" : [
"192.168.3.206:27017",
"192.168.3.210:27017"
],
"arbiters" : [
"192.168.3.201:27017"
],
"primary" : "192.168.3.210:27017",
"me" : "192.168.3.206:27017",
"maxBsonObjectSize" : 16777216,
"maxMessageSizeBytes" : 48000000,
"maxWriteBatchSize" : 1000,
"localTime" : ISODate("2014-07-16T03:43:25.102Z"),
"maxWireVersion" : 2,
"minWireVersion" : 0,
"ok" : 1
}
可以看到现在主节点已经修改为192.168.3.210:27017了。
8.动态扩展增加节点
为了节约服务器，我们在ip:192.168.3.210上面重新增加端口27027为standard节点
mkdir -p /data/mongodb1 #27027端口数据目录
mkdir -p /data/logs/mongodb1/ #27027端口日志目录
#启动27027端口standard节点
/usr/local/mongodb/bin/mongod --dbpath=/data/mongodb1/ --logpath /data/logs/mongodb1/log.log --logappend --port=27027 -replSet 1905 -maxConns=2000 -fork
进入活跃节点的服务器
rs.add("192.168.3.210:27027");
{ "ok" : 1 }
我们可以再次查看当前状态：
rs.status()
{
"set" : "1905",
"date" : ISODate("2014-07-16T05:55:37Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "192.168.3.206:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 838,
"optime" : Timestamp(1405490134, 1),
"optimeDate" : ISODate("2014-07-16T05:55:34Z"),
"electionTime" : Timestamp(1405489678, 1),
"electionDate" : ISODate("2014-07-16T05:47:58Z"),
"self" : true
},
{
"_id" : 1,
"name" : "192.168.3.210:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 314,
"optime" : Timestamp(1405490134, 1),
"optimeDate" : ISODate("2014-07-16T05:55:34Z"),
"lastHeartbeat" : ISODate("2014-07-16T05:55:36Z"),
"lastHeartbeatRecv" : ISODate("2014-07-16T05:55:37Z"),
"pingMs" : 0,
"syncingTo" : "192.168.3.206:27017"
},
{
"_id" : 2,
"name" : "192.168.3.201:27017",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 836,
"lastHeartbeat" : ISODate("2014-07-16T05:55:35Z"),
"lastHeartbeatRecv" : ISODate("2014-07-16T05:55:35Z"),
"pingMs" : 0
},
{
"_id" : 3,
"name" : "192.168.3.210:27027",
"health" : 1,
"state" : 5,
"stateStr" : "STARTUP2",
"uptime" : 3,
"optime" : Timestamp(0, 0),
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2014-07-16T05:55:36Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : 0
}
],
"ok" : 1
}
已经出现192.168.3.210:27027说明动态增加节点成功。
9.动态扩展删除节点
进入活跃节点的服务器
rs.remove("192.168.3.210:27027");
2014-07-16T14:00:10.118+0800 DBClientCursor::init call() failed
2014-07-16T14:00:10.119+0800 Error: error doing query: failed at src/mongo/shell/query.js:81
2014-07-16T14:00:10.121+0800 trying reconnect to 127.0.0.1:27017 (127.0.0.1) failed
2014-07-16T14:00:10.122+0800 reconnect 127.0.0.1:27017 (127.0.0.1) ok
我们可以再次查看当前状态：
rs.status()
{
"set" : "1905",
"date" : ISODate("2014-07-16T06:00:31Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "192.168.3.206:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1132,
"optime" : Timestamp(1405490410, 1),
"optimeDate" : ISODate("2014-07-16T06:00:10Z"),
"electionTime" : Timestamp(1405489678, 1),
"electionDate" : ISODate("2014-07-16T05:47:58Z"),
"self" : true
},
{
"_id" : 1,
"name" : "192.168.3.210:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 21,
"optime" : Timestamp(1405490410, 1),
"optimeDate" : ISODate("2014-07-16T06:00:10Z"),
"lastHeartbeat" : ISODate("2014-07-16T06:00:30Z"),
"lastHeartbeatRecv" : ISODate("2014-07-16T06:00:29Z"),
"pingMs" : 0,
"lastHeartbeatMessage" : "syncing to: 192.168.3.206:27017",
"syncingTo" : "192.168.3.206:27017"
},
{
"_id" : 2,
"name" : "192.168.3.201:27017",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 21,
"lastHeartbeat" : ISODate("2014-07-16T06:00:30Z"),
"lastHeartbeatRecv" : ISODate("2014-07-16T06:00:30Z"),
"pingMs" : 2
}
],
"ok" : 1
}
192.168.3.210:27027已经没有出现在副本集合里面，说明删除节点成功。
10.为主节点模拟写数据
10.1在主节点上面操作
use mytest
> db.test03.insert({age:26})
WriteResult({ "nInserted" : 1 })
> db.test03.find()
{ "_id" : ObjectId("53c4f9dd7f7a3afaa3dd2415"), "age" : 26 }
10.2在从节点上面操作
show dbs;
admin (empty)
local 1.078GB
mytest 0.078GB
#mytest数据库已经自动同步OK
show tables;
2014-07-16T14:17:21.849+0800 error: { "$err" : "not master and slaveOk=false", "code" : 13435 } at src/mongo/shell/query.js:131
#上面提示从节点不能读，所以不能查看集合。
rs.slaveOk() #执行此命令允许从节点可以读取，但是不能写。
show tables;
system.indexes
test03
db.test03.find()
{ "_id" : ObjectId("53c60edaf2c66b02d9c99338"), "age" : 26 }
MongoDB 副本集(类似高可用) [三]
时间： 2024-10-18 02:53:08
MongoDB 副本集(类似高可用) [三]的相关文章
[ MongoDB ] 副本集的搭建及测试
Replica Sets 复制 (副本集) node1: 10.0.0.10node2: 10.0.0.11node3: 10.0.0.12 副本集结构图: MongoDB程序,配置文件,启动脚本地址:链接:http://pan.baidu.com/s/1hslX7Ju 密码:jlei node1 部署: # 拷贝到其他两个节点上. [[email protected] ~]# scp mongodb-linux-x86_64-rhel62-3.2.8.tgz 10.0.0.11:/root/
MongoDB 副本集的相关概念【转】
一.副本集基本概念 副本集(replica set) MongoDB的replica set是一个mongod进程实例簇,数据在这个簇中相互复制,并自动进行故障切换. MongoDB的数据库复制增加了冗余,确保了高可用性,简化了管理任务如备份,并且增加了读能力.大多数产品部署都使用了复制.MongoDB中primary处理写操作,其它进行复制的成员则是secondaries. 一个副本集可以最多支持12个成员,但是只有7个成员可以参与投票. 注:MongoDB同时提供了传统的master/sla
MongoDB副本集搭建及备份恢复
一.MongoDB副本集(repl set)介绍 早起版本使用master-slave,一主一从和MySQL类似,但slave在此架构中为只读,当主库宕机后,从库不能自动切换为主: 目前已经淘汰了master-slave模式,改为副本集,这种模式下有一个主(primary),和多个从(secondary),只读,支持给他们设置权重,当主宕掉后,权重最高的从切换为主: 在此架构中还可以建立一个仲裁(arbiter)的角色,它只负责裁决,而不存储数据 在此架构中读写数据都是在主上,要想实现负载均衡的
MongoDB副本集
简介 mongodb复制(replication)是将数据同步在多个服务器的过程.主节点记录在其上的所有操作oplog,从节点定期轮询主节点获取这些操作,然后对自己的数据副本执行这些操作,从而保证从节点的数据与主节点一致.复制提供了数据的冗余备份,并在多个服务器上存储数据副本,提高了数据的可用性,并保证数据的安全性.复制还允许您从硬件故障和服务中断中恢复数据. 而副本集(replica set)是从mongodb 1.6 提供的新功能,比复制功能要强大一些并增加了故障自动切换和自动修复成员节点,
Mongodb副本集实现及读写分离
在前面的文章"Mongodb的主从模式搭建实例"中,我们对如何搭建一个主从结构的Mongodb服务器环境进行了简单的介绍.但是对于主从结构,Mongodb官方并不推荐我们使用了,可能是因为主从模式存在以下两个缺点: (1)主节点不可用之后,无法自动切换到从节点,无法确保业务访问的不间断性: (2)所有的读写操作都是对主节点的,造成主节点的访问压力较大: 因此,Mongodb为我们提供了另外一种推荐的使用方法,那就是使用副本集ReplicaSets.在这篇文章中简单描述一下副本集是如何实
mongodb副本集的内部机制（借鉴lanceyan.com）
针对mongodb的内部机制提出以下几个引导性的问题: 副本集故障转移,主节点是如何选举的?能否手动干涉下架某一台主节点. 官方说副本集数量最好是奇数,为什么? mongodb副本集是如何同步的?如果同步不及时会出现什么情况?会不会出现不一致性? mongodb的故障转移会不会无故自动发生?什么条件会触发?频繁触发可能会带来系统负载加重? Bully算法 mongodb副本集故障转移功能得益于它的选举机制.选举机制采用了Bully算法,可以很方便从分布式节点中选出主节点.一个分布式集群架构中一般
java程序连接MongoDB副本集测试
三个节点有一个节点挂掉也不会影响应用程序客户端对整个副本集的读写! [java] view plaincopy public class TestMongoDBReplSet { public static void main(String[] args) { try { List<ServerAddress> addresses = new ArrayList<ServerAddress>(); ServerAddress address1 = new ServerAddress
mongodb副本集搭建过程中的问题和解决技巧
在我以往的认知中,一个系统一旦正式上线,多半不会轻易的迁移服务器,尤其是那种涉及到多个关联应用,涉及到多台硬件服务器的系统,因为这种迁移将是牵一发而动全身的. 但是,却仍然有这种情况存在,就如我这几天主要负责的事,就是一个系统的全部服务器迁移中的部分机器迁移,还有一部分由别人负责. 这个系统涉及到flume数据采集,storm数据分析,rabbitmq消息分发,ehcache缓存提升系统性能,mongodb副本集存储数据,tomcat管理系统应用等,架构基本如下: 而这里我主要负责的是rabbi
如何配置 MongoDB 副本集
MongoDB 已经成为市面上最知名的 NoSQL 数据库.MongoDB 是面向文档的,它的无模式设计使得它在各种各样的WEB 应用当中广受欢迎.最让我喜欢的特性之一是它的副本集(Replica Set),副本集将同一数据的多份拷贝放在一组 mongod 节点上,从而实现数据的冗余以及高可用性. 这篇教程将向你介绍如何配置一个 MongoDB 副本集. 副本集的最常见配置需要一个主节点以及多个副节点.这之后启动的复制行为会从这个主节点到其他副节点.副本集不止可以针对意外的硬件故障和停机事件对数