一简介:今天遇到一个慢日志的排查和解决过程

二 版本:3.0.6

三 架构:分片集群

四 具体过程

     1 程序响应很慢,具体日志寻找定点sql(mongodb慢日志记录在log日志里)

       awk '$NF~/ms$/{print $1,$NF}' shard2.log|sed 's/ms//g'|awk '$2 > 12000 {print $1,$2}' 这里我统计的是大于12S的,

     2 通过分析定位具体sql为查询语句,条件是等值查询

     3 获取collection的所有索引

     db.chenfeng.getIndexes(); 可以发现并没有查询条件的字段为索引

     4  在线添加索引

      db.chenfeng.ensureIndex({"riqi":1}) 在这时候发现一直在卡住

      mongo  --eval "printjson(db.currentOp())"  发现此操作处于锁等待状态,于是改为后台执行

       db.killOp(opid) 干掉进程（这里补充下,mongodb的session即便kill,也需要很久才能释放,相当的无语_

     5 后台添加索引

      db.chenfeng.ensureIndex({"riqi":1},{background:true})

      这里要注意两点

       1 后台执行的意思是不阻塞DML操作,但是本身执行命令会卡住,所以我们采用nohup执行

        nohup  mongo  --eval " db.chenfeng.ensureIndex({"riqi":1},{background:true})"  &

       2 处在后台创建索引的进程是否完成,一定要依赖于explain 定位索引

          db.system.indexes.find() db.chenfeng.getIndexes() 命令都可以查看后台添加的索引,但是这并不代表已经完成,所以查询语句依然会可能应用不到索引(我整整用了一下午排坑)