ElasticSearch生命周期管理-索引策略配置与操作

  • 2020 年 8 月 26 日
  • 筆記

概述

本文是在本人学习研究ElasticSearch的生命周期管理策略时，发现官方未提供中文文档，有的也是零零散散，此文主要是翻译官方文档Policy phases and actions模块。

注：基于6.7版本

索引生命周期中有四个阶段，按执行顺序排列。

名称 描述
hot 该索引正在积极写入
warm 索引通常不会被写入，但仍然会被查询
cold 索引不再更新，很少查询。信息仍然需要搜索，但如果这些查询速度较慢也没关系。
delete 不再需要索引，可以安全删除

​ 这些阶段中的每一个都称为阶段。策略不需要为索引配置每个阶段。例如，一个策略可以仅定义热阶段和删除阶段，而另一个策略可以定义所有四个阶段。

时间（Timing）

​ 索引进入某阶段是基于该阶段设置的min_age参数。当索引的“年龄”大于该阶段设置的的min_age之前，索引才会进入阶段min_age。使用持续时间格式配置参数（请参阅时间单位）。

min_age如果未指定，则每个阶段的默认值为零秒0s。

示例

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "min_age": "1d",
        "actions": {
          "allocate": {
            "number_of_replicas": 1
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

以上示例策略，在一天之后将索引移动到暖阶段。在此之前，该索引处于等待状态。进入暖阶段后，它将等待30天后才能进入删除阶段并删除索引。

min_age通常是从创建索引的时间开始经过的时间。如果索引被翻转，那么min_age是从索引翻转开始经过的时间。这里的目的是执行以下阶段和操作，这些阶段和操作相对于数据最后写入滚动索引的时间。

在索引生命周期管理将检查min_age 并转换到下一阶段之前，必须完成上一阶段的操作。

Phase Execution（阶段执行）

​ 正在执行的索引策略的当前阶段定义存储在索引的元数据中。阶段及其动作被编译成一系列按顺序执行的离散步骤。由于某些ILM操作更复杂并且涉及针对索引的多个操作，因此这些操作中的每一个都在称为“步骤”的单元中单独完成。该 解释生命周期API公开这些信息给我们，看看哪些步骤我们的索引或者接下来执行或正在执行。

Actions（操作）

下列清单展示每个阶段可配置的动作。

在每个阶段中执行已配置操作的顺序由ILM自动确定，并且无法通过更改策略定义进行更改。

热阶段（Hot）

温阶段（Warm）

冷阶段（Cold）

删除阶段（Delete）

Allocate

阶段允许：warm，cold

​ Allocate操作允许您指定允许哪些节点托管索引的分片并设置副本数。在这些场景背后，它正在修改分片过滤和/或副本计数的索引设置。更新副本数时，配置分配规则是可选的。配置分配规则时，设置副本数是可选的。虽然此操作可以视为两个单独的索引设置更新，但两者都可以一次配置。

配置选项

Name Required Default Description
number_of_replicas no – The number of replicas to assign to the index
include no – assigns an index to nodes having at least one of the attributes
exclude no – assigns an index to nodes having none of the attributes
require no – assigns an index to nodes having all of the attributes

如果number_of_replicas未配置，那么include， exclude和require中的至少一个是必需的。没有配置的空Allocate Action是无效的。

示例：更改副本

在此示例中，索引的副本数已更改为2，而分配规则未更改。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "allocate" : {
            "number_of_replicas" : 2
          }
        }
      }
    }
  }
}

Delete

阶段允许：delete

删除操作就是这样，它会删除索引。

此操作没有与之关联的任何选项。

示例
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "delete": {
        "actions": {
          "delete" : { }
        }
      }
    }
  }
}

Force-Merge

阶段允许：delete

执行此操作时，索引将变成只读。请参考

强制合并操作Force Merge会将索引合并为最多特定数量的segments。

配置选项

名称 是否必须 默认 描述
max_num_segments 是 – 要合并的段数。要完全合并索引，请将其设置为1
示例
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "forcemerge" : {
            "max_num_segments": 1
          }
        }
      }
    }
  }
}

Freeze

阶段允许：cold

该动作将通过调用Freeze Index API的api来freeze索引

冻结索引将关闭索引并在同一API调用中重新打开它。
这导致初选不能在短时间内分配
导致群集变红，直到再次分配原色。
将来可能会删除此限制。

示例
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "cold": {
        "actions": {
          "freeze" : { }
        }
      }
    }
  }
}

Read-Only

阶段允许：warm

此操作将索引设置为只读（请参阅：index.blocks.write）

此操作没有与之关联的任何选项。

示例
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "readonly" : { }
        }
      }
    }
  }
}

Rollover

阶段允许：hot

  • 索引格式必须匹配模式^。* – \ d + $，例如（logs-000001）。
  • 托管的索引必须设置index.lifecycle.rollover_alias为别名进行Rollover，且索引还必须是以别名的写入。

例如，如果要管理的索引具有别名my_data。托管的索引“my_index”必须是别名的写入索引。有关更多信息，请阅读 写入索引别名行为。

PUT my_index
{
  "settings": {
    "index.lifecycle.name": "my_policy",
    "index.lifecycle.rollover_alias": "my_data"
  },
  "aliases": {
    "my_data": {
      "is_write_index": true
    }
  }
}

当现有索引满足其中一个滚动更新条件时，“Rollover Action”会将别名转到新索引。

配置选项

Name Required Default Description
max_size no – 最大主分片索引存储大小。请参见字节单位 以进行格式化
max_docs no – 滚动前索引要包含的最大文档数。
max_age no – 索引创建过去的最长时间。请参阅 时间单位 以进行格式

中的至少一个max_size，max_docs，max_age或需要这三者的任意组合来进行指定。

示例：索引过大时滚动

此示例在至少100千兆字节时滚动索引。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_size": "100GB"
          }
        }
      }
    }
  }
}
示例：索引包含太多文档时滚动

此示例在包含至少100000000个文档时将索引翻转。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_docs": 100000000
          }
        }
      }
    }
  }
}
示例：索引太旧时滚动

此示例至少在7天前创建索引。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_age": "7d"
          }
        }
      }
    }
  }
}
示例：索引太旧或太大时的翻转

此示例在至少7天前创建索引或至少100千兆字节时将索引卷起。在这种情况下，当满足任何条件时，索引将被翻转。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover" : {
            "max_age": "7d",
            "max_size": "100GB"
          }
        }
      }
    }
  }
}

Set-Priority

阶段允许: hot, warm, cold.

一旦策略进入hot，warm或cold阶段，此操作就会为索引设置索引优先级。具有较高优先级的索引将在节点重启后具有较低优先级的索引之前恢复。通常，hot阶段的指数应具有最高值，而cold阶段的指数应具有最低值。例如：hot阶段设置为100，warm阶段设置为50，cold阶段设置为0。未设置此值的指标的默认优先级为1。

配置选项

名称 需要 默认 描述
priority 是 – 索引的优先级。必须为0或更大。该值也可以设置为null以删除优先级。
示例
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "set_priority" : {
            "priority": 50
          }
        }
      }
    }
  }
}

Shrink

运行此操作时，索引将变为只读（请参阅：index.blocks.write）

此操作会将现有索引缩减为具有较少主分片的新索引。它调用Shrink API来缩小索引。由于将索引的所有主分片分配给一个节点是先决条件，因此该操作将首先将主分片分配给有效节点。收缩后，它会将指向原始索引的别名交换到新的收缩指数中。新索引还将有一个新名称：“shrink- ”。因此，如果原始索引称为“logs”，则新索引将命名为“shrink-logs”。

配置选项

名称 需要 默认 描述
number_of_shards 是 – 要缩小的分片数。必须是源索引中分片数量的一个因子。
示例
PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "warm": {
        "actions": {
          "shrink" : {
            "number_of_shards": 1
          }
        }
      }
    }
  }
}

Unfollow

此操作可以显式使用，如下所示，但此操作也在Rollover操作和Shrink操作之前运行，如这些操作的文档中所述。

取消关注操作没有任何选项，如果遇到非关注者索引，则取消关注操作会保持索引不变，并允许下一个操作对此索引进行操作。

PUT _ilm/policy/my_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "unfollow" : {}
        }
      }
    }
  }
}

完整策略（Full Policy）

​ 通过所有这些操作，我们可以为我们的索引支持复杂的管理策略。此策略将定义一个将在热阶段开始的索引，每50 GB或7天滚动一次。30天后，它进入温暖阶段并将副本增加到2，强制合并和收缩。60天后进入冷期并分配到“冷”节点，90天后删除索引。

PUT _ilm/policy/full_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "7d",
            "max_size": "50G"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "forcemerge": {
            "max_num_segments": 1
          },
          "shrink": {
            "number_of_shards": 1
          },
          "allocate": {
            "number_of_replicas": 2
          }
        }
      },
      "cold": {
        "min_age": "60d",
        "actions": {
          "allocate": {
            "require": {
              "type": "cold"
            }
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

参考

结语

欢迎关注微信公众号『码仔zonE』，专注于分享Java、云计算相关内容，包括SpringBoot、SpringCloud、微服务、Docker、Kubernetes、Python等领域相关技术干货，期待与您相遇！

VirMach 便宜 VPS

QNews

QNews