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()，不起作用； 这个时间很长
2、停止slave的同步；
3、对slave作mongodump，备份数据；
4、对master作mongostore，把备份数据恢复，使用–drop参数可以先把原表删除。
5、恢复slave的同步。
问题12：碎片整理-replSet架构
1、rs.freeze(60) 在60s内该机器无法成为primary
2、在primary机上进行rs.stepDown([120]) 让该机器成为从节点且在120s内不会成为primary
3、在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以内
-
通过mongod命令行来指定
mongod --setParameter replWriterThreadCount=32
-
在配置文件中指定
setParameter:
replWriterThreadCount: 32
