ElasticSearch 1.6 似乎在高可用性测试期间丢失文档

Question

作为将 ElasticSearch 用作可靠文档存储的调查的一部分，我从 Java 应用程序运行基本的 HA 测试，如下所示:

我使用 ElasticSearch 1.6 ( https://registry.hub.docker.com/_/elasticsearch ) 的现成 Docker 镜像设置了一个最小集群，其中:

• 2个主节点/数据节点
• 1 个客户端节点(总是有人可以连接)

然后我运行一个小型加载器应用程序，该应用程序插入 500,000 个文档，每个文档约 1KB。

这在我的机器上大约需要 1 分半钟。期间，我重启了当前的master节点(docker restart)。

在运行结束时，Java API 对我 100% 的查询响应正常，但是当我使用 curl 请求检查文档计数时，一些文档丢失了(在 2 到 10 之间，具体取决于我的运行制作)

即使在索引上有明确的“_refresh”请求，我的文档计数也是一样的。

当然，我主要关心的不是某些文档在崩溃期间无法存储，而是 API 返回的肯定结果(特别是因为我正在使用 WriteConsistencyLevel.ALL 进行测试)。

我知道这张票，但不确定它是否适用于我的基本场景

• https://github.com/elastic/elasticsearch/issues/7572

我的插入是这样完成的:

client.prepareUpdate("test", "test", id)
      .setDoc(doc).setUpsert(doc)
      .setConsistencyLevel(WriteConsistencyLevel.ALL)
      .execute.get.isCreated == true

其余代码可以在这里找到: https://github.com/joune/nosql/blob/master/src/main/scala/ap.test.nosql/Loader.scala

如果您认为我做错了什么，请提出建议。

(我知道有些人会回答说将 ElasticSearch 视为可靠的文档存储是完全错误的，但这是研究的目标，而不是我期望的那种答案)

---

更新 Andrei Stefan 要求的额外日志

> grep discovery.zen.minimum_master_nodes elasticsearch.yml
discovery.zen.minimum_master_nodes: 2

> curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{"transient":{"logger._root":"DEBUG"}}'
{"acknowledged":true,"persistent":{},"transient":{"logger":{"_root":"DEBUG"}}}%
> curl -XPUT 'http://localhost:9200/_cluster/settings' -d '{"transient": {"logger.index.translog":"TRACE"}}'
{"acknowledged":true,"persistent":{},"transient":{"logger":{"index":{"translog":"TRACE"}}}}%

使用 200,000 个条目运行测试:

0 KO | 200000 OK
> curl -XGET 'localhost:9200/test/test/_count?preference=_primary'
{"count":199991,"_shards":{"total":5,"successful":5,"failed":0}}%  

我把日志放在这里:https://gist.github.com/ab1ed844f2038c30e63b

Answer 1

I'm aware of this ticket, yet unsure if it applies to my basic scenario https://github.com/elastic/elasticsearch/issues/7572

我做了一些挖掘，结果确实如此。原因是在节点关闭期间，我们在关闭索引服务之前关闭了传输层，这意味着正在进行的操作被有效地分割开(就像网络问题的情况一样)。显然这不行，我打开了https://github.com/elastic/elasticsearch/issues/12314跟踪这个。

附带说明 - 在 Elasticsearch 2.0 中，我们添加了一个 shard header到响应，指示有多少分片成功。这为您提供了一种检查操作是否确实成功写入所有分片并在需要时重试的方法。这是成功响应的示例(同时写入主副本和副本)。

{
    "_shards" : {
        "total" : 2,
        "failed" : 0,
        "successful" : 2
    },

最后请注意，分片失败并不意味着 #7572 发挥了作用。这是极不可能的。但是，在 #7572 确实发生的所有情况下， header 都将有 total != successful。