【问题标题】:ElasticSearch restart spending long timeElasticSearch重启耗时较长
【发布时间】:2016-06-07 19:15:33
【问题描述】:

我有一个四节点的 ElasticSearch 集群。我在集群中插入了大约 100G 的数据后,我重新启动了集群。我发现恢复分片花费了很多时间。我注意到:

  1. 所有主分片通过网关从本地节点恢复,恢复速度非常快。
  2. 所有副本分片都从主分片恢复,我发现副本分片似乎从主分片所在的节点复制到集群中的另一个节点。
  3. 在我完成第一次长时间重启后,我关闭集群并再次重启集群,只需几分钟

我很困惑,为什么我重启集群时我的分片副本再次出现,我的节点中的原始副本数据在哪里?

我已经阅读了一些相关问题,例如:

quick recovery after node restart in elasticsearch

https://www.elastic.co/guide/en/elasticsearch/reference/1.7/indices-synced-flush.html

但是没有用,第一次重启集群时可以停止跨节点的分片迁移吗?

【问题讨论】:

    标签: node.js database hadoop elasticsearch


    【解决方案1】:

    副本恢复缓慢是可以的。当主分片恢复时,集群可用并且应该是黄色的。它可以接受查询,并为此给予优先级,限制其他操作,如写入副本。

    您引用的两个链接很有帮助。当一个节点消失时,集群会认为它已经损坏并开始疯狂地重新洗牌。当一个节点短暂重启或有点晚时,这没有意义。在这些情况下,设置和禁用分配会有所帮助。此外,较新的版本稍等片刻 (https://www.elastic.co/guide/en/elasticsearch/reference/current/delayed-allocation.html)。

    关于同步刷新的链接也不错。这意味着更快地重建副本。不过,根据我的经验,它并没有快多少。

    【讨论】:

    • 感谢您的耐心等待,我创建了一个新的集群并再次测试,在我将数据插入集群后,我运行了flush/synced,然后我找到了主分片和副本分片的syn_ids属性是一样的,我重启了集群,只花了几分钟
    猜你喜欢
    • 2011-10-05
    • 1970-01-01
    • 1970-01-01
    • 2016-05-21
    • 1970-01-01
    • 1970-01-01
    • 2017-06-21
    • 2016-12-22
    • 2011-07-05
    相关资源
    最近更新 更多