关于我们

质量为本、客户为根、勇于拼搏、务实创新

< 返回

mongdbshard集群均衡导致宿主机CPU飙到100%处理

发布时间:2022-07-27 13:54:09
原因:mongdbshard集群均衡导
致宿主机CPU飙到100%处理

      由于开发设计时对mongo不熟悉,只设计了结构和索引,并没有设计片键,在经过巡检发现mongo业务库没有添加片键,导致数据都集中在某个shard中,数据分布不均衡.

处理过程:

     1.规划片键,经过与架构师讨论,设计片键为operate_date,但是没有想到这里有坑,开发为了解决时区问题,将operate_date类型设置为了字符串,

         但是没有告知我,我还是以date   去建立片键,导致业务库 无法访问,紧急粗暴的把config中业务库的集合分片数据干掉了。这种方式为下个线上问题留下隐患.

    2.由于线上有二十多个业务库,我先按数据量从小到大依次处理,最后还剩下两个大库,待时处理.

   3.一个晚上8点多,客户访问数减少了,开始处理 大库A,将其中一个数据量大的集合加上片键后,触发均衡,CPU一直涨,最后飙到100%,过了一个小时,开始有客户反馈,说无法进行操作,影响生产了。

      还是按上次粗暴处理,直接动了config库,将 大库A的 chunks,collections,locks直接干掉了,过了一会 CPU降下来了,再过了一会,客户反馈部分数据找不到,经过紧急对比发现大库A中数据量最大的一个集合丢失10%左右的数据,

      没办法,从备份中恢复.

    4.反思:

             通过阅读官方文档 官方说明 禁止直接操作config库,由于直接干掉了chunks数据,导致部分chunk无法访问到,导致表现为部分数据无法找到.

     5.降cpu处理

         1.sh.stopBalancer()

         2.待Balancer状态为false后  通过top 找出cpu占用最高的进行,找到相应的mongo进程.

         3.找出问题shard,shard我部署为PSS模式,一般是在P节点,执行db.stepDown(120) 降级,然后将P节点shutdown,然后再启动,如果因为locks 导致无法 shutdown,那就没办法了优先让客户先生产,ps找到pid,直接kill掉,

             复制集故障转移会自动在两个S中选举一个为P,依次将问题shard的所有节点都重启一次,释放负载. 主要原因是  均衡过程中 有些lock的问题,可以通过db.currentOp() 找到对应的耗时操作. 

         4.重启后 CPU会逐渐将下来。


/template/Home/Dawn/PC/Static

选择风纳云,也许是您成就一番大事业的开端

注册账号