在我之前文章 “Elasticsearch:如何调试集群状态 - 定位错误信息” 中,我有详细介绍如何调试集群状态。在今天的文章中,我将详细介绍如何故障排除和修复索引状态。
Elasticsearch 是一个伟大而强大的系统,特别是创建一个可扩展性极强的分布式数据存储,并自动跟踪、管理和路由索引中的所有数据。
但有时事情会出错,索引会遇到或大或小的麻烦。 这通常最终会导致它们具有红色或黄色的状态。 集群将紧随其后,因为它的状态是所有索引中最差的,例如 如果一个索引为红色,则集群为红色。
如果你的集群和一些索引是红色或黄色的,你会怎么做? 那么,你需要找出原因。 你是怎样做的?
首先,说一下颜色的含义,因为它们看起来很复杂,但最终很简单:
1) 第一步是确定你知道的主要问题,例如死节点、磁盘空间问题等可能产生问题的问题。 这有助于告知我们寻找什么以及我们以后如何修复它。
有时你只需要耐心等待,因为系统通常会通过移动数据来修复自身,例如将副本提升为主要副本,然后重新创建新副本,但这需要时间,从几分钟到更长,具体取决于分片数量和大小, 集群负载、磁盘速度等。
但你不能指望这一点,除非很明显系统正在自我修复。 有时事情真的坏了,这就是为什么了解历史是件好事,因为重启节点肯定会使一些索引变黄,但几分钟后又变绿。
2) 第二步是确定哪些索引有问题,有多少索引有问题。 _cat API 可以通过状态告诉我们:
GET /_cat/indices?v&health=red
GET /_cat/indices?v&health=yellow
从中我们可以了解我们有多少问题,这可能与上面讨论的任何最近事件有关。 我们还需要这个列表,以便我们可以更深入地挖掘每个索引。
3) 第三步是查看哪些分片有问题以及原因。 这与索引列表有关,但索引列表只会告诉你哪些索引有问题,现在我们需要每个分片的问题列表。
我们为此使用 _cat 接口,理想情况下使用排序和一些额外的列,例如这将列出按状态排序的索引,包括未分配的基本原因 - 查找 UNASSIGNED 状态:
GET /_cat/shards?v&h=n,index,shard,prirep,state,sto,sc,unassigned.reason,unassigned.details&s=sto,index
这可能足以了解正在发生的事情,其中有未分配的详细信息列,我们可以从中解决问题。 但有时我们需要更多细节,特别是当我们有节点路由或其他更复杂的问题时。
我们可以询问集群为什么分片没有分配 …
为此,我们可以要求集群解释给定分片的当前分配情况和逻辑。 这有点混乱,因为我们需要上面列表中的两个分片编号(从 0 开始),并且要知道我们是否要查看主分片或副本,同样来自上面的列表。
API 调用是这样的,这里需要设置索引名,分片号,primary true/false:
GET _cluster/allocation/explain
{
"index": ".ds-heartbeat-8.6.1-2023.03.27-000001",
"shard": 0,
"primary": true
}
这将使您更详细地了解情况,接下来要做什么取决于您在那里找到的原因。
一些常见问题包括:
第四步是修复问题。 修复分为几类:
我们将在出现状态和解决方案时添加更多详细信息,但这是一个复杂的问题,并且与所有系统一样,修复会根据问题的确切细节和历史记录而有所不同。