mongodb服务挂掉，mongodb开启服务

关闭MongoDB服务的几种方法

MongoDB 提供几种关闭服务的命令

使用 mongod 命令关闭

 [mongo@redhatB data]$ mongod  --shutdown  --dbpath /database/mongodb/data/

killing process with pid: 17747

使用 kill 命令

 [mongo@redhatB data]$ ps -ef | grep mongo

root     17573 14213  0 05:10 pts/1    00:00:00 su - mongo

mongo    17574 17573  0 05:10 pts/1    00:00:00 -bash

mongo    18288     1  0 06:12 ?        00:00:00 mongod -f /database/mongodb/data/mongodb_27017.conf

mongo    18300 17574  6 06:13 pts/1    00:00:00 ps -ef

mongo    18301 17574  0 06:13 pts/1    00:00:00 grep mongo

备注：可以使用操作系统的 kill 命令，给 mongod 进程发送 SIGINT 或 SIGTERM 信号，

即 "kill -2 PID," 或者 “kill -15 PID“。

            建议不要使用 ”kill -9 pid“，因为如果 MongoDB 运行在没开启日志（--journal）的情况下，

            可能会造成数据损失。

mongodb仲裁节点挂掉怎么办

要尽量使用奇数个节点而不要使用仲裁节点

当仲裁节点挂掉后，若Primary节点正常，则不影响正常使用，将仲裁节点恢复即可；若在仲裁节点恢复之前，Primary节点就挂了，这时候因无法进行选择投票，所以只有secondary节点而没有Primary节点，因此只能进行检索操作无法进行更新操作，此时若将仲裁节点恢复，将会重新选举出Primary节点，集群重新恢复正常功能。

linux下的mongodb服务自动关闭，不知道什么原因

为解决频繁的数据插入和更新问题（这些数据的可靠性要求不高，不需要事务），赶上NoMysql的热潮，选择目前最热门的Mongodb，在测试中充分感受到mongodb安装的简单性和客户端调用API的便捷。

但在生产环境下（操作系统CentOS 6.2，内存64G，CPU 12核），却出现频繁的宕机，有时候一天就要宕2次，虽然设置了replica sets，却很容易挂掉2台，导致不可用。

查看mongod.log，发现每次宕机时都会打印Got signal: 11 (Segmentation fault)，但从这个查找不到能够解决问题的资料。

有人认为mongodb频繁宕机大多数是因为在并发查询的压力下，因为热数据没有在内存中，被迫到文件系统读取数据，很容易出现timeout的问题，之后会造成进程锁死，经过验证，如果把查询（只有通过主键查一条记录的查询）的客户端关闭掉，宕机的概率小非常多。查看每台mongodb的内存(通过mongodb命令控制台的db.serverStatus()看“mem”部分的“resident”)，发现mongodb热数据的内存只占用不到2G，而数据文件有近200G，可能也是因为频繁的宕机，导致热数据一直未全部加载。

但还是会出现宕机，为了不需要人工重启，就在每个replica的服务器上用Linux Shell脚本写了一段每隔1分钟检测mongodb进程死掉自动重启的进程，虽然能够解决mongodb一直在运行的状态，但发现mongodb的collections中出现很多损坏的数据，甚至出现一些自动创建的异常collections，如一个collections的名称是“jingdong”，则会出现多个“ingdong”、"jing"、“jingdon”之类的collections。

不得已只好把mongodb的定时检测启动脚本关闭掉，顺着这个现象找问题，终于在mongodb的JIRA看到有个用户反馈的现象跟我们完全一致，最后他解决的方法是把mongodb客户端的java驱动jar包由2.9.1回退至2.8.0，我们也按照这样处理后，果然不会再出现crash问题。

mongodb服务挂掉的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于mongodb开启服务、mongodb服务挂掉的信息别忘了在本站进行查找喔。