导出
mongoexport -d my_mongodb -c user -o user.dat
导出CSV格式
mongoexport -d my_mongodb -c user --csv -f uid,username,age -o
user_csv.dat
-csv 指要要导出为 csv 格式
-f 指明需要导出哪些例
导入
mongoimport -d my_mongodb -c user user.dat
导入CSV格式
mongoimport -d my_mongodb -c user --type csv --headerline --file
user_csv.dat
CSV 格式良好，主流数据库都支持导出为 CSV 的格式，所以这种格式非常利于异构数据迁移
mongodump 来做 MongoDB 的库或表级别的备份，下面举例说明:
备份 my_mongodb 数据库
[root@localhost bin]# ./mongodump -d my_mongodb
自动出现备份目录 dump
mongodump -d my_mongodb -o my_mongodb_dump
也可以指定备份目录
恢复数据库
mongorestore -d my_mongodb my_mongodb_dump/*
删除数据库
use test
db.dropDatabase()
服务端限制只有 192.168.1.103 这个 IP 可以访问 MongoDB 服务
[root@localhost bin]# ./mongod --bind_ip 192.168.1.103
客户端访问时需要明确指定服务端的 IP，否则会报错:
[root@localhost bin]# ./mongo 192.168.1.102
MongoDB shell version: 1.8.1
connecting to: 192.168.1.103/test
将服务端监听端口修改为 28018
[root@localhost bin]# ./mongod --bind_ip 192.168.1.103 --port 28018
端户访问时不指定端口，会连接到默认端口 27017，对于本例会报错
[root@localhost bin]# ./mongo 192.168.1.102
所以当服务端指定了端口后，客户端必须要明确指定端口才可以正常访问
[root@localhost bin]# ./mongo 192.168.1.102:28018
先启用系统的登录验证模块, 只需在启动时指定 auth 参数即可，如:
[root@localhost bin]# ./mongod --auth
在 admin 库中新添一个用户 root:
[root@localhost bin]# ./mongo
MongoDB shell version: 1.8.1
connecting to: test
> db.addUser("root","111")
{
"user" : "root",
"readOnly" : false,
"pwd" : "e54950178e2fa777b1d174e9b106b6ab"
}
> db.auth("root","111")
本地客户端连接，指定用户，结果如下:
[root@localhost bin]# ./mongo -u root -p
将将将 MongoDB Windows
先创建 C:\mongo\logs\mongodb.log 文件，用于存储 MongoDB 的日志文件, 再安装系统
服务。
C:\mongo\bin>C:\mongo\bin\mongod --dbpath=c:\ db --logpath=c:\mongo\lo
gs\mongodb.log --install
t1_count.js 就是我们要执行的文件，里面的内容如下
[root@localhost bin]# cat t1_count.js
var totalcount = db.t1.count();
printjson('Total count of t1 is : ' + totalcount);
printjson('-----------------------');
./mongo t1_count.js
MongoDB shell version: 1.8.1
connecting to: test
"Total count of t1 is : 7"
/mongo --quiet t1_count.js
"Total count of t1 is : 7"
"-----------------------"
[root@localhost bin]#
通过指定 quiet 参数，即可以将一些登录信息屏蔽掉，这样可以让结果更清晰
查看活动进程，便于了解系统正在做什么，以便做下一步判断
> db.currentOp();
> // 等同于: db.$cmd.sys.inprog.findOne()
{ inprog: [ { "opid" : 18 , "op" : "query" , "ns" : "mydb.votes" ,
"query" : "{ score : 1.0 }" , "inLock" : 1 }
]
}
:
Opid: 操作进程号
Op: 操作类型(查询，更新等)
Ns: 命名空间, 指操作的是哪个对象
Query: 如果操作类型是查询的话，这里将显示具体的查询内容
lockType: 锁的类型，指明是读锁还是写锁
DBA 都会毫不留情的杀掉这个罪魁祸首的
进程，下面将是这操作
> db.killOp(1234/*opid*/)
> // 等同于: db.$cmd.sys.killop.findOne({op:1234})
在字段 age 上创建索引，1(升序);-1(降序)
> db.t3.ensureIndex({age:1})
> db.t3.getIndexes();
当系统已有大量数据时，创建索引就是个非常耗时的活，我们可以在后台执行，只需指定
“backgroud:true”即可。
> db.t3.ensureIndex({age:1} , {backgroud:true})
索引可以任何类型的字段，甚至文档
db.factories.insert( { name: "wwl", addr: { city: "Beijing", state: "BJ" } } );
//在 addr 列上创建索引
db.factories.ensureIndex( { addr : 1 } );
//下面这个查询将会用到我们刚刚建立的索引
db.factories.find( { addr: { city: "Beijing", state: "BJ" } } );
//但是下面这个查询将不会用到索引，因为查询的顺序跟索引建立的顺序不一样
db.factories.find( { addr: { state: "BJ" , city: "Beijing"} } );
MongoDB 也是有组合索引的，下面我们将在 addr.city 和 addr.state
上建立组合索引。当创建组合索引时，字段后面的 1 表示升序，-1 表示降序，是用 1 还是
用-1 主要是跟排序的时候或指定范围内查询 的时候有关的。
db.factories.ensureIndex( { "addr.city" : 1, "addr.state" : 1 } );
// 下面的查询都用到了这个索引
db.factories.find( { "addr.city" : "Beijing", "addr.state" : "BJ" } );
db.factories.find( { "addr.city" : "Beijing" } );
db.factories.find().sort( { "addr.city" : 1, "addr.state" : 1 } );
db.factories.find().sort( { "addr.city" : 1 } )
//删除 t3 表中的所有索引
db.t3.dropIndexes()
//删除 t4 表中的 firstname 索引
db.t4.dropIndex({firstname: 1})
执行计划 利用 explain 命令，
我们可以很好地观察系统如何使用索引来加快检索，同时可以针对性优化索引。
> db.t5.ensureIndex({name:1})
> db.t5.ensureIndex({age:1})
> db.t5.find({age:{$gt:45}}, {name:1}).explain()
{
"cursor" : "BtreeCursor age_1",
"nscanned" : 0,
"nscannedObjects" : 0,
"n" : 0,
"millis" : 0,
"nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
"indexBounds" : {
"age" : [
[
45,
1.7976931348623157e+308
]
}
}
:
cursor: 返回游标类型(BasicCursor 或 BtreeCursor)
nscanned: 被扫描的文档数量
n: 返回的文档数量
millis: 耗时(毫秒)
indexBounds: 所使用的索引
启动 MongoDB 时加上–profile=级别 即可。
也可以在客户端调用 db.setProfilingLevel(级别) 命令来实时配置，Profiler 信息保存在
system.profile 中。我们可以通过 db.getProfilingLevel()命令来获取当前的 Profile 级别，类似如
下操作
> db.setProfilingLevel(2);
{ "was" : 0, "slowms" : 100, "ok" : 1 }
上面 profile 的级别可以取 0，1，2 三个值，他们表示的意义如下：
0 – 不开启
1 – 记录慢命令 (默认为>100ms)
2 – 记录所有命令
列出执行时间长于某一限度(5ms)的 Profile 记录：
db.system.profile.find( { millis : { $gt : 5 } } )
db.system.profile.find().sort({$natural:-1}).limit(1)
{ "ts" : ISODate("2012-05-20T16:50:36.321Z"), "info" : "query test.system.profile reslen:1219
nscanned:8 \nquery: { query: {}, orderby: { $natural: -1.0 } } nreturned:8 bytes:1203", "millis" :
0 }
>
:
ts： 该命令在何时执行
info: 本命令的详细信息
reslen: 返回结果集的大小
nscanned: 本次查询扫描的记录数
nreturned: 本次查询实际返回的结果集
millis: 该命令执行耗时，以毫秒记
capped Collections 比普通 Collections 的读写效率高。Capped Collections 是高效率的 Collection
类型，它有如下特点：
1、固定大小；Capped Collections 必须事先创建，并设置大小：
db.createCollection("mycoll", {capped:true, size:100000})
2、Capped Collections 可以 insert 和 update 操作；不能 delete 操作。只能用 drop（）方法
删除整个 Collection。
3、默认基于 Insert 的次序排序的。如果查询时没有排序，则总是按照 insert 的顺序返回。
4、FIFO。如果超过了 Collection 的限定大小，则用 FIFO 算法，新记录将替代最先 insert 的
记录。
此工具可以快速的查看某组运行中的 MongoDB 实例的统计信息
/mongostat
insert query update delete ...... locked % idx miss % qr|qw ar|aw conn time
*0 *0 *0 *0 ...... 0 0 0|0 1|0 4 01:19:15
*0 *0 *0 *0 ...... 0 0 0|0 1|0 4 01:19:16
*0 *0 *0 *0 ...... 0 0 0|0 1|0 4 01:19:17
:
insert: 每秒插入量
query: 每秒查询量
update: 每秒更新量
delete: 每秒删除量
locked: 锁定量
qr | qw: 客户端查询排队长度(读|写)
ar | aw: 活跃客户端量(读|写)
conn: 连接数
time: 当前时间
它每秒钟刷新一次状态值，提供良好的可读性，通过这些参数可以观察到一个整体的性能情
mongodb状态查询之db.serverStatus()详解(2012-06-20 16:28:09)
转载▼ 分类： DBA之路
--转载（收藏）
Field Example Value Explanation
Host te.rzw.com:27018 运行实例所监听的IP与端口
version 1.8.3 当前实例所使用的版本
Process mongod 当前实例是mongod，还是mongos
Uptime 231905 实例连续正常运行时间,单位秒
uptimeEstimate 223083 基于mongodb内部粗粒定时器的连续正常运行时间
localTime ISODate(“2011-10-13T01:47:38.773Z”) 本机时间，以UTC时间为计算标准。
globalLock.totalTime 231905155987 自实例启动全局锁创建以来到现在多长时间，单位微秒.
globalLock.lockTime 9053050 自全局锁创建以来锁定总时间，单位微秒
globalLock.ratio 0.0000390377262 锁定的时间所占的比例(lockTime/ totalTime)
globalLock.currentQueue.total 0 当前等待全局锁的数量
globalLock.currentQueue.readers 0 当前等待读锁的数量
globalLock.currentQueue.writers 0 当前等待写锁的数量
globalLock.activeClients.total 1 连接到当前实例处于活动状态的客户端数量。
globalLock.activeClients.readers 1 处于活动状态的客户端中有多少是在执行read操作
globalLock.activeClients.writers 0 处于活动状态的客户端中有多少是在执行write操作
Mem.resident 6 到现在总共使用的物理内存,单位是MB
Mem.virtual 17307 当前Mongodb实例使用的虚拟内存大小，单位MB，一般情况下比mem.map的值要超大一点，如果大很多很有可能发生
内存泄露，如果使用journal,大约是2倍的map值
Mem.maped 8556 Mongodb使所有数据都映射到内存中，所以这个值可以看似整个数据量的值。
Mem.bits 64 机器位数,32位或64位
Mem.supported true 本机是否支持内存扩展
Connections.current 2 当前连接到本机处于活动状态的连接数
Connections. available 19998 剩余多少可供连接
extra_info. heap_usage_bytes 521152 当前实例堆大小，单位bytes
extra_info. page_faults 569 加载磁盘内容时发生页错误的次数
indexCounters. Btree.accesses 1 访问索引次数
indexCounters. Btree.hits 1 访问索引时，索引在内存中被命中的次数
indexCounters. Btree.misses 0 访问索引时，索引不是在内存中被命中的次数
indexCounters. Btree.resets 0 索引计数器被重置的次数
indexCounters. Btree.missRatio 0 索引非命中率
backgroundFlushing.flushes 3864 实例刷新数据到磁盘的数次
backgroundFlushing.total_ms 15473 刷新到磁盘总共花费的时间,单位毫秒
backgroundFlushing.average_ms 4.004399585921325 平均每次刷新执行时间
backgroundFlushing.last_ms 3 最后一次刷新执行时间
backgroundFlushing.last_finished ISODate(“2011-10-13T01:46:51.184Z”) 最后一次刷新完成的时间点
Cursors.totalOpen 1 当前游标数量
Cursors.timeOut 2 从实例启动到现在游标超时的总数量
Network.bytesIn 4680778 发送到实例的字节大小
Network.bytesOut 4759827 发送出去的字节大小
Repl.setName myset replSet结构定义的名称
Repl.isMaster True 当前实例是否是replSet结构中的Master节点
Repl.secondary False 当前实例是否是replSet结构中的secondary节点
Repl.hosts [ “te.rzw.com:27018”,”te.rzw.com:27019”] replSet结构中每个节点情况
Opcounters.insert 4 自实例启动以来，执行insert次数
Opcounters.query 181 自实例启动以来，执行query次数
Opcounters.update 92084 自实例启动以来，执行update次数
Opcounters.delete 0 自实例启动以来，执行delete次数
Opcounters.getmore 92816 自实例启动以来，在游标执行getMore次数
Opcounters.command 316 自实例启动以来，执行其他操作的次数
Asserts.regular 0 自实例启动以来,断言正常的次数
Asserts.warn 0 自实例启动以来,断言警告的次数
Asserts.msg 0 自实例启动以来，断言内部错误的次数
Asserts.user 134 自实例启动以来,因用户使用造成的错误而被断言次数
Asserts.rollovers 0 断言被翻转的次数
writeBacksQueued False 在mongos中，操作被重做的次数
Dur.commits 1 在最近间隔，向journal文件提交的次数
Dur.journaledMB 0.008192 在最近间隔,journalr文件写入数据量，单位MB
Dur. writeToDataFilesMB 0 在最近间隔,从journal文件向数据文件写入的数据量，单位MB
Dur. commitsInWriteLock 0 在最近间隔中，处于写锁状态下向journal提交的次数.这种提交方式是不被推荐的
Dur.earlyCommits 0 在预定时间之前请求提交的次数
Dur.timeMs.dt 3045 Journal状态收集的频率,单位毫秒
Dur.timeMs. prepLogBuffer 0 向journal写数据前的准备所花费时间, 单位毫秒
Dur.timeMs. writeToJournal 2 向journal写数据所花费时间，单位毫秒
Dur.timeMs. writeToDataFiles 0 在写入journal文件后向数据文件写数据花费时间，单位毫秒
Dur.timeMs. remapPrivateView 0 重新在内存中映射数据花费的时间
Ok 1 serverStatus操作是否被成功执行
原文地址:http://archive.cnblogs.com/a/2210339/
{
"host" : "localhost.localdomain",
"version" : "1.8.1", --服务器版本
"process" : "mongod",
"uptime" : 3184, --启动时间(秒)
"uptimeEstimate" : 3174,
"localTime" : ISODate("2012-05-28T11:20:22.819Z"),
"globalLock" : {
"totalTime" : 3183918151,
"lockTime" : 10979,
"ratio" : 0.000003448267034299149,
"currentQueue" : {
"total" : 0, --当前全部队列量
"readers" : 0, --读请求队列量
"writers" : 0 --写请求队列量
},
"activeClients" : {
"total" : 0, --当前全部客户端连接量
"readers" : 0, --客户端读请求量
"writers" : 0 --客户端写请求量
}
},
"mem" : {
"bits" : 32, --32 位系统
"resident" : 20, --占用物量内存量
"virtual" : 126, --虚拟内存量
"supported" : true, --是否支持扩展内存
"mapped" : 32
},
"connections" : {
"current" : 1, --当前活动连接量
"available" : 818 --剩余空闲连接量
},
……
"indexCounters" : {
"btree" : {
"accesses" : 0, --索引被访问量
"hits" : 0, --索引命中量
"misses" : 0, --索引偏差量
"resets" : 0,
"missRatio" : 0 --索引偏差率(未命中率)
}
},
……
"network" : {
"bytesIn" : 1953, --发给此服务器的数据量(单位:byte)
"bytesOut" : 25744, --此服务器发出的数据量(单位:byte)
"numRequests" : 30 --发给此服务器的请求量
},
"opcounters" : {
"insert" : 0, --插入操作的
"query" : 1, --查询操作的量
"update" : 0, --更新操作的量
"delete" : 0, --删除操作的量
"getmore" : 0,
"command" : 31 --其它操作的量
},
……
"ok" : 1
}
>
(http://cache.baidu.com/c?
m=9f65cb4a8c8507ed4fece7631046893b4c4380147d8c8c4668d4e419ce3b4c413037bfa6663f405a8e906b6075a91e5aeef43474610123b598c9c
d409cac925f75ce786a6459db0144dc4fffdc4755d620e74de8df58b0fab465d3b9d3a39e12008c1444&p=99759a46d7c41afc57ee952149409826&
user=baidu&fm=sc&query=db%2EserverStatus%28%29%3B&qid=ac4bd6920b330747&p1=2)
链接字符串：mongodb://sa:[email protected]:27017
(http://blog.csdn.net/lzy_1515/article/details/7027474)
db.stats 查看数据库状态信息。使用样例如下:
> db.stats()
{
"db" : "test",
"collections" : 7, --collection 数量
"objects" : 28, --对象数量
"avgObjSize" : 50.57142857142857, --对象平均大小
"dataSize" : 1416, --数据大小
"storageSize" : 31744, --数据大小(含预分配空间)
"numExtents" : 7, --事件数量
"indexes" : 7, --索引数量
"indexSize" : 57344, --索引大小
"fileSize" : 50331648, --文件大小
"ok" : 1 --本次取 stats 是否正常
}
>
通过这个工具，可以查看所在数据库的基本信息
mongo admin -u root -p
Mongo m = new Mongo();
DB db = m.getDB("test");//获取系统权限 登陆admin 再切换数据库
boolean auth = db.authenticate("root", "8858".toCharArray());
//db = m.getDB("test");
Set<String> colls = db.getCollectionNames();
for (String string : colls) {
System.out.println(string);
}
DBCollection coll = db.getCollection("c4");
System.out.println(coll.count());
DBCursor cur = coll.find().limit(1000);
while(cur.hasNext())
System.out.println(cur.next());
MongoDB 高可用可用分两种:
1. 主从复制 Master-Slave ：：：
只需要在某一个服务启动时加上–master参数，而另一个服务加上–slave与–source参数，
即可实现同步。MongoDB 的最新版本已不再推荐此方案。
2. 复制集 Replica Sets ：：：
MongoDB 在 1.6 版本对开发了新功能 replica set，这比之前的 replication 功能要强大一
些，增加了故障自动切换和自动修复成员节点，各个 DB 之间数据完全一致，大大降低了维
护成功。auto shard 已经明确说明不支持 replication paris，建议使用 replica set，replica set
故障切换完全自动。
设置主从服务器步骤
1。设置主服务器（ 10.166.112.109 ）
mongod --master --dbpath=d:\db --logpath=d:\db\logs\mongodb.log --auth --install
启动 net start mongodb
2。设置从服务器
mongod --slave --source 10.166.112.109 --dbpath=e:\db --logpath=e:\db\logs\mongodb.log --auth --install
启动 net start mongodb
如果发现主从不同步，从上手动同步
db.runCommand({"resync":1})
状态查询
db.runCommand({"isMaster":1}) #主还是从
在丛库上查询主库地址
> use local;
switched to db local
> db.sources.find();
{ "_id" : ObjectId("4e9105515d704346c8796407"), "host" :"10.166.112.109:27001", "source" : "main", "syncedTo" : { "t" :
1318155992000,"i" : 1 } }
#查看各Collection状态
db.printCollectionStats();
#查看主从复制状态
db.printReplicationInfo();
需认证的主从处理:
mongod --port 27017 --dbpath /data/mongodb/dbs/master --logpath /data/mongodb/dbs/master/master.log --fork --master -
-auth
mongod --port 27018 --dbpath /data/mongodb/dbs/slave --logpath /data/mongodb/dbs/slave/slave.log --fork --slave --
source localhost:27017 --auth
无需认证的主从处理:
mongod --port 27017 --dbpath /data/mongodb/dbs/master --master
mongod --port 27018 --dbpath /data/mongodb/dbs/slave --slave --source localhost:27017
主从设备同步 例子2
mongod --master --dbpath data/m1 -port 10001
mongod --slave --source localhost:10001 --dbpath data/s1 -port 10101
mongod --slave --source localhost:10001 --dbpath data/s2 -port 10102
客户端连接:
mongo -port 10001
mongo -port 10101
mongo -port 10102
Mongodb的全面总结
MongoDB语法与现有关系型数据库SQL语法比较
MongoDB语法 MySql语法
db.test.find({'name':'foobar'})<==> select * from test where name='foobar'
db.test.find() <==> select *from test
db.test.find({'ID':10}).count()<==> select count(*) from test where ID=10
db.test.find().skip(10).limit(20)<==> select * from test limit 10,20
db.test.find({'ID':{$in:[25,35,45]}})<==> select * from test where ID in (25,35,45)
db.test.find().sort({'ID':-1}) <==> select * from test order by IDdesc
db.test.distinct('name',{'ID':{$lt:20}}) <==> select distinct(name) from testwhere ID<20
db.test.group({key:{'name':true},cond:{'name':'foo'},reduce:function(obj,prev){prev.msum+=obj.marks;},initial:
{msum:0}}) <==> select name,sum(marks) from testgroup by name
db.test.find('this.ID<20',{name:1}) <==> select name from test whereID<20
db.test.insert({'name':'foobar','age':25})<==>insertinto test ('name','age') values('foobar',25)
db.test.remove({}) <==> delete * from test
db.test.remove({'age':20}) <==> delete test where age=20
db.test.remove({'age':{$lt:20}}) <==> elete test where age<20
db.test.remove({'age':{$lte:20}}) <==> delete test where age<=20
db.test.remove({'age':{$gt:20}}) <==> delete test where age>20
db.test.remove({'age':{$gte:20}})<==> delete test where age>=20
db.test.remove({'age':{$ne:20}}) <==> delete test where age!=20
db.test.update({'name':'foobar'},{$set:{'age':36}})<==> update test set age=36 where name='foobar'
db.test.update({'name':'foobar'},{$inc:{'age':3}})<==> update test set age=age+3 where name='foobar'
(http://blog.csdn.net/jakenson/article/details/7060431)