mongodb维护文档的方法是怎样的,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
<强> mongodb CPU <>强利用率超高,负载超高。
, 
<强>问题分析:
mongodb的CPU 使用率很高, 数据库发生堵塞或者有大量的慢查询。
<强> mongostat <强>分析:
mongostat,查看到请求量并不高, 而且发生的库是从库。
<强>使用d <强> b.currentOp() <强>查看:
Db.currentOp () 查看到的会话非常的多, 这里查找比较麻烦, 我们可以去查看MONGODB的日志, 慢查询会打印日志到文件中。
<强>查看M <强> ONGODB <强>日志:
如果找不到MONGODB的日志文件, 可以使用ps精灵| grep mongod 去找到配置文件, 配置文件里会有相关的配置。
, 
配置文件中的LOGPATH 参数是配置日志文件的。
使用尾巴-100 f/数据/mongodb/日志/db.log
, 
此查询需要花30秒的时间。
此查询是根据DATAID查询的,,连接mongodb查看此条件是否有索引。
Mongo 127.0.0.1:27017
使用datalog;
Db。user_operate_log.getIndexes () 去获取此集合的索引。
发现此集合没有关于DATAID的索引, 因此跟业务人员联系,要求加索引即可。
db.user_operate_log.ensureIndex ({“dataId": 1});
在添加索引完成后, 关于此服务器的告警全部消失:
, 
<强> M <强> ONGODB <强>开启集群分片
<强>对库进行开启分片操作:
sh.enableSharding (“dbname")
<强>在要开启分片的集合上面创建索引:
db.collection_name。方法createIndex ({_id:“hashed"})
因为我这边里创建的是散列分片,所以创建散列类型的索引即可。
<>强打开集合分片:
sh。shardCollection (“dbname.collection_name" {“_id":“hashed"})
<强>验证分片:
sh.status ()
<强> M <强> ONGODB <强>分片集群下的磁盘扩容
介绍: 因前期磁盘空间未做规划,MONGODB的数据目录存放在了根分区,根分区的空间小而且IO能力跟不上,在后期添加磁盘后需要对数据进行迁移到新磁盘的操作。
方案:
关闭备节点。
Mongo 127.0.0.1:27017
使用管理;
Db.shutdownServer ()
迁移数据目录到新的磁盘,并修改配置文件到新的磁盘路径。(ps精灵| grep Mongo 可获取到参数文件的路径)
Mv/数据/mongo/data1 mongo
启动备节点。
依次将所有备节点操作完毕。
主库降级成为备库,让已经切换为的主库提供服务。注: 在这个过程中会有微妙级的中断,和业务沟通,并无影响。
主库降级命令连接进主库后执行rs.stepDown ()
迁移原主库数据即可。
在关库重启后需要使用rs.status()来确认复制集的正常。
在切换主库时需要关注业务的正常以及复制集的正常。
关于mongodb维护文档的方法是怎样的问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注行业资讯频道了解更多相关知识。
