MongoDB·最佳实践·count不准原因分析

  • 时间:
  • 浏览:1
  • 来源:彩神3D_神彩3D官方

从chunk迁移过程都能否 看出,我希望迁移过程失败,亲戚亲戚亲戚亲们尚不得知它是是否是会清理目标端数据,理论上也会造成目标分片上的孤立文档,不过而且movechunk串行出理 ,即使有,最多也就一一二个 chunk块有现象图片;但而且最后一步的清理源端旧chunk数据失败,则必然会在源端造成孤立文档,而且最差的具体情况下而且会产生少量chunk的孤立文档。

从也不方面考虑,我希望产生了孤立文档,mongodb提供了清理分片上所有孤立文档的法律法律依据,在每一一二个 sharding节点上执行,法律法律依据如下

一般来说,除了而且secondary延迟而且造成查询secondary节点数据不准以外,关于count的准确性现象图片,在MongoDB4.0官方文档涵盖这么搞笑的话

On a sharded cluster, db.collection.count() without a query predicate can result in an inaccurate count iforphaned documents exist or if a chunk migration is in progress.

To avoid these situations, on a sharded cluster, use the db.collection.aggregate() method

孤立文档是而且move chunk期间守护进程异常关闭造成的迁移失败或清理迁移后的源端chunk失败造成的,使得这累积记录在源端和目标端都处于,而在mongo分片集群的定义中,一一二个 文档时要且只有属于一一二个 chunk和shard。

显而易见,孤立文档而且原因分析分析count不准,而且孤立文档量很多,后会造成占用额外的磁盘存储资源。

通过mongod日志而且sh.isBalancerRunning()命令都能否 确认,该表处于move chunk阶段;

为了方便观察,亲戚亲戚亲戚亲们将_waitForDelete设置为1,即迁移chunk完成后立即删除源端分片数据再进入下一次地chunk迁移,都能否 观察到count结果值首先有一一二个 快速的增长过程,而且是一一二个 相对缓慢的减少过程;

每个chunk迁移循环上述过程,直到sh.isBalancerRunning()为OFF后,稳定在一一二个 准确值。

从上边都能否 看多,只有不带谓词条件的全表count才会处于结果不准的现象图片,而且在你这个 具体情况下,count结果值直接从表和chunk的元数据信息获取,在分布集群模式下也不挨个去各个分片的chunk获取该表存取的count值,而且做一一二个 累加返回,而且孤立文档的处于就造成返回结果大于准确结果。上个案例中一一二个 产生了7090977个孤立文档。

而MongoDB3.6官方文档却是这么描述的

On a sharded cluster, db.collection.count() can result in an inaccurate count if orphaned documents exist or if a chunk migration is in progress.

To avoid these situations, on a sharded cluster, use the db.collection.aggregate() method

mongodb在设计实现上,真正从源端向目标端copy数据的过程是串行的,也也不只有逐个chunk迁移,而且出于迁移时延上的考虑,最后一步的清理源端分片残留数据的操作是异步的,也也不当修改完config元数据后,马都能否 不能 进入下一一二个 chunk的迁移,很多时要等待图片源端分片清理完成。

清理源端分片旧chunk数据的操作放上去一一二个 队列中,在一点场景下它而且而且清理缓慢造成堆积,而且这时primary节点crash,就会产生孤立文档。

从一方面说,减少孤立文档产生的数量,默认具体情况下,清理源端分片数据是异步调用的,但也都能否 通过命令设置成同步调用,也也不设置完后 我希望primary节点crash,最多只有一一二个 chunk而且产生孤立,但很多推荐,意义也不大。设置法律法律依据为

一般来说,movechunk操作要花费有以下步骤

1 一起去追求时延和准确性,都能否 设置负载均衡窗口,在窗口以外禁止move chunk

2 强调数据准确性的场景,使用db.collection.aggregate()法律法律依据代替count

3 针对带谓词条件的count操作,将mongo版本升级到4.0以上

4 针对跳出少量孤立文档的具体情况,做孤立文档清理

而且是MongoDB4.0完后 的版本,count操作即使带了谓词条件结果值也会不准。这是而且在4.0版本完后 带谓词条件的count操作原理和普通的query不同,它很多会去检查遍历到的chunk真是只属于一一二个 shard,而4.0完后 的版本,其原理就和普通query一样了,杜绝了结果值不准的具体情况。

从设计哲学上分析,既然4.0版本也这么保证不带谓词条件的count准确性,都能否 认为是本身性能与时延上的折衷,而且在你这个 count场景下,大累积业务很多时要非常精准的count结果,而更强调"fast count"理念,即不不遍历数据,直接从元数据层面返回结果值;当然你时要准确的count值,也详细都能否 用aggregate法律法律依据代替,也不只有认为这是一一二个 bug,而且说有待优化的点,而且也不本身count法律法律依据在命令展示上严重不足兼容,容易引起误解。

也也不说,MongoDB4.0分片集群模式下,针对不带谓词条件的全表count操作的返回结果是不准确的,主要包括以下本身场景。在MongoDB4.0完后 的版本,即使不带谓词条件,在以下本身场景下count值也不准。

1 处于孤立文档

2 mongo分片集群实物正在进行move chunk操作

本文主要针对这本身场景,分析count不准的原因分析分析和规避法律法律依据

也很多模拟出孤立文档很简单,只时要在少量movechunk期间强制杀掉主节点mongod守护进程即可,比如在已有一一二个 shard的具体情况下,加进另外一一二个 shard到分片集群中,这时必然会涉及到少量的movechunk操作,本文也不采用你这个 法律法律依据。

在move chunk过程中,而且是非count操作,普通的query肯定无法容忍你这个 错误的,而且根据完后 的迁移过程分析,在movechunk的copy data期间,源端接收所有的访问请求;在修改元数据后,delete源端数据期间,目标端接受所有的访问请求。也也不说,普通的query会去判断查询时要的chunk真是属于且只属于一一二个 shard,详细遵循config server中的元数据,也不它的查询结果是准确的。