1

这个问题有两个方面,都与指数有关。

我有一个包含 5.3 亿个条目的数据集,每个条目都有一个包含 10 个元素的数组。我正在使用单个 mongod。我正在批量插入后的数组上构建索引。该数组有两个字符串类型的键值对 - int。

我已经推断/研究过,在构建之前建立索引是 mongodb 的设计目的,如果没有大量的 ram/swappable-virtual-memory,就无法(插入后)对如此大的数据集进行索引。

一:指数构建阶段

索引构建的阶段是什么,我正在查看日志,看到它从 0 上升到 100%,只有在达到 100% 时才开始计数(与排序有关??)。第二阶段比第一阶段慢得多。还有其他需要完成的通行证吗?

二:索引状态

我不打算以这种速度观看索引构建,并且我有一个索引数据集作为备份(我不再信任它,请继续阅读)。所以,我kill -9'd的过程。我再次启动了该过程,日志显示数据库确认索引构建操作正在进行并且错误结束,但除此之外没有其他内容。索引显示在db.<db-name>.getIndexes()列表中。

我觉得这很奇怪,尤其是getIndexes一点,我知道在这种情况下索引构建永远不会结束,现在我不能相信我认为索引结束的备份。

我至少希望数据库平台处于一致状态,或者在它通过我的控制之前达到一个状态。因此,要么回滚索引构建,完成它,要么拒绝在没有恢复操作的情况下启动。

那么如何确定我的数据库是否处于一致状态,特别是索引?

4

1 回答 1

2

那么如何确定我的数据库是否处于一致状态,特别是索引?

为此,有一个validate命令。该命令是一个阻塞命令,就像修复一样,但看起来它有几个选项。

因此,要么回滚索引构建,完成它,要么拒绝在没有恢复操作的情况下启动。

同意。并且日志应该清楚地了解数据库重新启动时的状态。但是,MongoDB 肯定还没有“存在”。

第二阶段比第一阶段慢得多。还有其他需要完成的通行证吗?

实际上,一旦完成第二阶段,数据库就会锁定并执行一个巨人fsync,因为它将新创建的索引刷新到磁盘。你杀它的时候它可能就在这里。

我最后一次看到这个过程发生时,在fsync. 给定数据的大小,这将代表刷新到磁盘的数据的演出和演出。对驱动器的速度与索引进行一些数学运算,但这个阶段肯定会代表很多等待时间。

于 2012-02-02T08:21:12.657 回答