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 servers = new List();
　　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