为什么我的 ISM 策略中的翻转索引操作在 Amazon OpenSearch Service 中总是失败?
上次更新日期: 2021 年 8 月 5 日
我想要使用索引状态管理(ISM)功能将我在 Amazon OpenSearch Service 集群上的索引翻转。但我的索引翻转失败,我还收到了一个错误。为什么会出现这种情况,我该怎样解决呢?
简短描述
如果您收到 "Failed to rollover index"(未能翻转索引)错误,则表明您的翻转操作可能由于以下原因之一而失败:
- 翻转目标不存在。
- 缺少翻转别名。
- 索引名称与索引模式不匹配。
- 翻转别名指向了索引模板中的一个重复别名。
- 您在集群中有着最大的资源利用率。
要解决此问题,请使用 explain(解释) API 确定错误的原因。然后,检查您的 ISM 策略。有关如何在 ISM 策略中设置翻转操作的更多信息,请参阅如何使用索引状态管理 (ISM) 功能管理 Amazon OpenSearch Service 中的存储空间不足问题?
解决方法
使用 explain API
要确定 Failed to rollover index(未能翻转索引)错误的根本原因,请使用 explain API:
GET _opendistro/_ism/explain/logs-000001?pretty
下面是 explain API 的一个示例输出:
{
"logs-000001" : {
"index.opendistro.index_state_management.policy_id" : "rollover-workflow",
"index" : "logs-000001",
"index_uuid" : "JUWl2CSES2mWYXqpJJ8qlA",
"policy_id" : "rollover-workflow",
"policy_seq_no" : 2,
"policy_primary_term" : 1,
"rolled_over" : false,
"state" : {
"name" : "open",
"start_time" : 1614738037066
},
"action" : {
"name" : "rollover",
"start_time" : 1614739372091,
"index" : 0,
"failed" : true,
"consumed_retries" : 0,
"last_retry_time" : 0
},
"retry_info" : {
"failed" : false,
"consumed_retries" : 0
},
"info" : {
"cause" : "rollover target [rolling-indices] does not exist",
"message" : "Failed to rollover index [index=logs-000001]"
}
}
}
此示例输出表明,目标翻转别名 (rolling-indices) 不存在,因此未能翻转索引。
翻转目标不存在
如果 explain API 返回的原因是 "rollover target [rolling-indices] does not exist",请检查是否使用翻转别名引导了索引:
GET _cat/aliases
此输出列出了集群中的所有当前别名以及它们的关联索引。如果 ISM 表明您的翻转目标不存在,则意味着缺少转换别名和失败的索引关联。
要解决索引关联失败问题,请为索引附加翻转别名:
POST /_aliases
{
"actions" : [
{ "add" : { "index" : "logs-000001", "alias" : "my-data" } }
]
}
附加翻转别名之后,在 OpenSearch Service 中对托管的索引重试翻转操作:
POST _opendistro/_ism/retry/logs-000001
有关更多信息,请参阅 Open Distro for Elasticsearch 网站上的 Retry failed index(重试失败的索引)。
当重试失败的索引时,您可能会收到 Attempting to retry(正在尝试重试)状态消息。如果 OpenSearch Service 正在尝试重试,请等待下一个 ISM 周期运行。ISM 周期每 30 到 48 分钟运行一次。如果翻转操作成功,您将收到以下消息:"Successfully rolled over index"(已成功翻转索引)。
缺少翻转别名
如果 explain API 输出确定的翻转失败原因是缺少翻转别名,请检查失败的索引的设置:
GET <failed-index-name>/_settings
如果您发现缺少 index.opendistro.index_state_management.rollover_alias 设置,请手动将此设置添加到索引中:
PUT /<failed-index-name>/_settings
{
"index.opendistro.index_state_management.rollover_alias":"<rollover-alias>"
}
使用 retry failed index API,对失败的索引重试翻转操作。当重试翻转操作时,请更新您的策略模板:
PUT _template/<template-name>
确保使用现有策略模板中的那些设置,以便将您的翻转别名应用于新创建的索引。例如:
PUT _template/<existing-template>
{
"index_patterns": ["<index-pattern*>"],
"settings": {
"index.opendistro.index_state_management.policy_id": "<policy_id>",
"index.opendistro.index_state_management.rollover_alias":"<rollover-alias>"
}
}
索引名称与索引模式不匹配
如果 ISM 策略表明由于索引名称与索引模式不匹配而导致翻转操作失败,请检查失败的索引的名称。为了成功进行翻转,索引名称必须与如下正则表达式模式匹配:
`^.*-\\d+$`
此正则表达式模式要求索引名称必须包含文本,然后是连字符 (-) 以及一个或多个数字。如果索引名称不遵循此模式,而且您的第一个索引中写入了数据,请考虑重新索引数据。当您重新索引数据时,请为新索引使用正确的名称。例如:
POST _reindex
{
"source": {
"index": "<failed-index>"
},
"dest": {
"index": "my-new-index-000001"
}
}
当 reindex data API 正在运行时,请从失败的索引中分离翻转别名。随后,将翻转别名添加到新索引中,以使数据源能够继续将传入的数据写入到新索引中。
例如:
POST /_aliases
{
"actions" : [
{ "remove" : { "index" : "<failed-index>", "alias" : "<rollover-alias>" } },
{ "add" : { "index" : "my-new-index-000001", "alias" : "<rollover-alias>" } }
]
}
使用如下 API 调用,手动将 ISM 策略附加到新索引:
POST _opendistro/_ism/add/my-new-index-* { "policy_id": "<policy_id>" }
更新现有的模板,以反映新的索引模式名称:
PUT _template/<existing temaplate>
注意:您的 ISM 策略和翻转别名必须反映使用相同的索引模式创建的连续索引。
翻转别名指向了索引模板中的一个重复别名
如果 explain API 表明由于翻转别名指向了一个重复的别名而导致索引翻转失败,请检查您的索引模板设置:
GET _template/<template-name>
检查您的模板是否包含额外的 aliases(别名)部分(另一个别名指向了同一个索引):
"index_patterns": ["my-index*"],
"settings": {
"index.opendistro.index_state_management.policy_id": "rollover-policy",
"index.opendistro.index_state_management.rollover_alias": "rollover-alias"
},
"aliases": {
"another_alias": {
"is_write_index": true
}
}
另一个别名的存在确认了您的翻转操作失败的原因,因为多个别名会导致翻转失败。要解决这一失败,请更新模板设置,但不要指定任何别名:
PUT _template/<template-name>
随后,对失败的索引执行 retry API:
POST _opendistro/_ism/retry/my-index-000001
重要提示:如果别名指向了多个索引,请确保只为一个索引启用了写访问权限。rollover API 会自动为翻转别名指向的索引启用写访问权限。这表示,在 ISM 中执行翻转操作时,您无需为 "is_write_index" 设置指定任何别名。
集群中的资源利用率最高
集群上的最大资源利用率可能是由断路器异常或存储空间不足引起的。
断路器异常
如果 explain(解释)API 返回断路器异常,那么在调用 rollover(翻转)API 时,您的集群可能会遇到很高的 JVM 内存压力。有关排查 JVM 内存压力问题的更多信息,请参阅如何排查 Amazon OpenSearch Service 集群上的高 JVM 内存压力问题?
在 JVM 内存压力降至 75% 以下之后,您可以通过以下 API 调用对失败索引进行重试活动:
POST _opendistro/_ism/retry/<failed-index-name>
注意:您可以使用索引模式 (*) 对多个失败索引进行重试活动。
如果集群上不频繁出现 JVM 峰值,那么还可以使用以下重试数据块更新 ISM 策略,以进行翻转操作:
"actions": {
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "10m"
}
}
在 ISM 策略中,每个操作都具有基于 count 参数的自动重试。如果您之前的操作失败,请检查“delay”参数来查看 ISM 重试该操作需要等待多久。
存储空间不足
如果您的集群存储空间不足,OpenSearch Service 会在集群上触发写入数据块,使所有写入操作都返回 ClusterBlockException。您的 ClusterIndexWritesBlocked 指标值将显示值“1”,这表示集群正在阻止请求。因此,任何创建新索引的尝试都将失败。explain(解释)API 调用还将返回 403 IndexCreateBlockException,这表示集群存储空间不足。要排查集群数据块异常问题,请参阅如何解决 Amazon OpenSearch Service 中的 403 "index_create_block_exception" 错误?
在 ClusterIndexWritesBlocked 指标返回到 "0" 后,请对失败的索引重试 ISM 操作。如果您的 JVM 内存压力超过 92%,且持续时间超过 30 分钟,则可能会触发写入数据块。如果遇到写入数据块,则必须对 JVM 内存压力问题进行排查。有关如何排查 JVM 内存压力的更多信息,请参阅如何排查 Amazon OpenSearch Service 集群的 JVM 内存压力较高问题?
Amazon OpenSearch Service 是 Amazon Elasticsearch Service 的后继者。