故障现象：
elastisearch 集群索引状态为red，数据上T大小，单个索引好几百个G，集群重启耗时过长，无法恢复正常状态
报错类似：
Caused by: org.elasticsearch.action.UnavailableShardsException: [.monitoring-kibana-7-2023.01.17][0] primary shard is not active Timeout: [1m], request: [BulkShardRequest [[.monitoring-kibana-7-2023.01.17][0]] containing [2] requests]
... 11 more
[2023-01-17T06:19:46,326][WARN ][o.e.x.m.e.l.LocalExporter] [datanodeprod5.synnex.org] unexpected error while indexing monitoring documentcat recovery API | Elasticsearch Guide [8.7] | Elastic
基于如下五种情况，Elasticsearch 自动执行恢复（recovery）：
-
节点启动（这种类型的恢复称为本地存储恢复）；
-
将主分片复制到副本分片；
-
将分片迁移到同一集群中的不同节点；
-
恢复快照（又称作：快照还原 restore 操作）；
-
Clone, shrink, or split 操作。
1. 集群尚可用的情况下，使用recovery_api
GET _cat/recovery?v=true&h=i,s,t,ty,st,shost,thost,f,fp,b,bp&s=index:desc用途：返回有关分片恢复的信息，包括正在进行的和已完成的。
注意：分片恢复完成后，恢复的分片可用于搜索和索引。
2. 确定每个节点将被恢复的并发分片数
如下设置若生效，本质上是：
node_concurrent_incoming_recoveries和 node_concurrent_outgoing_recoveries同时生效。
incoming_recoverie可以简单理解为副本分片的恢复，outgoing_recoveries可以简单理解为主分片的恢复。
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.node_concurrent_recoveries": 3
}
}默认值是2，理论上调大会增大并发。
Cluster-level shard allocation and routing settings | Elasticsearch Guide [8.7] | Elastic
3. 延时分片分配策略
当节点出于任何原因（人为原因或系统异常）离开集群时，主节点会做出以下反应（如下称为步骤 X 是方便后续的解读）：
步骤1：将副本分片提升为主分片以替换节点上的任何主分片。
步骤2：分配副本分片以替换丢失的副本（在有足够的节点的前提下）。
步骤3：在其余节点之间均匀地重新平衡分片。
以上操作的好处是：避免集群数据丢失，确保集群高可用。
但可能带来的副作用也非常明显：其一，会给集群带来额外的负载（分片分配非常耗费系统资源）；其二，若离开集群的节点很快返回，上述机制的必要性就有待商榷。
此时，延迟分片分配就显得非常必要，设置如下：
PUT _all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "6m"
}
}延时分片分配策略的本质
当节点离开集群并确认几分钟（自己设定）可以快速上线的情况下，离开的过程中只触发步骤1的将离开节点上的对应的副本分片提升为主分片。此时集群至少不是red 状态，而是yellow状态。步骤2、步骤3不会发生，此时集群是可用的，待设定的几分钟内下线集群确保重新上线后，分片再重新转为副本分片，此时集群恢复绿色状态。
这个过程有效避免了步骤2、步骤3的分片分配，整体上以最短的时间确保了集群的高可用性。
Delaying allocation when a node leaves | Elasticsearch Guide [8.7] | Elastic
4. 限制恢复速度以避免集群过载
Elasticsearch 限制分配给恢复的速度以避免集群过载。
可以更新此设置以使恢复更快或更慢，具体取决于业务要求。在资源允许的情况下，想快就调大；反之，则相反。
但一味的追求快速恢复，将如下设置过高，正在进行的恢复操作会消耗过多的带宽和其他资源，这可能会破坏集群的稳定性。
PUT _cluster/settings
{
"transient": {
"indices.recovery.max_bytes_per_sec": "100mb"
}
}
注意事项：
这是集群层面的动态设置，一旦设置后，对集群中每个节点都生效。
如果仅想限制有限的某个节点，可以通过更新elasticsearch.yml 配置文件的静态配置来实现。
Index recovery settings | Elasticsearch Guide [8.7] | Elastic
以上是集群还可以访问的情况下
集群无法响应的情况下如何恢复？？？
提速的核心：删除历史“包袱”（将来不再需要的大索引），以间接使得集群恢复加速。
免责说明：
-
如下的验证，仅在单节点集群验证 ok，多节点原理一致。
-
涉及文件的操作，是无法之法，万不得已，不要直接操作文件。
1. 找到待删除大索引的 uuid
部分命令可执行，可以 cat/index
GET _cat/indices?v&s=docs.count:desc
找到对应的uuid
这一步目的：找到需要删除、业务层面彻底放弃的索引直接物理删除文件，为重启集群会减少恢复压力。
2. 在Elasticsearch 存储路径下找到对应存储
find ./ -name "znUfwfE3Rt22GMMqANMbQQ"
./indices/znUfwfE3Rt22GMMqANMbQQ
建议：先备份，后执行物理删除
3. 再次重启集群
物理删除文件不是首选的方法去恢复集群，是无奈之法，没得其他选择的情况下使用。
一般来说，ES的集群需要做好日常的数据备份，出现故障尽量使用备份的数据进行恢复。
这里就不得不提到ES的快照了，定时建立快照是比较好的选择作为备份
总结一下：
1. 对于ES集群需要定时做好快照
2. 避免大索引，比如上百G的索引，把ILM用起来，历史数据该清理的清理、该冷的冷处理方为王道
3. 相关调优参数需要验证后再上生产环境，未经测试不要上生产环境
4. 需要有可对照的测试环境，不要直接动生产环境
5. 需要对于ES相关知识比较熟悉
原文：
涉及10TB+数据，ElasticSearch紧急线上问题复盘文章来源：https://www.toymoban.com/news/detail-620885.html
Elasticsearch 5.x 数据备份和恢复文章来源地址https://www.toymoban.com/news/detail-620885.html
到了这里，关于elasticsearch 故障恢复的参考 —— 筑梦之路的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
