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

Question

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

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

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

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

我的机器大约需要1分半钟.在此期间,我重新启动当前主节点(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

我知道这张票,但不确定它是否适用于我的基本场景 https://github.com/elastic/elasticsearch/issues/7572

我做了一些挖掘,我发现它确实如此.原因是在节点关闭期间,我们在关闭索引服务之前关闭传输层,这意味着正在进行的操作被有效地分区(完全类似于网络问题).显然这不好,我打开https://github.com/elastic/elasticsearch/issues/12314来跟踪这个.

作为旁注 - 使用Elasticsearch 2.0,我们在响应中添加了一个分片标头,表明有多少分片成功.这为您提供了一种方法来检查操作是否确实已成功写入所有分片,并在需要时重试.这是成功响应的一个示例(写入主副本和副本).

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

最后请注意,碎片失败并不意味着#7572已经发挥了作用.这是非常不可能的.但是,在#7572确实发生的所有情况下,标题都会有!=成功.

Answer 2

这里的评论中有很多好的笔记.我谦虚地建议只有两个符合条件的主节点的集群不是"高可用性".elasticsearch 文档声明:

建议避免只有两个符合条件的主节点,因为两个法定数量是两个.因此,丢失任一主节点都将导致无法运行的集群.

实际上,在discovery.zen.minimum_master_nodes 正确设置为2 的双主集群中,只要任一节点出现故障,就无法拥有主节点,因此您不再拥有集群.如果minimum_master_nodes设置为1,那么你将面临一系列不同的问题(裂脑).我们为每个ES集群运行3个主服务器(此外,运行专用主服务器) - 我很想知道您是否使用3个主集群获得不同的结果.

也就是说,API确认收到你的文档然后无法坚持它们似乎仍然是不正确的,但我认为最终它可能会回到这样一个事实:elasticsearch不是为了运行生产类实现而设计的只有两个符合主节点的节点.