elasticsearch河因大量数据而失败

Question

我在使用mongodb在elasticsearch中设置了河流问题。如果日期的大小在一百万以内，我从mongodb导入数据没有问题。但是当数据大到1000万或更大时，河流就无法索引来自mongodb集合的所有记录。

我在日志中看到了这个错误

org.elasticsearch.river.mongodb.Slurper$SlurperException: River out of sync with oplog.rs collection
    at org.elasticsearch.river.mongodb.Slurper.isRiverStale(Slurper.java:618)
    at org.elasticsearch.river.mongodb.Slurper.oplogCursor(Slurper.java:603)
    at org.elasticsearch.river.mongodb.Slurper.run(Slurper.java:119)

并且通常会说河流陈旧的错误几次。此外，我的mongodb设置中的oplog大小为1024MB。

Answer 1

为什么River陈旧/不同步？

您将数据写入replication oplog的速度比ElasticSearch河可以处理的速度快，并且需要increase the size of your oplog。

如果River处理落后太多，oplog tailable游标将变为“陈旧”，这意味着River不再与MongoDB服务器有共同点（即它“不同步”） 。为确保您已将所有文档编入索引，您必须完全重新同步River，而不是仅从正在插入/更新的新文档中恢复。否则，您的River会在与oplog不同步时错过一些文档更改。

我的MongoDB oplog应该有多大？

default oplog size是64位Linux服务器环境中可用磁盘空间的5％。如果您正在推进数千万次更新并且还需要将这些更新同步到外部ElasticSearch服务器，则1024Mb是一个非常小的oplog大小。如果ElasticSearch与MongoDB在同一台服务器上运行，则可能会加剧您的性能问题。

您可以使用以下方式估算mongo shell中oplog所涵盖的持续时间：

db.printReplicationInfo()

请注意，这是基于您的oplog中观察到的第一个和最后一个条目的估算值。如果您在短时间内处理大量更改，则可以显着降低oplog持续时间。

您可以对适当的oplog大小进行猜测，但更好的方法是使用MMS (MongoDB Management Service)之类的监控系统来捕获一些历史活动。特别是，请查看以MMS计算的Replication Oplog Window和Oplog Db/Hour统计信息中的活动。理想情况下，Other MongoDB-aware monitoring systems应具有类似的计算统计数据。