一 简介:此文汇总遇到过和搜集过的故障案例
二 场景案例
1 问题描述: mongo集群在无任何业务情况下,mongos所在服务器cpu突然被打满,内核日志报错 mongos被hung住,非常奇怪的问题
问题分析: 此问题经过分析和网上查阅可知,是由numa回收内存问题导致
问题解决: 1 numatl=all方式启动mong 2sysctl.conf中添加 vm.zone_reclaim_mode = 0(回收内存控制参数)
2 问题描述: mongo集群在业务进行压测期间(已做读写分离) primary和secondary同时负载报警
问题分析: 1 通过天兔mongo监控曲线图和mongostat定位 primary发生大量insert操作,每秒大概200+次,频率非常高
2 通过 观察secondary shardlog 日志发现大量的全表扫描语句
问题解决: 1 更改程序逻辑,减少主库操作频率,限制人数
2 添加查询语句索引,避免从库的慢查询语句
3 问题描述: mongo集群在深夜执行定时任务进行查询,量非常大,也非常多,导致负载升高,触发故障切换
问题分析: 此表的数据量已经非常之大,虽然已经添加索引,但是无法解决
问题解决: 归档表的数据量,减少表的数据量大小,负载明显下降,问题解决
4 问题描述: mongo集群负载升高,日志出现大量saslstart相关认证信息日志,时间很长
问题分析: mongo集群3.X采用的鉴权机制正是SCRAM-SHA-1,程序采用的短链接,由于并发太高,导致短链接开销非常大,cpu暴涨
问题解决: 1放弃短链接,改用连接池 2 也可以考虑去掉鉴权认证 3 client : authMechanism='MONGODB-CR'（未验证)
5 问题描述: mongo监控显示, page_faults页错误发生频率的次数再升高
问题分析: 数据库访问数据时发现数据不在内存时的页面数量，表示需要从硬盘进行也交换,MongoDB要读取的数据很多都不在内存中，需要从硬盘读取
问题解决: 1 增大数据库内存 2优化语句 3 降低并发 4 增加分片,减少单台shard的压力
6 问题描述: mongo集群发生负载暴涨,进行分析定位
问题分析思路 1 利用天兔的mongo监控定位具体的操作类型,可以发现,发生大量的insert语句
2 利用mongostat和mongotop定位 具体的发生collection
3 联系研发进行解决
问题原因: 瞬间并发insert导致的cpu暴涨问题
7 mongodump没有问题,但是复制数据到新库报错
问题详细 Failed: restore error:: error creating indexes for: cannot restore index with namespace 'i': namespace is too long (max size is 127 bytes)
问题解决 新库本身长于老库,加上本身索引比较长 超过了限制,修改索引名长度即可