收缩
编辑收缩
编辑允许的阶段：hot，warm。
阻止源索引上的写入，并将其收缩为具有较少主分片的新索引。结果索引的名称为shrink-<random-uuid>-<original-index-name>。此操作对应于收缩 API。
在shrink操作之后，指向源索引的任何别名都将指向新的收缩索引。如果 ILM 对数据流的后备索引执行shrink操作，则收缩索引将替换流中的源索引。您不能对写入索引执行shrink操作。
要在hot阶段使用shrink操作，则rollover操作必须存在。如果未配置翻转操作，则 ILM 将拒绝该策略。
收缩操作将取消设置索引的index.routing.allocation.total_shards_per_node设置，这意味着将没有限制。这是为了确保可以将索引的所有分片复制到单个节点。即使在步骤完成后，此设置更改仍将保留在索引上。
如果在追随者索引上使用收缩操作，则策略执行将等待领导者索引翻转（或以其他方式标记为完成），然后使用取消关注操作将追随者索引转换为常规索引，然后再执行收缩操作。
收缩选项
编辑-
number_of_shards - （可选，整数）要收缩到的分片数。必须是源索引中分片数的因子。此参数与
max_primary_shard_size冲突，只能设置其中一个。 -
max_primary_shard_size - （可选，字节单位）目标索引的最大主分片大小。用于查找目标索引的最佳分片数。设置此参数后，目标索引中每个分片的存储空间将不大于该参数。目标索引的分片计数仍将是源索引分片计数的因子，但是如果该参数小于源索引中的单个分片大小，则目标索引的分片计数将等于源索引的分片计数。例如，当此参数设置为50gb时，如果源索引有60个主分片，总计100gb，则目标索引将有2个主分片，每个分片的大小为50gb；如果源索引有60个主分片，总计1000gb，则目标索引将有20个主分片；如果源索引有60个主分片，总计4000gb，则目标索引仍将有60个主分片。此参数与
settings中的number_of_shards冲突，只能设置其中一个。 -
allow_write_after_shrink - （可选，布尔值）如果为true，则通过删除写入阻止来使收缩后的索引可写。默认为false。
示例
编辑显式设置新的收缩索引的分片数
编辑resp = client.ilm.put_lifecycle(
name="my_policy",
policy={
"phases": {
"warm": {
"actions": {
"shrink": {
"number_of_shards": 1
}
}
}
}
},
)
print(resp)
response = client.ilm.put_lifecycle(
policy: 'my_policy',
body: {
policy: {
phases: {
warm: {
actions: {
shrink: {
number_of_shards: 1
}
}
}
}
}
}
)
puts response
const response = await client.ilm.putLifecycle({
name: "my_policy",
policy: {
phases: {
warm: {
actions: {
shrink: {
number_of_shards: 1,
},
},
},
},
},
});
console.log(response);
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"shrink" : {
"number_of_shards": 1
}
}
}
}
}
}
计算收缩索引的最佳主分片数
编辑以下策略使用max_primary_shard_size参数，根据源索引的存储大小自动计算新的收缩索引的主分片计数。
resp = client.ilm.put_lifecycle(
name="my_policy",
policy={
"phases": {
"warm": {
"actions": {
"shrink": {
"max_primary_shard_size": "50gb"
}
}
}
}
},
)
print(resp)
response = client.ilm.put_lifecycle(
policy: 'my_policy',
body: {
policy: {
phases: {
warm: {
actions: {
shrink: {
max_primary_shard_size: '50gb'
}
}
}
}
}
}
)
puts response
const response = await client.ilm.putLifecycle({
name: "my_policy",
policy: {
phases: {
warm: {
actions: {
shrink: {
max_primary_shard_size: "50gb",
},
},
},
},
},
});
console.log(response);
PUT _ilm/policy/my_policy
{
"policy": {
"phases": {
"warm": {
"actions": {
"shrink" : {
"max_primary_shard_size": "50gb"
}
}
}
}
}
}
收缩的分片分配
编辑在shrink操作期间，ILM 将源索引的主分片分配到一个节点。收缩索引后，ILM 会根据您的分配规则将收缩索引的分片重新分配到相应的节点。
这些分配步骤可能会因多种原因而失败，包括
- 在
shrink操作期间删除节点。 - 没有足够的磁盘空间来托管源索引的分片。
- 由于分配规则冲突，Elasticsearch 无法重新分配收缩索引。
当其中一个分配步骤失败时，ILM 将等待index.lifecycle.step.wait_time_threshold中设置的时间段，该时间段默认为 12 小时。此阈值期允许集群解决导致分配失败的任何问题。
如果阈值期已过，而 ILM 尚未收缩索引，则 ILM 会尝试将源索引的主分片分配到另一个节点。如果 ILM 收缩了索引，但无法在阈值期间重新分配收缩索引的分片，则 ILM 会删除收缩索引并重新尝试整个shrink操作。