mongodb集群(replication)

三台机器: 172.7.15.111(primary)   172.7.15.112(secondary)    172.7.15.101(secondary) 
编辑三台机器的配置文件,增加:
replication:
##oplog大小
oplogSizeMB: 20

##复制集名称

replSetName: aminglinux

分别重启后,连接primary机器
mongo

>use admin

>config={_id:"aminglinux",members:[{_id:0,host:"192.168.10.10:27017"},{_id:1,host:"192.168.10.11:27017"},{_id:2,host:"192.168.10.12:27017"}]}

>rs.initiate(config)     //如果初始化报错,需要注释掉配置文件的    "bind_ip = 127.0.0.1"

>rs.add("172.7.15.112")
>rs.add("172.7.15.101")
查看状态:
>rs.status()
{
"set" : "aminglinux",
"date" : ISODate("2015-10-19T06:32:09.200Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "localhost.localdomain:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1381,
"optime" : Timestamp(1445235074, 1),
"optimeDate" : ISODate("2015-10-19T06:11:14Z"),
"electionTime" : Timestamp(1445234949, 1),
"electionDate" : ISODate("2015-10-19T06:09:09Z"),
"configVersion" : 3,
"self" : true
},
{
"_id" : 1,
"name" : "172.7.15.112:27017",
"health" : 1,
"state" : 0,
"stateStr" : "STARTUP",
"uptime" : 1268,
"optime" : Timestamp(0, 0),
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2015-10-19T06:32:07.764Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : 1,
"configVersion" : -2
},
{
"_id" : 2,
"name" : "172.7.15.101:27017",
"health" : 1,
"state" : 0,
"stateStr" : "STARTUP",
"uptime" : 1255,
"optime" : Timestamp(0, 0),
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2015-10-19T06:32:07.930Z"),
"lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
"pingMs" : 1,
"configVersion" : -2
}
],
"ok" : 1
}

这个状态是不对的,正常从节点上应该是SECONDARY,而不是STARTUP
解决该问题,需要在主节点执行
> var config={_id:"aminglinux",members:[{_id:0,host:"172.7.15.111:27017"},{_id:1,host:"172.7.15.112:27017"},{_id:2,host:"172.7.15.101:27017"}]}
>rs.reconfig(config)
再次执行
>rs.status() 
发现状态好了

测试:
主上建库,建集合
>use mydb
>db.acc.insert({AccountID:1,UserName:"123",password:"123456"})            
>show tbs
>show tables

从上测试

>show dbs    //也出现mydb库了。

//报错的话,需要执行rs.slaveOk()

在生成环境中,我们需要找一个从节点作为自动切换节点,当主节点宕机后,它会自动接管主的服务,成为主节点,当主恢复后还会自动切换回原来的身份。所以,我们应该这样配置:

cfg = rs.conf()
cfg.members[0].priority = 3
cfg.members[1].priority = 2
cfg.members[2].priority = 1
rs.reconfig(cfg)这样的话,第二个节点将会成为候选主节点。

iptables -I INPUT -p tcp --dport 27017 -j DROP  禁掉主

6. mongodb 备份与恢复
1) 备份指定库
mongodump  -h ip -d dbname -o dir  //-h后面跟服务器ip,-d后面跟database名字,不加则备份所有库,-o后面指定备份到哪里

2)备份所有库
mongodump -h ip -o dir

3) 备份指定集合
mongodump -d mydb -c testc -o /tmp/testc   //用-c指定集合名字

4)恢复所有库
mongorestore  --drop dir/   //其中dir是备份所有库的目录名字,其中--drop可选,意思是当恢复之前先把之前的数据删除,不建议使用

5) 恢复指定库
mongorestore -d mydb dir/ //-d跟要恢复的库名字,dir就是该库备份时所在的目录

6)恢复集合
mongorestore -d mydb -c testc  dir/mydb/testc.bson  // -c后面跟要恢复的集合名字,dir是备份mydb库时生成文件所在路径,这里需要跟一个bson文件的路径

7)导出集合为json文件
mongoexport -d mydb -c testc -o /tmp/testc.json

8)导入集合

mongoimport -d mydb -c testc --file /tmp/testc.json

时间: 2024-10-18 22:16:18

mongodb集群(replication)的相关文章

搭建高可用mongodb集群(二)—— 副本集

http://www.lanceyan.com/tech/mongodb/mongodb_repset1.html 在上一篇文章<搭建高可用MongoDB集群(一)——配置MongoDB> 提到了几个问题还没有解决. 主节点挂了能否自动切换连接?目前需要手工切换. 主节点的读写压力过大如何解决? 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 这篇文章看完这些问题就可以搞定了.NoSQL的产生就是为了解决大数据量.高扩展性.高

搭建高可用mongodb集群—— 分片

从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么行!不行!“分片”就用这个来解决这个问题. 传统数据库怎么做海量数据读写?其实一句话概括:分而治之.上图看看就清楚了,如下 taobao岳旭强在infoq中提到的 架构图: 上图中有个TDDL,是taobao的一

搭建高可用mongodb集群(一)——配置mongodb

搭建高可用mongodb集群(一)--配置mongodb 在大数据的时代,传统的关系型数据库要能更高的服务必须要解决高并发读写.海量数据高效存储.高可扩展性和高可用性这些难题.不过就是因为这些问题Nosql诞生了. NOSQL有这些优势: 大数据量,可以通过廉价服务器存储大量的数据,轻松摆脱传统mysql单表存储量级限制. 高扩展性,Nosql去掉了关系数据库的关系型特性,很容易横向扩展,摆脱了以往老是纵向扩展的诟病. 高性能,Nosql通过简单的key-value方式获取数据,非常快速.还有N

【转】搭建高可用mongodb集群(二)—— 副本集

在上一篇文章<搭建高可用MongoDB集群(一)——配置MongoDB> 提到了几个问题还没有解决. 主节点挂了能否自动切换连接?目前需要手工切换. 主节点的读写压力过大如何解决? 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 这篇文章看完这些问题就可以搞定了.NoSQL的产生就是为了解决大数据量.高扩展性.高性能.灵活数据模型.高可用性.但是光通过主从模式的架构远远达不到上面几点,由此MongoDB设计了副本集和分片的功能

搭建高可用mongodb集群

搭建高可用mongodb集群(一)——配置mongodb Posted on 17 十一月, 2013 by lanceyan | 9条评论 在大数据的时代,传统的关系型数据库要能更高的服务必须要解决高并发读写.海量数据高效存储.高可扩展性和高可用性这些难题.不过就是因为这些问题Nosql诞生了. NOSQL有这些优势: 大数据量,可以通过廉价服务器存储大量的数据,轻松摆脱传统mysql单表存储量级限制. 高扩展性,Nosql去掉了关系数据库的关系型特性,很容易横向扩展,摆脱了以往老是纵向扩展的

mongodb集群化

转自:https://www.cnblogs.com/nulige/p/7613721.html 一.mongodb主从复制配置 主从复制是MongoDB最常用的复制方式,也是一个简单的数据库同步备份的集群技术,这种方式很灵活.可用于备份,故障恢复,读扩展等. 最基本的设置方式就是建立一个主节点和一个或多个从节点,每个从节点要知道主节点的地址.采用双机备份后主节点挂掉了后从节点可以接替主机继续服务.所以这种模式比单节点的高可用性要好很多. 配置主从复制的注意点 1 2 3 1)在数据库集群中要明

搭建mongodb集群(副本集+分片)

完整的搭建mongodb集群(副本集+分片)的例子... 准备四台机器,分别是bluejoe1,bluejoe2,bluejoe3,以及bluejoe0 副本集及分片策略确定如下: 将创建3个副本集,命名为shard1,shard2,shard3: 以上3个副本集作为3个分片: 每个副本集包含2个副本(主.辅): 副本分开存储,即shard1存在bluejoe1和bluejoe2上各一份...以此类推 将创建3个配置库实例,一台机器一个 bluejoe0上配置一个mongos(mongos一般可

搭建高可用MongoDB集群 -分片-good

搭建高可用MongoDB集群(四):分片 http://blog.jobbole.com/72643/ Mongodb Replica Sets 副本集架构实战(架设.扩充.容灾.修复.客户端代码连入) http://snoopyxdy.blog.163.com/blog/static/60117440201241694254441/ 关于mongodb的shard集群动态添加分片 我在机器上建立起了分片集群,其中包含了四个分片,每个分片都是副本集构成,程序访问的时候可以将数据路由到各个分片上.

搭建高可用mongodb集群(四)—— 分片(经典)

转自:http://www.lanceyan.com/tech/arch/mongodb_shard1.html 按照上一节中<搭建高可用mongodb集群(三)-- 深入副本集>搭建后还有两个问题没有解决: 从节点每个上面的数据都是对数据库全量拷贝,从节点压力会不会过大? 数据压力大到机器支撑不了的时候能否做到自动扩展? 在系统早期,数据量还小的时候不会引起太大的问题,但是随着数据量持续增多,后续迟早会出现一台机器硬件瓶颈问题的.而mongodb主打的就是海量数据架构,他不能解决海量数据怎么

利用Docker部署mongodb集群--分片与副本集

环境 Docker version 1.6.2  mongodb 3.0.4 第一步  编写Dockerfile并生成镜像 主意包含两个Dockerfile镜像,一个mongod的,一个mongos(在集群中负责路由) 编写Mongod的Dockerfile: FROM ubuntu:14.04 RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10 ENV MONGO_MAJOR 3.0 RUN ech