Question

我刚刚将我的群集从5.6升级到6.1。我按指定的documentation进行了滚动升级。看起来我正在使用的设置在6.1中不再可用。这本来没问题，但现在我甚至无法启用分片，所以现在我的最后一个节点不会分配它的分片。做一些简单的事情：

curl -XPUT 'localhost:9200/_cluster/settings?pretty' -H 'Content-Type: application/json' -d'
{
    "persistent" : {
        "cluster.routing.allocation.enable" : "all"
    }
}

结果如下：

{
  "error" : {
    "root_cause" : [
      {
        "type" : "remote_transport_exception",
        "reason" : "[inoreader-es4][92.247.179.253:9300][cluster:admin/settings/update]"
      }
    ],
    "type" : "illegal_argument_exception",
    "reason" : "unknown setting [indices.store.throttle.max_bytes_per_sec] did you mean [indices.recovery.max_bytes_per_sec]?"
  },
  "status" : 400
}

无论我尝试更改什么设置，我总是会收到此错误。是的，我确实在5.x中将indices.store.throttle.max_bytes_per_sec设置为持久设置，我现在必须将其设置为新名称，但我怎么能删除它呢？它不在elasticsearch.yml。

Answer 1

您需要取消该值。如果您仍在使用旧版本，则可以使用以下命令（在5.0中取消设置null）：

PUT _cluster/settings
{
  "persistent": {
    "indices.store.throttle.max_bytes_per_sec": null
  }
}

然而，这将失败，并且＃34;持久性设置[indices.store.throttle.max_bytes_per_sec]，无法识别＆＃34;如果您已升级，则在群集中。

目前（Elasticsearch版本6.1.1），已删除的设置将归档在archived.indices.store.throttle.max_bytes_per_sec下。您可以使用以下命令删除此设置和任何其他存档设置：

PUT _cluster/settings
{
  "persistent": {
    "archived.*": null
  }
}

但是，有a bug that only lets you unset archived settings before you change any other settings。

如果您已经进行了其他设置并受此错误的影响，唯一的解决方案是再次降级到5.6，取消设置配置（此答案顶部的命令），然后再次进行升级。它可能足以在一个节点上执行此操作（停止所有其他节点），只要它是主节点并且所有其他节点加入该节点并接受其更正的群集状态即可。无论如何，请务必拍摄快照。

对于将来的版本，archived.*行为可能会按照in the ticket的规定进行更改（尽管它现在正处于规划阶段）：

[...]我们不应归档未知和损坏的群集设置。相反，我们应该无法恢复群集状态。解决方案升级案例中的用户将回滚到以前的版本，解决下一个专业中未知或破坏的设置版本，然后继续升级。

手动编辑甚至删除磁盘上的群集状态听起来非常危险：群集状态包含大量信息（使用GET /_cluster/state检查自己），如模板，索引，路由表，......即使您拥有数据节点的数据，但是你丢失了集群状态，你将无法访问你的数据（＆＃34; map＆＃34;如何从分片中形成索引）。如果我没记错的话，在最新的ES版本中，数据节点会缓存群集状态并尝试从中恢复，但这是最后的手段，我不想依赖它。此外，我不确定这是否也可能不会带回你糟糕的环境。

PS：我强烈推荐免费upgrade assistant从5.6到6.x。

Elasticsearch - 如何在升级后删除卡住的持久性设置

1 个答案: