先说下主从
随着数据量的增多单台mongodb服务器已经满足不了现状,所以用到了主从集群
主从复制是最mongodb最常用的复制方式,他最大的特点是备份,对于读易扩展,降低服务器的压力!
MongoDB支持在多个机器中通过异步复制到底故障转移和实现冗余,多台机器中同一时刻只有一台是用于写操作,这为mongoDB提供了数据一致性的保障.担当Primary角色的机器能把读操作分发给slave机器.
MongoDB的主从集群分为两种 Master-Slave 复制(主从复制) Replica Sets 复制(副本集) 主服务器支持增删该,从服务器主要支持读.
Master-Slave(主从复制) 只需要在某一个服务启动时加上-master参数,以指明此服务器的角色是primary,而另一个服务加上-slave与-source参数,以指明此服务器的角色是slave. 即可实现同步, MongoDB的最新版本已经不推荐使用这种方法了.
Replica Sets 复制(副本集) MongoDB在1.6版本开发了replica set,主要增加了故障自动切换和自动修复成员节点.各个DB之间数据完全一致,最为显著的区别在于,副本集没有固定的主节点,它是整个集群选举得出的一个主节点.当其不工作时变更其它节点.
|
两种启动方式,一种是配置文件,另一种是加参数
master
在主服务器上加--master 选项启动
./mongod --dbpath=/home/mongodb/db --master --oplogSize 64
slave
从服务器上加 --slave选项启动并指定 master 的地址。
mongod --dbpath=/data/db --slave --source 192.168.0.2 --only test --slavedelay 10
测试主从的效果
在主服务器上加一些数据。打开客户端 bin/mongo > db.foo.save({"id":123,"name":'chenlb'}) 成功的话可以在从服务器看到数据: bin/mongo > db.foo.find({"id":123}) |
集群副本的使用
#Server1:
mkdir -p /data2/mongodb/shard11
mkdir -p /data2/mongodb/shard21
/mongodb/bin/mongod --shardsvr --replSet shard1 --port 27017 --dbpath /data2/mongodb/shard11 --oplogSize 100 --logpath /data2/mongodb/shard11.log --logappend --fork --rest
/mongodb/bin/mongod --shardsvr --replSet shard2 --port 27018 --dbpath /data2/mongodb/shard21 --oplogSize 100 --logpath /data2/mongodb/shard21.log --logappend --fork �Crest
#Server2:
mkdir -p /data2/mongodb/shard12/
mkdir -p /data2/mongodb/shard22/
/mongodb/bin/mongod --shardsvr --replSet shard1 --port 27017 --dbpath /data2/mongodb/shard12 --oplogSize 100 --logpath /data2/mongodb/shard12.log --logappend --fork --rest
/mongodb/bin/mongod --shardsvr --replSet shard2 --port 27018 --dbpath /data2/mongodb/shard22 --oplogSize 100 --logpath /data2/mongodb/shard22.log --logappend --fork �Crest
#Server3:
mkdir -p /data2/mongodb/shard13/
mkdir -p /data2/mongodb/shard23/
/mongodb/bin/mongod --shardsvr --replSet shard1 --port 27017 --dbpath /data2/mongodb/shard13 --oplogSize 100 --logpath /data2/mongodb/shard13.log --logappend --fork --rest
/mongodb/bin/mongod --shardsvr --replSet shard2 --port 27018 --dbpath /data2/mongodb/shard23 --oplogSize 100 --logpath /data2/mongodb/shard23.log --logappend --fork �Crest
3、初始化Replica Set
通过命令行初始化两组Replica Set,通过mongo连接到一个mongod
/mongodb/bin/mongo 172.17.0.121:27017
config = {_id: ‘shard1′, members: [
{_id: 0, host: '172.17.0.121:27017'},
{_id: 1, host: '172.17.0.122:27017'},
{_id: 2, host: '172.17.0.123:27017'}]};
rs.initiate(config);
/mongodb/bin/mongo 172.17.0.121:27018
config = {_id: ‘shard2′, members: [
{_id: 0, host: '172.17.0.121:27018'},
{_id: 1, host: '172.17.0.122:27018'},
{_id: 2, host: '172.17.0.123:27018'}]};
rs.initiate(config);
博客地址: http://rfyiamcool.blog.51cto.com/1030776/1193765
备份与恢复: 冷备份: 关闭mongod,拷贝数据库文件,启动mongod,恢复时一样 热备份:(1)、使用mongodump备份,mongorestore恢复 (2)、使用mongoexport备份,mongoimport恢复 (3)、创建主从复制机制,自动同步
|
冷备份 用这个方法的时候 最好关闭进程 不然大数据的时候 会出现问题
下面是还原
热备份
mongodump mongo导出数据库命令 mongodump --help 可以查看该命令下所有的帮助
-h 导出源
-d 要导出的数据库名称
-o 数据库要导出的位置
在终端滚过N行之后,数据库导出完成
恢复使用:mongorestore 命令
-d 使用的数据库名称
后面直接加你刚才导出的目录,这样是直接恢复所有表
如果-c 是恢复一个表
--drop:恢复的时候,先删除当前数据,然后恢复备份的数据。就是说,恢复后,备份后添加修改的数据都会被删除,慎用哦!
导入
mongoimport -d my_mongodb -c user user.dat
参数说明:
-d 指明使用的库, 本例中为” my_mongodb”
-c 指明要导出的表, 本例中为”user”
可以看到导入数据的时候会隐式创建表结构
4. 导出
mongoexport -d my_mongodb -c user -o user.dat
参数说明:
-d 指明使用的库, 本例中为” my_mongodb”
-c 指明要导出的表, 本例中为”user”
-o 指明要导出的文件名, 本例中为”user.dat”
从上面可以看到导出的方式使用的是JSON 的样式
博客地址:http://rfyiamcool.blog.51cto.com/
Mongodb 性能的监控
它的输出有以下几列:
insert 每秒插入次数
query 每秒查询次数
update 每秒更新次数
delete 每秒删除次数
getmore 每秒执行getmore次数
command 每秒的命令数,比以上插入、查找、更新、删除的综合还多,还统计了别的命令
flushs 每秒执行fsync将数据写入硬盘的次数。
mapped 所有的被mmap的数据量
vsize 虚拟内存使用量
res 物理内存使用量
faults 每秒访问失败数(只有Linux有),数据被交换出物理内存,放到swap。不要超过100,否则就是机器内存太小,造成频繁swap写入。此时要升级内存或者扩展
locked % 被锁的时间百分比,尽量控制在50%以下吧
idx miss % 索引不命中所占百分比。如果太高的话就要考虑索引是不是少了
qr 客户端等待从 MongoDB 实例读取数据的队列长度。
qw 客户端等待向 MongoDB 实例写入数据的队列长度。
ar 执行读取操作的活动客户端的数目。
aw 执行写入操作的活动客户端的数目。
netIn MongoDB 收到的网络流量,这包括 mongostat 本身的流量。
netOut MongoDB 发送的网络流量,这包括 mongostat 本身的流量。
conn 打开连接的总数。
set 副本集的名称(如适用)。
repl 节点的复制状态。(M:主版本,SEC:次,REC:恢复,UNK:未知,SLV:从属)
优化器profile 在MySQL 中,慢查询日志是经常作为我们优化数据库的依据,那在MongoDB 中是否有类似的功能呢?答案是肯定的,那就是MongoDB Database Profiler。 db.setProfilingLevel(2);上面profile 的级别可以取0,1,2 三个值,他们表示的意义如下: 1.0 �C 不开启 2.1 �C 记录慢命令 (默认为>100ms) 3.2 �C 记录所有命令 Profile 记录在级别1 时会记录慢命令,那么这个慢的定义是什么?上面我们说到其默认为100ms,当然有默认就有设置,其设置方法和级别一样有两种,一种是通过添加�Cslowms 启动参数配置。第二种是调用db.setProfilingLevel 时加上第二个参数: 与MySQL 的慢查询日志不同,MongoDB Profile 记录是直接存在系统db 里的,记录位置system.profile ,所以,我们只要查询这个Collection 的记录就可以获取到我们的 Profile 记录了。列出执行时间长于某一限度(5ms)的 Profile 记录: db.system.profile.find( { millis : { $gt : 5 } } ) MongoDB Shell 还提供了一个比较简洁的命令show profile,可列出最近5 条执行时间超过1ms 的 Profile 记录。 |
zabbix 对mongodb监控
添加MongoDB监控
1、zabbix客户端配置文件zabbix_agentd.conf文件,添加如下内容:
UserParameter=MongoDB.Status[*],/bin/echo "db.serverStatus().$1" | /usr/local/sbin/mongo admin | grep "$2"|awk -F: '{print $$2}'|awk -F, '{print $$1}'
2、重新启动zabbix客户端
/etc/init.d/zabbix_agentd restart
剩下的模板就是增加模板了
本文出自 “峰云,就她了。” 博客,请务必保留此出处http://rfyiamcool.blog.51cto.com/1030776/1193765