生产事故(MongoDB数据分布不均解决方案)

可以很明显可以看到我们这个集合的数据严重分布不均匀。

一共有8个分片,面对这个情况我首先想到的是手动拆分数据块,但这不是解决此问题的根本办法。

    造成此次生产事故的首要原因就是片键选择上的问题,由于片键选择失误,在数据量级不大的时候数据看起来还是很健康的,但随着数据量的暴涨,问题就慢慢浮出了水面,我们使用的组合片键并不是无规律的,片键内容是线性增长的,这就导致了数据的不正常聚集。由于数据分布不均匀,我们有两个分片的磁盘使用率接近80%,数据还在持续增长,这个问题必须尽快解决。

涉及到此次事故的集合一共有三个,总数据量加起来接近30T,数据总量300亿左右。

下面是我解决此问题的解决方案:

方案一:

第一步:创建一个新的分片表,片键我选择_id做hashed分片,并提前分好了数据块,降低在恢复期间频繁切割数据造成的服务器压力。

sh.shardCollection("loan_his.collection",{_id:"hashed"}www.zheshengjpt.com,false,{numInitialChunks:1024})

第二步:单独连接各个分片将8个分片的数据全量备份:

nohup mongodump -u loan_his -p loan_his --authenticationDatabase loan_his  -h ${replset} --db loan_his --collection ${collectionName} --query ‘{"txdt": { $lte: "2019-07-09"} }‘ -o ${bak_dir} &>>  ${log} &

你可能会问为什么不连接mongos,因为我在连接mongos做数据备份时出现了以下异常:

2019-07-08T16:10:03.886+0800	Failed: error writing data for collection `loan_his.ods_cus_trad` to disk: error reading collection: operation was interrupted

可能是因为集合内的数据坏块吧,此异常信息是我备份了将近70%的数据后突然抛出的异常信息。

除了这个原因,单独备份各个分片的数据后你能够自由控制恢复数据的时间窗口,不会因为恢复单个数据文件时间较长,突发意外情况导致恢复中断从头再来的窘境。能够根据服务器的状态避开高峰期来进行数据恢复。

备份期间我发现了有时候备份出来的总文档数和 db.collection.getShardDistribution() 查看的文档数不一致,我还以为是备份期间出了问题,但我删除当前备份文件后重新备份出来的文档数还是和之前一样。目前不知道是怎么回事,怀疑是坏的数据块引发的我问题,备份出来的数据一般会比原数据量多几万条数据,有时候会少一些。

第三步:恢复数据:

 mongorestore -u loan_his -p loan_his --authenticationDatabase loan_his -h 10.0.156.9:27017 --db loan_his  --collection  ${collectionName_two}  /mongodb/${collectionName}/replset_sh2/loan_his/${collectionName}.bson  &>>  ${log}

在恢复数据前千万要记得不要创建索引!否则性能极差,速度非常非常慢!在使用mongodump工具备份时,在数据文件的同级目录下会有一个 XXXXX.metadata.json 索引文件,默认会在数据恢复完毕后执行创建索引的操作。

此处有坑需要注意:因为备份出来的数据是由原表备份出来的,那这个索引文件也是原表的索引,由于原表我使用的是组合片键做的分片,所以在原表内会存在一个由片键组成的组合索引,并且不是后台创建的组合索引!!!这意味着如果你使用此索引文件来给新表创建索引,会造成这个集群处于阻塞状态,无法响应任何操作!!直至索引创建完毕。所以你可以将这个索引文件备份到其它目录以作参考,然后将原文件删除就可以了,恢复数据时不会有其它的问题。

如果恢复期间出现了意外情况导致恢复失败,比如节点宕机什么的,不需要担心,重新执行恢复程序,数据文件不会重复增加,因为备份出来的数据文件包含mongodb自带的 Objectld对象_id ,导入时,如果已存在此ID,将不会插入数据。注意:在不同集合是允许出现相同ID的,所以在使用方案二恢复数据时,新产生的数据不能通过新表A备份出来汇入新表C,需要通过原始数据文件重新导入。

第四步:创建索引:

待所有数据恢复完毕后再创建索引,一定要记得后台创建!!!你也可以将索引拆分,一个一个的来。如果觉得此操作对业务影响较大,请看本文最后的解决方案。

mongo 10.0.156.2:27017/loan_his -uloan_his -ploan_his -eval ‘db.getSiblingDB("loan_his").runCommand({createIndexes: "collection",indexes: [{"v":2,"key":{"_id":1},"name":"_id_","ns":"loan_his.collection"},{"v":2,"key":{"opnode":1.0,"txdt":1.0,"acct":1.0,"crdno":1.0},"name":"opnode_1_txdt_1_acct_1_crdno_1","ns":"loan_his.collection"},{"v":2,"key":{"txdt":1.0,"opnode":1.0,"acct":1.0,"crdno":1.0,"pbknum":1.0},"name":"txdt_1_opnode_1_acct_1_crdno_1_pbknum_1","ns":"loan_his.collection","background":true},{"v":2,"key":{"acct":1.0,"txdt":1.0,"opnode":1.0},"name":"acct_1_txdt_1_opnode_1","ns":"loan_his.collection","background":true},{"v":2,"key":{"crdno":1.0,"txdt":1.0,"opnode":1.0},"name":"crdno_1_txdt_1_opnode_1","ns":"loan_his.collection","background":true},{"v":2,"key":{"pbknum":1.0,"txdt":1.0,"opnode":1.0},"name":"pbknum_1_txdt_1_opnode_1","ns":"loan_his.collection","background":true}]})‘

停止失控索引:

一旦你触发一个索引,简单的重启服务并不能解决这个问题,因为MongoDB会继续重启前的建索引的工作。如果之前你运行后台建索引任务,在服务重启后它会变成前台运行的任务。在这种情况下,重启会让问题变得更糟糕。MongoDB提供了选项“noIndexBuildRetry”,它会指示MongoDB重启后不再继续没建完的索引。如果不小心在前台创建了索引导致集群不可用,可以使用--noIndexBuildRetry 参数重启各个分片来停止索引的创建过程,只用重启主节点就可以了。如果是在后台创建索引,重启时记得加上--noIndexBuildRetry,否则重启后创建索引的线程会重新被唤醒,并由后台创建变为前台创建,导致整个集群不可用。

mongod -f $CONFIGFILE --noIndexBuildRetry

此方案迁移期间不用通知业务系统做变更,把数据迁移完毕后,通知业务系统将表名变更,弊端就是在你迁移的过程中数据还是会持续增长的,问题分片的磁盘容量会越来越少。

方案二:

为了避免在迁移期间数据仍在增长,导致数据还没迁移完毕磁盘就爆满的情况,可以选择停止往旧表B内写入数据,创建一个健康的新表A,新的数据往新表A内写,具体的查询方案需要应用系统的配合。然后将旧表B的数据迁移至新表C中,最终将新表A的数据汇入新表C , 完成数据迁移。此次迁移数据耗时共9个月!!!片键一定要慎重选择,因为我们使用的MongoDB是3.4.7版本的,不支持修改片键,最新版本支持片键的修改。

接下来介绍数据量较大时如何构建索引--减少业务最少影响

在数据量较大或请求量较大,直接建立索引对性能有显著影响时,可以利用复制集(数据量较大时一般为线上环境,使用复制集为必然选择或者使用分片.)中部分机器宕机不影响复制集工作的特性,继而建立索引。

(1)首先把 secondary server 停止,再注释 --replSet 参数,并且更改 MongoDB port 之后重新启动 MongoDB,这时候 MongoDB 将进入 standalone 模式;

(2).在 standalone 模式下运行命令 ensureIndex 建立索引,使用 foreground 方式运行也可以,建议使用background方式运行;

(3)建立索引完毕之后关闭 secondary server 按正常方式启动;

4.根据上述 1~3 的步骤轮流为 secondary 建立索引,最后把 primary server 临时转换为 secondary server,同样按 1~3 的方法建立索引,再把其转换为 primary server。

日志内容大致如下:

2019-09-24T18:51:39.003+0800 I -        [www.tongyayule.com conn33]   Index Build: 838416900/876543270 95%
2019-09-24T20:10:08.360+0800 I INDEX    [www.jiuyueguojizc.cn conn33] 	 done building bottom layer, going to commit
2019-09-24T20:10:26.001+0800 I -        [www.wuji5pingtai.cn conn33]   Index: (2/3) BTree Bottom Up Progress: 11684400/876543270 1%
done building bottom layer, going to commit

原文地址:https://www.cnblogs.com/laobeipai/p/11966231.html

时间: 2024-10-25 10:19:42

生产事故(MongoDB数据分布不均解决方案)的相关文章

因我而起的生产事故

首先,祝大家新年快乐!应该陆陆续续开始踏上了回家的征程吧! 生产事故 产品上线一段时间之后,技术支持反馈客户现场一个进程总是挂掉或者不干活!最开始不紧不慢的查找问题,后来老大很生气说:生产事故很严重,你们居然不重视!成立了一个应急小组,专门解决此问题,其中包括我! 事故原因 经过2.3天没日没夜的艰苦奋斗,终于找到进程挂掉的原因,问题因我而起.大约去年8月,做一个项目,与大数据对接,把数据推给它,然在加上了推送部分的代码,最开始那个模块是没有日志的,然后给加上了日志打印,当时也没考虑那么多,多线

深入认识二进制序列化--记一次生产事故的思考

一 概要 二进制序列化是公司内部自研微服务框架的主要的数据传输处理方式,但是普通的开发人员对于二进制的学习和了解并不深入,容易导致使用过程中出现了问题却没有分析解决的思路.本文从一次生产环境的事故引入这个话题,通过对于事故的分析过程,探讨了平时没有关注到的一些技术要点.二进制序列化结果并不像Json序列化一样具备良好的可读性,对于序列化的结果大多数人并不了解,因此本文最后通过实际的例子,对照MSDN的文档对于序列化结果进行详细解析,并意图通过本次分析对于二进制序列化的结果有直观和深入的认识. 二

凌晨1点突发致命生产事故,人工多线程来破局!

有一个读者问我:你认为一个程序员具备什么样的能力,才算得上是厉害的程序员? 我答:拥有解决问题的能力的程序员. 这个回答貌似有点抽象,不要紧看下面的文章你会慢慢有所了解. 一.解决问题的能力 很多年前,当我还是一个小菜鸟的时候,我的领导经常告诉我,解决问题的时候,不要局限于技术本身,并且形象的给我举了一个例子. 有一次两个程序员一直讨论,如何判断两台服务器之间是否网络正常,争争吵吵了很久.旁边的一个测试说,Ping 一下不就知道了吗?就这样他们用 Java 代码实现了 Ping 操作解决了这个问

生产事故:误删/lib64,移走/lib64目录

事故背景: 有一台机器装不上nagios监控,yum install openssl报一个关于"libkrb5.so.3"冲突的错误. 解决过程: 1./lib64事故 关于"libkrb5.so.3"冲突的错误,查了一些文章没有解决,就想着把libkrb5卸掉,rpm -e libkrb5.rpm,卸载有关联冲突,然后就rpm -e libkrb5.rpm --nodeps(事实证明,如果不清楚软件的依赖,最好不要"--nodeps"),一卸载

MongoDB集群解决方案-分片技术

MongoDB,NoSQL技术的实现,基于分布式文件存储的数据库,由C++语言编写.主要是解决海量数据的访问效率问题,为web应用提供可扩展的高性能数据库存储解决方案 MongoDB集群的实现方式: 1.Replica Set:也叫作副本集,简单来说就是集群中的服务器包含了多分数据,保证主节点挂掉了.备节点能够继续的提供服务,但是提供的前提就是数据必须要和主节点的一致,如下图: MongoDB(M)表示主节点,MongoDB(S)表示从节点,MongoDB(A)表示仲裁节点: M节点存储数据并提

linux日志审计项目案例实战(生产环境日志审计项目解决方案)

所谓日志审计,就是记录所有系统及相关用户行为的信息,并且可以自动分析.处理.展示(包括文本或者录像) 推荐方法:sudo配合syslog服务,进行日志审计(信息较少,效果不错) 1.安装sudo命令.syslog服务(centos6.4或以上为rsyslog服务) [[email protected]_back ~]#rpm -qa "sudo|syslog"   查询系统是否已安装sudo.syslog程序 rsyslog-5.8.10-8.el6.x86_64 sudo-1.8.6

从一次生产事故说起——linux的单用户模式,救援模式等等

伴随着今年linux上面最大一个安全漏洞bash漏洞的出现,我们公司也开始了风风火火的漏洞修复工作,机器一多,也就容易出问题,有台64位的linux服务器一不小心就升级了32位 bash 的rpm,由于root,oracle这些用户默认都是通过/bin/bash来登陆的,这就造成了用户不能登陆服务器造成了极大的困扰,下面就是应对的办法,由于在生产环境解决的时候没法截图,通过虚拟机的环境来模拟当时的情况: 我们通过删除bash的rpm包的方式来模拟生产商bash包装错的情况: 在这个以前,我们先来

生产案例之运维解决方案

大视频解决方案 一站式提供"海量存储.高效分发.极速网络"等强大服务, 轻松坐享CCTV-5.新浪微博.知乎等量级的传播能力.广泛应用于 游戏直播.娱乐直播.泛生活直播. 教育类. 远程医疗. 企业远程视频会议等典型场景 https://www.aliyun.com/solution/media/?utm_medium=text&utm_source=baidu&utm_campaign=hyy&utm_content=se_119788

完了!生产事故!几百万消息在消息队列里积压了几个小时!

作者:中华石杉 来源:https://github.com/doocs/advanced-java/blob/master/docs/high-concurrency/mq-time-delay-and-expired-failure.md 一.面试题 如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决? 二.面试官心里分析 你看这问法,其实本质针对的场景,都是说,可能你的消费端出了问题,不消费了,或者消费的极其极其慢.接着就坑爹了,可能