原因:

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

成都创新互联专注为客户提供全方位的互联网综合服务，包含不限于成都做网站、网站制作、兰考网络推广、小程序开发、兰考网络营销、兰考企业策划、兰考品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们大的嘉奖；成都创新互联为所有大学生创业者提供兰考建站搭建服务，24小时服务热线：13518219792，官方网址：www.cdcxhl.com

处理过程：

   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会逐渐将下来。

名称栏目：mongdbshard集群均衡导致宿主机CPU飙到100%处理-创新互联
地址分享：http://cdweb.net/article/degsei.html