es的索引生命周期管理
一、常见概念及命令
1.1、概念
ILM定义了四个生命周期阶段：
Hot：正在积极地更新和查询索引。
Warm：不再更新索引，但仍在查询。
cold：不再更新索引，很少查询。信息仍然需要可搜索，但是如果这些查询速度较慢也可以。
Delete：不再需要该索引，可以安全地将其删除
rollover: rollover可以基于大小，文档数或使用期限
创建新的索引去保存数据
1.2、DSL命令
索引的生命周期常用命令：GET _ilm/status # 查看状态
POST _ilm/start # 启动
POST _ilm/stop # 停止索引的策略的常用命令：GET _ilm/policy #查看策略 或者 GET _ilm/policy/<policy_id> #查看指定策略id
DELETE _ilm/policy/<policy_id> # 删除指定策略POST <index>/_ilm/remove从index中移除策略
查看索引的生命周期状态：(
重点)
GET <index-name>/_ilm/explain例如：
GET /my_cas_history_logs/_ilm/explain
查看索引的策略应用情况：(重点)
GET _iml/policy/<policy-name>例如：GET _iml/policy/cas_login_policy
查看模板详情：（重点）
GET _template/<template-name>例如：GET /cas_log/_ilm/explain
在实验中可以修改设置，来缩短ILM检测时间间隔。ILM定期运行（indices.lifecycle.poll_interval），默认是10分钟，检查索引是否符合策略标准，并执行所需的任何步骤。
实际开发中不修改此项。
PUT /_cluster/settings
{
"transient": {
"indices.lifecycle.poll_interval": "1m"
}
}
二、生命周期的管理步骤
第一步：创建生周期 policy。
#为索引创建ilm规则(可以根据不同场景设置不同规则)#设置ilm规则,主分片没50GB或者超过30天或数据条数超过500000000切换一次索引(三者可任意保留无需都留下)，超过360天的索引自动删除#max_size:主分片数*50GB#common_policy 是自己取的策略名字，自己根据自己合适的取，这里只设置了hot和delete。根据自己业务需求决定是否设置warm、cold
PUT _ilm/policy/common_policy {
"policy":{
"phases":{
"hot":{
"min_age":"0ms","actions":{
"rollover":{ #滚动创建新索引的触发条件"max_size":"50gb",# 当容量超过50gb(根据自己的需求设置)"max_docs": 500000000,# 当总条数超过500000000(根据自己的需求设置)"max_age":"30d"# 当时间超过30d(根据自己的需求设置)
},"set_priority":{ #优先级，任一满足条件就执行"priority":100
}
}
},"delete":{#删除策略"min_age":"360d",#超过360天的数据就自动删除"actions":{
"delete":{}
}
}
}
}
}
第二步：创建索引模板，模板中关联 policy 和别名。
PUT _template/<index_name>
{
"order":0,"index_patterns":["<index_name>-*"],#index_name是自己的索引别名"settings":{
"index.lifecycle.name":"common_policy",#这里的common_policy就是上面设置的策略"index.lifecycle.rollover_alias":"<index_name>","index.number_of_replicas":"1",# 设置副本1"index.number_of_shards":"6",# 设置主分片数为6(建议分片数设置为数据节点的倍数个)"index.refresh_interval":"30s","index.translog.durability":"async","index.translog.sync_interval":"10s","index.unassigned.node_left.delayed_timeout":"30m"
},"mappings":{},"aliases":{}
}
例如：（我测试的例子）
PUT _template/my_cas_history_logs
{"order":0,"index_patterns":["my_cas_history_logs-*"],"settings":{"index.lifecycle.name":"common_policy","index.lifecycle.rollover_alias":"my_cas_history_logs","index.number_of_replicas":"1","index.number_of_shards":"6","index.refresh_interval":"30s","index.translog.durability":"async","index.translog.sync_interval":"10s","index.unassigned.node_left.delayed_timeout":"30m"},"mappings":{},"aliases":{}}
第三步：创建符合模板的起始索引，设置别名(即我们统一对外提供服务的索引名)。
#创建<index_name>索引,支持rollover的时候index名称附加年月日时分秒(将url及json里面的<index_name>替换为对应索引名)
PUT /%3C<index_name>-%7Bnow%2Fm%7Byyyy.MM.dd.HH.mm%7CAsia%2FShanghai%7D%7D-000001%3E
{
"aliases":{
"<index_name>":{
"is_write_index":true
}
}
}
例如：（我测试的例子）
PUT /%3Cmy_cas_history_logs-%7Bnow%2Fm%7Byyyy.MM.dd.HH.mm%7CAsia%2FShanghai%7D%7D-000001%3E
{"aliases":{"my_cas_history_logs":{"is_write_index":true
}}}
按以上设置完成后就可以查看
GET /my_cas_history_logs/_search
以上就完成了一个简单的es 的生命周期的管理
三、生命周期的管理的测试
在实际开发中,测试老师问如何测试es的生命周期生效了呢？总不能等一年才看到删除效果吧？
cas_policy_logs 是我的索引名字(别名),以此为例：
#查看索引的生命周期,可以看到当前的索引的策略应用情况GET /cas_policy_logs/_ilm/explain
删除策略
PUT _ilm/policy/cas-history-policy
{"policy": {"phases": {"delete": {"actions": {"delete" : {}}}}}}
注意：我用这个方法没有删掉，改用kibana图形化工具的操作删除的（要先删除所有索引才能删除策略）
设置es的ILM检测时间间隔,测试完记得改回去，默认10分钟。这仅仅是为了增加es监测频率。
PUT /_cluster/settings
{"transient": {"indices.lifecycle.poll_interval": "30s"}}
重点:这里delete指定的是当老的索引index超过rollver的时间，后的delete指定时间才被删掉。而不是索引的创建时间。
如果是索引按指定时间rollver，那删除时间就是rollver中的max_age+delete指定时间，才被删除。而索引按容量或者文档数量（max_size、max_docs）那么就小于
max_age+delete指定时间 就被删除。
官网对于删除的定义是：Delete the index 30d days after rollover.(30d是这里设置的删除时间)
总结来说就是:当这个索引不再写入数据(即创建新索引)开始算在delete设定时间后删除
查看生命周期的重要命令:
查看索引的生命周期状态：(
重点)
GET <index-name>/_ilm/explain例如：
GET /my_cas_history_logs/_ilm/explain
查看索引的策略应用情况：(重点)
GET _iml/policy/<policy-name>例如：GET _iml/policy/cas_login_policy
查看模板详情：（重点）
GET _template/<template-name>例如：GET /cas_log/_ilm/explain
删完之后重新建策略即可，设置调试，这样就完成了测试。
版权归原作者 神雕大侠mu 所有， 如有侵权，请联系我们删除。