一 简介:此文汇总遇到过和搜集过的故障案例

二 场景案例

      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)

       问题解决 新库本身长于老库,加上本身索引比较长 超过了限制,修改索引名长度即可