mongodb维护文档

目录

Mongodb CPU利用率超高，负载超高。 2

问题分析： 2

mongostat 分析： 2

使用 db.currentOp()查看： 2

查看 MONGODB日志： 2

MONGODB开启集群分片 3

对库进行开启分片操作： 3

在要开启分片的集合上面创建索引： 4

打开集合分片： 4

验证分片： 4

MONGODB分片集群下的磁盘扩容 4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Mongodb CPU 利用率超高，负载超高。

 

问题分析：

M ONGODB 的 C PU 使用率很高， 数据库发生堵塞或者有大量的慢查询。

mongostat 分析：

m ongostat   查看到请求量并不高， 而且发生的库是从库。

使用 d b.currentOp() 查看：

Db.currentOp() 查看到的会话非常的多， 这里查找比较麻烦， 我们可以去查看 M ONGODB 的日志， 慢查询会打印日志到文件中。

查看 M ONGODB 日志：

如果找不到 M ONGODB 的日志文件， 可以使用 p s –elf | grep mongod 去找到配置文件， 配置文件里会有相关的配置。

 

配置文件中的 L OGPATH 参数是配置日志文件的。

使用 t ail -100f /data/mongodb/logs/db.log

 

此查询需要花 30秒的时间。

此查询是根据 DATAID查询的，  连接MONGODB查看此条件是否有索引。

Mongo 127.0.0.1:27017

Use datalog;

Db. user_operate_log.getIndexes() 去获取此集合的索引。

发现此集合没有关于 D ATAID 的索引， 因此跟业务人员联系，要求加索引即可。

db.user_operate_log.ensureIndex({"dataId":1});

在添加索引完成后， 关于此服务器的告警全部消失：

 

 

 

 

 

M ONGODB 开启集群分片

对库进行开启分片操作：

sh.enableSharding("dbname")

在要开启分片的集合上面创建索引：

db.collection_name.createIndex({_id: "hashed"})

因为我这边里创建的是 H ASH 分片，所以创建 H ASH 类型的索引即可。

打开集合分片：

sh.shardCollection( "dbname.collection_name", { "_id": "hashed" } )

验证分片：

sh.status()

 

M ONGODB 分片集群下的磁盘扩容

介绍： 因前期磁盘空间未做规划， M ONGODB 的数据目录存放在了根分区，根分区的空间小而且 I O 能力跟不上 ,在后期添加磁盘后需要对数据进行迁移到新磁盘的操作。

方案：

关闭备节点。

Mongo 127.0.0.1:27017

Use admin;

Db.shutdownServer()

迁移数据目录到新的磁盘，并修改配置文件到新的磁盘路径。（ p s –elf | grep mongo 可获取到参数文件的路径）

Mv /data/mongo /data1/mongo

启动备节点。

依次将所有备节点操作完毕。

主库降级成为备库，让已经切换为的主库提供服务。注： 在这个过程中会有微妙级的中断，和业务沟通，并无影响。

主库降级命令连接进主库后执行 r s.stepDown()

迁移原主库数据即可。

在关库重启后需要使用 r s.status() 来确认复制集的正常。

在切换主库时需要关注业务的正常以及复制集的正常。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28458088/viewspace-2642200/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28458088/viewspace-2642200/