一简介:今天遇到一个慢日志的排查和解决过程
二 版本: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() 命令都可以查看后台添加的索引,但是这并不代表已经完成,所以查询语句依然会可能应用不到索引(我整整用了一下午排坑)