一、数据的导入导出和备份恢复
数据导出:mongoexport
常用导出方法
1
2
3
|
mongoexport -d
test
-c stu -o stu.dat
connected to: 127.0.0.1
exported 10 records
|
导出数据的导出的方式使用的是JSON的样式
1
2
3
4
5
6
7
8
9
10
11
|
cat
stu.dat
{
"_id"
: 1,
"classid"
: 1,
"age"
: 14,
"name"
:
"Tom"
}
{
"_id"
: 2,
"classid"
: 1,
"age"
: 12,
"name"
:
"Jacky"
}
{
"_id"
: 3,
"classid"
: 2,
"age"
: 16,
"name"
:
"Lily"
}
{
"_id"
: 4,
"classid"
: 2,
"age"
: 9,
"name"
:
"Tony"
}
{
"_id"
: 5,
"classid"
: 2,
"age"
: 19,
"name"
:
"Harry"
}
{
"_id"
: 6,
"classid"
: 2,
"age"
: 13,
"name"
:
"Vincent"
}
{
"_id"
: 7,
"classid"
: 1,
"age"
: 14,
"name"
:
"Bill"
}
{
"_id"
: 8,
"classid"
: 2,
"age"
: 17,
"name"
:
"Bruce"
}
{
"_id"
: 9,
"classid"
: 3,
"age"
: 18,
"name"
:
"Gaici"
}
{
"_id"
: 10,
"classid"
: 3,
"age"
: 38,
"name"
:
"Leader"
}
|
参数说明:
-d指明使用的库,本例中为”test”
-c指明要导出的表,本例中为”stu”
-o指明要导出的文件名,本例中为”stu.dat”
导出CSV格式的文件
1
|
mongoexport -d
test
-c stu --csv -f classid,age,name -o stu_csv.dat
|
格式如下:
1
2
3
4
5
6
7
8
9
10
11
12
|
cat
stu_csv.dat
classid,age,name
1.0,14.0,
"Tom"
1.0,12.0,
"Jacky"
2.0,16.0,
"Lily"
2.0,9.0,
"Tony"
2.0,19.0,
"Harry"
2.0,13.0,
"Vincent"
1.0,14.0,
"Bill"
2.0,17.0,
"Bruce"
3.0,18.0,
"Gaici"
3.0,38.0,
"Leader"
|
参数说明:
-csv指要要导出为csv格式
-f指明需要导出哪些例
数据导入:mongoimport
先将表删除
1
2
3
4
5
6
7
8
9
|
> db.stu.drop()
true
> show tables;
fs.chunks
fs.files
mycappc1
mycappc2
stu_res
system.indexes
|
然后导入数据
1
2
3
|
mongoimport -d
test
-c stu stu.dat
connected to: 127.0.0.1
Tue Nov 12 17:43:16.532 imported 10 objects
|
导入CSV数据
1
|
mongoimport -d
test
-c stu -
type
csv --headerline --
file
stu_csv.dat
|
参数说明:
-type指明要导入的文件格式
-headerline批明不导入第一行,因为第一行是列名
-file指明要导入的文件路径
注意:
CSV格式良好,主流数据库都支持导出为CSV的格式,所以这种格式非常利于异构数据迁移
数据备份mongodump
可以用mongodump来做MongoDB的库或表级别的备份,下面举例说明:
备份test数据库
1
|
mongodump -d
test
|
此时会在当前目录下创建一个dump目录,用于存放备份出来的文件
也可以指定备份存放的目录
1
|
mongodump -d
test
-o my_test
|
这个例子中将备份的文件存在了当前目录下的my_test目录下
数据恢复mongorestore
由于刚刚已经做了备份,所以我们先将库test删除掉
1
2
|
db.dropDatabase()
{
"dropped"
:
"test"
,
"ok"
: 1 }
|
接下来我们进行数据库恢复
1
|
mongorestore -d
test
dump/*
|
经验证数据库又回来了,其实要是想恢复库,也大可不必先删除test库,只要指
明–drop参数,就可以在恢复的时候先删除表然后再向表中插入数据的
二、访问控制
官方手册中启动MongoDB服务时没有任何参数,一旦客户端连接后可以对数据库任意操
作,而且可以远程访问数据库,所以推荐开发阶段可以不设置任何参数,但对于生产环境还
是要仔细考虑一下安全方面的因素,而提高MongoDB数据库安全有几个方面:
1、绑定IP内网地址访问MongoDB服务
MongoDB可以限制只允许某一特定IP来访问,只要在启动时加一个参数bind_ip即可,如
下:
服务端限制只有192.168.1.103这个IP可以访问MongoDB服务
1
|
.
/mongod
--bind_ip 192.168.1.103
|
则只有IP为192.168.1.103的客户端可以访问
2、设置监听端口
官方默认的监听端口是27017,为了安全起见,一般都会修改这个监听端口,避免恶意的连
接尝试,具体如下:将服务端监听端口修改为28018
1
|
.
/mongod
--bind_ip 192.168.1.103 --port 28018
|
端户访问时不指定端口,会连接到默认端口27017,对于本例会报错
所以当服务端指定了端口后,客户端必须要明确指定端口才可以正常访问
1
|
.
/mongo
192.168.1.103:28018
|
3、使用用户名和口令登录
MongoDB默认的启动是不验证用户名和密码的,启动MongoDB后,可以直接用MongoDB连接
上来,对所有的库具有root权限。所以启动的时候指定参数,可以阻止客户端的访问和连接。
先启用系统的登录验证模块,只需在启动时指定auth参数即可,如:
1
|
.
/mongod
--auth
|
连接一下试试
1
2
3
4
|
.
/mongo
MongoDB shell version: 2.4.7
connecting to:
test
>
|
很奇怪,为什么我们启用了登录验证模块,但我们登录时没有指定用户,为什么还可以登录
呢?在最初始的时候MongoDB都默认有一个admin数据库(默认是空的),
而admin.system.users中将会保存比在其它数据库中设置的用户权限更大的用户信息。
注意:当admin.system.users中没有添加任何用户时,
即使MongoDB启动时添加了--auth参数,此时不进行任何认证依然可以使用任何操作,
直到你在admin.system.users中添加了一个用户。
1
2
3
4
5
6
7
8
|
use admin
db.addUser(
'root'
,
'123'
)
{
"user"
:
"root"
,
"readOnly"
:
false
,
"pwd"
:
"c2eb464922307de3bc3aaf9593f1d49b"
,
"_id"
: ObjectId(
"5282086396b7a4a6e3cb17ed"
)
}
|
客户端连接试试:
连上test库了,但进一步操作时有异常,看来MongoDB允许未授权连接,不能进行任何操作。
本地客户端连接,指定用户,结果如下:
因为root是admin库的,所以只能连接admin,连接其他库是不能进入的。
1
2
3
4
5
|
.
/mongo
-uroot -p123
test
MongoDB shell version: 2.4.7
connecting to:
test
Tue Nov 12 19:07:41.870 Error: 18 { code: 18, ok: 0.0, errmsg:
"auth fails"
} at src
/mongo/shell/db
.js:228
exception: login failed
|
只能进入admin然后再进行操作:
MongoDB也支持为某个特定的数据库来设置用户,如我们为test库设一个只读的用户
1
2
3
4
5
6
7
8
9
10
11
|
> use
test
;
switched to db
test
> db.addUser(
'test'
,
'123'
,
true
)
{
"user"
:
"test"
,
"readOnly"
:
true
,
"pwd"
:
"e78333b96cbdc20a67432095f4741222"
,
"_id"
: ObjectId(
"52820d76bca929d60ae67b5c"
)
}
> db.auth(
'test'
,
'123'
)
1
|
客户端用此用户来访问test,只能进行读操作,只针对test库
本文转自shayang8851CTO博客,原文链接:http://blog.51cto.com/janephp/1324110,如需转载请自行联系原作者