20220211故障-MongoDB最大支持数据量

📢📢📢📣📣📣

在日常工作中处理各种需求和故障，尤其以故障响应尤为重要。
如果没有及时处理好产生的故障，所产生的损失，用我以前一句话所说：秒秒都是钱。
金鱼哥突发想法，弄一个新的专栏记录日常工作中所遇到的故障，借此希望我的分享和总结能给大家有所启发。

也许是命运中的安排，昨天是我在新单位（外包到一家大公司）进场第一天，还未熟悉各种环境的情况下，就被带上去跟进遇到的故障。
庆幸的是，虽然我已经有11个月没在技术一线岗位，但我的技术功底一直都在。再次体现到基础，思维，经验真的很重要，让我定位到问题😜😜😜而让相关人员去沟通后续的解决办法。

故障描述：

中午时分，我和交付经理去到XX院5楼的信息中心里，在处理的是开发商（吉ao）的开发和公司的支持工程师，从大家的口中了解到相关情况：

应用使用MongoDB 3.4，此前是3台机器搭建集群+一仲裁节点，周四开发商尝试拿一个节点进行单节点测试，因此有一个节点数据已经被删除。但做了周四晚的快照（使用XX云），所以有一个以快照方式的备份。

目前当天情况：
1.一主一从一仲裁节点
2.主从节点无法同时启动
2.先启动主节点时，节点状态为SECONDARY，再启动从节点，从节点无法启动，进程直接出现异常被关闭。

测试成果：
将主节点作为单机启动，可读不可写，写入时会和上述从节点出现一样的异常。后续将主节点部分数据删除，主节点可读可写。

以下为一些相关日志（因我刚进场，所以没拿到相关更多资料，现在排查也只能现场看相关日志）

主节点一直为 secondary的状态，所以也只能进行读的操作，不能进行写，整个集群存在问题。
因此现在业务上不能进行相关上传操作（不能写），但可进行各种查询。

吐槽点：

o((⊙﹏⊙))o 去到现场，发现库全部运行在windows server上，查看日志是何其的痛苦。。。
现场人员对自身应用的架构都不太熟悉，问应用的并发大吗？也不知道（如果并发不大，集群毛线）。。。所以去到现场还需要各种了解，耗费时间。。。
以上两点都阻碍处理故障的效率。。。🤦‍♂️🤦‍♂️🤦‍♂️

然后，为啥现场还在不断纠结集群上的各种问题，为啥不以先恢复业务为先导呢？🤦‍♂️🤦‍♂️🤦‍♂️
也足见没有对应的应急预案。也可想自己之后的工作需要完善的东西是何其之多。

测试与尝试：

看着他们在纠结集群的事，我初来乍到，本想围观一下，但想着，我既然跟过来，如果他们处理不到，那只会铁定加班。。。要知道很远啊，这XX院在科学城，我加在白云区广园路。。。所以忍不住出声了：

“先以恢复业务为导向，先别纠结集群上的问题，先用单节点把服务重新启动起来，恢复好业务。根据你们反馈，使用并发不大，单节点没问题的，先恢复。”

建议开发找了有数据的单节点上，让他修改不同的端口起动数据库。
启动后，出现了周四晚说的现象，将节点部分数据删除，节点可读可写。

让开发进行现象测试，删除一些文件后，的确可上传文件，但当上传大文件时，就不能继续上传，会导致数据库崩掉，重启库也只能读，再写也会崩溃。
从日志中，根本看不出有效的报错信息。（win中看日志很痛苦。。。为啥不用linux，low成这样吗？😥）

看到这现象，我在旁边，建议再测试给我看。
这时我记录一下大概的容量情况，看看他删除的文件容量大小，之后对比上传的容量大小。
测试过程中，只要上传的大小，不超过删除的容量大小是可上传的，超过，就崩溃。而磁盘容量是够的。

看到这里，突然灵机一动，难道是有什么限制？
这个时候，马上去翻查自己的笔记和去找找网上文章。

故障分析：

查询自己的笔记中，有一段：

限制

MongoDB通常适用于64位操作系统，32位系统只能寻址4GB内存，意味着数据集包含元数据和存储达到4GB，Mongodb就无法存储额外的数据了，强烈建议32位系统使用Mongodb可以自己测试使用，生产环境一地使用64位操作系统。
最大文档大小有助于确保单个文档不会使用过多的RAM或在传输过程中占用过多的带宽。要存储大于最大大小的文档，MongoDB提供了GridFS API。

MongoDB支持BSON文档嵌套的级别不超过100。

副本集

在Mongodb3.0中副本集成员最最多支持50个，也就是说副本集做大支持50个节点，副本集每个节点数据支持32T，副本集每个实例建议数据不要超过4T，数据量大备份恢复时间会很长。

来了，看到重点了，“副本集每个实例建议数据不要超过4T”，之后马上让对应的开发一查，3915G，这时候终于知道问题所在了，怪不得删除一些数据后就可以重新写入，因为已经达到人家的上限了，所以肯定不能再写了。

查看官网（https://docs.mongodb.com/v3.4/reference/limits/）具体的描述：

存储限制

分片会使用默认的chunk大小为64M，如果我们的分片key （片键）values值是512字节，分片节点支持最大32768个，最大集合大小为1TB。
一个片键大小不能超过512字节。

那如果不做相关设置，在默认chunk大小为64M的情况下，使用128字节，最大也只是4TB的容量。
不用想，肯定没考虑到各种，而且，也不会使用64字节这么小的values值。

所以推断由于单实例由于快达到容量限制而导致出问题。

用阿里云的MongoDB规格也可看出端倪：

故障处理：

做到这样，已经是我第一天入职的人能够做的了。
之后就让开发商和整个组的运维经理沟通后续的解决了。（我初来乍到，环境完全不熟悉呢）

开发商负责人，运维经理，用户，经过商量沟通后，先备份数据（有2个节点的数据在，而且有快照，但zheng wu云的快照曾经有坑，在我心里，还是有个物理备份保守点，但备份由于小文件太多肯定太久了，所以暂时就这样），然后统计2020年前的数据（统计后，只有200多G），再进行数据删除，以解决燃眉之急。

这问题最终还是需要开发商处理好对应的逻辑。
在选用数据库的时候，也要评估数据库的特性，在以前的数据量是可以满足，但肯定没想到近2年的数据量爆发。

也听说后续开发商会进行大整改。
那这事情就告一段落。。。

总结

以上就是【金鱼哥】刚上班第一天遇到的故障（什么都未开始了解，就。。。）。希望能对看到此文章的小伙伴有所帮助。

如果这篇【文章】有帮助到你，希望可以给【金鱼哥】点个赞👍，创作不易，相比官方的陈述，我更喜欢用【通俗易懂】的文笔去讲解每一个知识点，如果有对【运维技术】感兴趣，也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💕💕！