mongodb 常见问题处理方法收集

问题1：非正常关闭服务或关机后 mongod服务没法正常启动

在使用中发现mongodb 的服务可能由于非正常关闭而启动不了，这时咱们经过
删除data目录下的 *.lock文件，再运行下/mongodb_binpath/mongod -repair -f config文件路径 再启动便可
也能够在/etc/init.d/mongod 服务启动的文件中加入启动前删除该文件 以下：

 

问题2：server-side JavaScript execution is disabled

完整信息：JavaScript execution failed: group command failed: { "ok" : 0, "errmsg" : "server-side JavaScript execution is disabled" }
解决方法：mongod.conf 这个配置文件里（配置文件须要本身建立）

noscripting：false

若是true 就是禁止

 

问题3：Decimal转换成BsonValue值异常

BsonValue 暂不支持 Decimal类型，转换前强制转换类型，

若是用MongoDB，最好不要用decimal类型，不然在序列化的时候也有问题，可用double

 

问题4：MONGO Replica 频繁插入大数据的问题

当在复制集中频繁插入大数据时有可能出现 “error RS102 too stale to catch up"，出现这个错误的缘由是SECONDARY即副节点的复制速度跟不上了，当须要批量频繁向副本集中写入数据时最好先移除副本节点，待插入完后从新同步。

 

问题5：Mongo集群没有primary但有secondary时链接不上且不能读数据

#mongodb默认是从主节点读写数据的，副本节点上不容许读，须要设置副本节点能够读。
shell
1 repset:SECONDARY> db.getMongo().setSlaveOk(); #要在primary上执行
2 rs.slaveOk()

其余客户端
从secondary 读数据
若是应用程序没有设置相应的ReadReference也可能不能进行读取操做

MongoClientSettings set = new MongoClientSettings();
List<MongoServerAddress> servers = new List<MongoServerAddress>();
servers.Add(new MongoServerAddress("192.168.129.129", 37017));
servers.Add(new MongoServerAddress("192.168.129.129", 37018));
servers.Add(new MongoServerAddress("192.168.129.129", 37019));
set.Servers = servers;

//设置副本集名称
set.ReplicaSetName = "rs0";
//设置超时时间为3秒
set.ConnectTimeout = new TimeSpan(0, 0, 0, 3, 0);

MongoClient client = new MongoClient(set);
MongoServer server = client.GetServer();
MongoDatabase db = server.GetDatabase("test");
MongoCollection coll = db.GetCollection("test");

注：设置驱动的ReadReference也能够经过MongoDB链接字符串配置：mongodb://example1.com,example2.com,example3.com/?readPreference=secondary。经过链接字符串指定的read preference是针对整个链接。

set.ReadPreference = new ReadPreference(ReadPreferenceMode.PrimaryPreferred);
将ReadPreferenceMode设置成Secondary或SecondaryPreferred

 

问题6：addshard 遇到的错误

db.runCommand({addshard:”172.16.5.104:20000″})
{
“ok” : 0,
“errmsg” : “can't use localhost as a shard since all shards need to communicate. either use all shards and configdbs in localhost or all in actual IPs host: 172.16.5.104:20000 isLocalHost:0″
}

遇到这样的错误是因为某些服务启动在 localhost 地址。
通过检查发现 route 启动时，读取 config 服务是读取的 localhost 地址：

./mongos –port 40000 –configdb localhost:30000 –fork –logpath /data/route/log/route.log –chunkSize 1

将 localhost 修改成 IP 地址，问题解决。

 

另外若是不以 localhost 为地址连接，那么 config 启动的时候不能加 –auth 选项，否则会在log文件中遇到如下错误：

ERROR: config servers not in sync! not authorized, did you start with –keyFile?

此时进程没法启动

 

问题7：在 route 和 config 准备完毕后，经过 route 以远程 IP 为地址添加shard，则报错：（有 –auth 参数）

db.runCommand({addshard:'a1:28010′})
{
“ok” : 0,
“errmsg” : “failed listing a1:28010′s databases:{ errmsg: \”need to login\”, ok: 0.0 }”
}

去掉 –auth 参数，添加 shard，成功！

 

依旧保留 –auth 参数，添加用户后，再添加shard。报错：

“errmsg” : “couldn't connect to new shard DBClientBase::findN: transport error: a1:28010 query: { getlasterror: 1 }”

 

问题8：RepairDatabase命令的使用：
数据库总会出现问题的，关于修复的方法以下：
运行db.repairDatabase()来整理记录，但这个过程会比较缓慢。
当MongoDB作的是副本集群时：能够直接把数据rm掉，而后再从新启动。

问题9：当在不是primariy server上运行时，会获得一个"clone failed for wkgbc with error: query failed wkgbc.system.namespaces"

为了修复，须要restart server 不加--replSet选项而且要选用不一样的端口

问题10：LINUX下找出哪一个进程形成的IO等待很高的方法，能够判断是否是IO问题形成的：
#/etc/init.d/syslog stop
#echo 1 > /proc/sys/vm/block_dump
#dmesg |egrep "READ|WRITE|dirtied"|egrep -o '([a-zA-Z*])'|sort|uniq -c|sort -rn|head
   

问题11：访问mongodb的python程序开始出错，常常抛出AssertionError异常

查证是否只是master查询异常，而slave正常，若是只是master查询异常，可判断为master的数据出了问题。

修复过程：

1、在master作db.repairDatabase()，不起做用； 这个时间很长
二、中止slave的同步；
三、对slave做mongodump，备份数据；
四、对master做mongostore，把备份数据恢复，使用–drop参数能够先把原表删除。
五、恢复slave的同步。

 

问题12：碎片整理-replSet架构

1、rs.freeze(60)    在60s内该机器没法成为primary
二、在primary机上进行rs.stepDown([120]) 让该机器成为从节点且在120s内不会成为primary
三、在primary上 ，能够将data的数据删掉 ，启动。数据会自动同步上去。

 

问题13：主备同步滞后

生产环境，最好经过db.printSlaveReplicationInfo()来监控主备同步滞后的状况，当Secondary落后太多时，要及时调查清楚缘由。

当Secondary同步滞后是由于主上并发写入过高致使，（db.serverStatus().metrics.repl.buffer.sizeBytes持续接近db.serverStatus().metrics.repl.buffer.maxSizeBytes），可经过调整Secondary上replWriter并发线程数来提高。

 

注意事项：

·  initial sync单线程复制数据，效率比较低，生产环境应该尽可能避免initial sync出现，需合理配置oplog，按默认『5%的可用磁盘空间』来配置oplog在绝大部分场景下都能知足需求，特殊的case(case1, case2)可根据实际状况设置更大的oplog。

 

·  新加入节点时，能够经过物理复制的方式来避免initial sync，将Primary上的dbpath拷贝到新的节点，直接启动，这样效率更高。

·  当Secondary上须要的oplog在同步源上已经滚掉时，Secondary的同步将没法正常进行，会进入RECOVERING的状态，需向Secondary主动发送resyc命令从新同步。3.2版本目前有个bug，可能致使resync不能正常工做，必须强制(kill -9)重启节点，详情参考SERVER-24773。

 

问题14：MongoDB Secondary同步慢问题

Primary写入QPS过高，致使Seconary的同步没法跟上的问题

默认状况下，Secondary采用16个replWriter线程来重放oplog，可经过启动时设置replWriterThreadCount参数来定制线程数，当提高线程数到32时，同步的状况大大改观，主备写入的qps基本持平，主备上数据同步的延时控制在1s之内

1. 经过mongod命令行来指定      

mongod --setParameter replWriterThreadCount=32

 

1. 在配置文件中指定

setParameter:

replWriterThreadCount: 32