mongodb系列~具体案例

一 增加索引导致的性能问题
1 问题描述
1 并发增加大表index 2 从库异常重启构建索引到一半崩溃
增加索引具体流程
1　主节点查询对应表数据，然后build构建索引。
2 索引数据构建执行完成后，返回客户端OK。(注意：主构建完成后就通知OK给客户端，实际上这时候从节点还没有开始构建索引)
3 生成createIndex对应oplog数据到oplog表
4　从节点获取到createIndex对应oplog操作，然后重放createIndex构建索引。
2 问题解决
1 去掉副本集参数 以单实例+noindexbuidlretry启动 增加索引,增加完再以副本集的成员加入集群() 注意点 该参数已在4.2版本废弃
2 重新构建从库
二 global-lock突然上升-读写TICKET剩余量减少
1 值获取 db.serverStatus().globalLock,默认读写ticket是128个
2 获取顺序 globalLock ==> DBLock ==> CollecitonLock 在globallock层次加的是意向锁,如果是读就是(MODE_IS) 如果是写就是(mode_IX) IS和IX是无需竞争的，所以读写请求可以在没有竞争的情况下，同时传到wiredtiger引擎去处理 ,获取不到ticket,global lock值就会升高
2 问题解决
1 优化语句 2 升级实例内存/CPU
三 MONGO聚合内存不足
内存限制大小是16M db.collection.aggregate([{$group:{_id:"$_id"}}], {allowDiskUse: true}) 添加allowDiskUse解决
四 mongo-config异常-版本3.2X版本
1 问题描述
config servers mongo1 and mong3 differ 3.2.X版本mongo-config还是独立节点启动,所以某个config服务异常会导致config整体异常导致分配不可用
2 问题解决
1 如何进行确认呢
use config db.runCommand({dbHash:1}) 对比3个节点的hash值 取2个正确的
2 停止一个正确hash meta 错误hash meta,然后rsync同步 再同步启动即可
3 问题避免
1 升级mongodb版本避免此问题
五 mongo无法写入 几种情况
1 mongos层挂掉
2 mongos层整体堆积
3 某个分片会话堆积
六 too many open files导致的mongodb服务异常
查看方法
cat /proc/pid/limits|grep 'open files' 最大文件打开数
ls /proc/pid/fd/ |wc -l 已使用的文件句柄
须知
MongoDB的WiredTiger的工作原理跟MMAPv1不太一样，一个集合一个文件，一个索引一个文件。
所以一共有多少集合，至少就会有集合数量x2个打开文件（以1集合文件+1索引文件计算）被占用
解决方式
1 减少collections集合数量
2 加大linux mongodb文件打开数限制
3 服务启动参数添加启动参数加
LimitNOFILE=1024000
LimitNPROC=1024000
七 mongos所在的服务器高负债
mongos本身需要做聚合计算,所以会出现高负载的情况
解决方式
扩展mongos节点 并将节点提供给研发即可，减少单个mongs的资源消耗
八 mongodb secondary节点长期处于rollback状态
关键词 rollback cannot complete at this time (retrying later)
当MongoDB实例进入回滚状态并且回滚数据大于300MB数据时，您必须手动进行干预。它将保持回滚状态，直到您采取措施保存/删除/移动该数据为止，然后应重新同步（现在是辅助数据）以使其与主数据保持一致。这不必是完全重新同步，但这是最简单的方法
九 mongokill会话问题
0 查询语句
db.currentOp({"active" : true, "secs_running" : { "$gt" : 5} })
1 kill语句
db.currentOp().inprog.forEach(function(item){if(item.secs_running > 5 ) db.killOp(item.opid)})
2 相关说明
被kill的会话处于killpending状态.少量的被kill会话会立刻释放,一旦堆积过多,会释放的非常缓慢,建议执行主从切换,重启从节点释放,但是这时候从节点会处于rollback状态,如果回滚太多,就只能重做了,所以不要等有太多会话堆积时才做kill