为 GET 操作创建内存段失败 - 如何解决此 Elasticsearch 异常

适用版本： 7.14-8.11 说明： 该异常的含义以下方源码片段为准。

1. 错误异常的基本描述 #

failed to create an in-memory segment for get [id] 是 Elasticsearch 分片引擎层抛出的 EngineException。当客户端通过 GET /{index}/_doc/{id} 发起实时读取请求时，Elasticsearch 需要把尚未刷盘（flush）的 translog 操作合并成一个临时的内存段（in-memory segment），以便实时返回最新写入结果。如果这个内存段的构建过程失败，就会触发该异常。

常见现象 #

• 实时 GET 请求返回 500 内部服务器错误，异常信息中包含 EngineException: failed to create an in-memory segment for get [...].
• 应用侧表现为个别文档读取失败，但同一索引的其他文档或搜索请求可能仍然正常。
• 在 Elasticsearch 节点日志中可以看到与该异常同时出现的 IOException 或 AlreadyClosedException 堆栈。
• 如果问题持续存在，受影响分片的读取能力会下降，甚至导致该分片上的所有实时 GET 请求失败。

典型报错与异常栈 #

org.elasticsearch.index.engine.EngineException: failed to create an in-memory segment for get [dGhpcyBpcyB0ZXN0]
Caused by: java.io.IOException: failed to open segment reader
    at org.apache.lucene...
    at org.elasticsearch.index.engine.InternalEngine.get(InternalEngine.java:...)

2. 为什么会发生这个错误 #

该异常的核心触发点在 InternalEngine.get() 方法中，具体是在尝试将尚未刷盘的 translog 操作构造为 LeafReader 之前失败。常见原因可以分为以下几类：

2.1 分片引擎或 Lucene 层异常 #

• 段文件损坏：分片目录中的 Lucene 段文件（.si、.cfs、.liv 等）部分损坏，导致内存段无法正确构建。
• translog 损坏或截断：translog 文件在写入或同步过程中损坏，使得实时 GET 无法从 translog 中恢复尚未刷盘的操作。
• 分片状态异常：分片正处于 RECOVERING、RELOCATING 或 CLOSED 状态，引擎内部不允许创建临时内存段。

2.2 磁盘与 I/O 问题 #

• 磁盘空间不足：节点磁盘使用率接近 100%，导致 Lucene 无法分配新的文件描述符或写入临时文件。
• 磁盘 I/O 错误：底层磁盘出现坏道、只读挂载或文件系统错误，引发 IOException。
• 文件描述符耗尽：节点打开文件数达到系统上限（ulimit -n），新段文件无法被打开。

2.3 内存压力 #

• JVM 堆内存紧张：实时 GET 需要在堆内构建临时段结构，如果堆内存不足，可能导致段创建失败或触发 OutOfMemoryError。
• IndexReader 未正确关闭：之前的操作中 IndexReader 没有正常释放，导致资源泄漏，累积后影响新的段创建。

3. 如何排查这个异常 #

建议按以下步骤逐步定位根因：

1. 查看节点日志：在异常时间点前后搜索目标节点日志，确认是否有 IOException、CorruptIndexException、FileSystemException 或磁盘相关错误。

   grep -n "failed to create an in-memory segment" /var/log/elasticsearch/elasticsearch.log
   grep -n "IOException\|CorruptIndex\|disk" /var/log/elasticsearch/elasticsearch.log | tail -50
   

2. 检查分片状态：确认目标索引和分片的健康状态，判断是否存在恢复、迁移或关闭事件。

   curl -s "http://localhost:9200/_cat/shards/${index_name}?v"
   curl -s "http://localhost:9200/_cluster/health/${index_name}?pretty"
   

3. 检查磁盘与系统资源：在目标节点上执行以下检查：

   df -h                    # 磁盘使用率
   ulimit -n                # 文件描述符限制
   free -h                  # 内存使用
   dmesg | tail -30          # 系统内核日志（磁盘/I/O 错误）
   

4. 尝试复现：用同一 _id 多次执行 GET 请求，判断是个别文档问题还是整个分片读取路径异常。

   curl -s "http://localhost:9200/${index_name}/_doc/${doc_id}?pretty"
   

5. 检查 translog 完整性：如果怀疑 translog 损坏，可以尝试对分片执行 translog 修剪（需在维护窗口操作）。

   curl -s -X POST "http://localhost:9200/${index_name}/_flush?force=true&wait_if_ongoing=true"
   

4. 如何解决这个错误 #

4.1 紧急修复 #

• 恢复磁盘空间：如果磁盘已满，立即清理旧日志、旧快照或不需要的索引，确保磁盘使用率低于 85%。
• 重启受影响节点：在确认数据不会进一步损坏的前提下，尝试重启节点，使分片重新分配并重建引擎上下文。
• 分配副本：如果主分片受影响但副本可用，可以临时将副本提升为主分片（通过 _cluster/reroute）。

4.2 修复损坏的分片 #

如果确认是段文件或 translog 损坏，可以考虑以下方案：

1. 从副本恢复：如果索引有其他副本分片，先分配一个新副本，待数据同步完成后，再移除损坏的主分片。

   curl -s -X POST "http://localhost:9200/_cluster/reroute" -H 'Content-Type: application/json' -d '{
     "commands": [
       { "allocate_replica": { "index": "${index_name}", "shard": 0, "node": "target_node_name" } }
     ]
   }'
   

2. 使用 _forcemerge 修复段：在问题较轻的情况下，尝试强制合并段文件，触发 Lucene 重写操作。

   curl -s -X POST "http://localhost:9200/${index_name}/_forcemerge?max_num_segments=1"
   

3. 重建索引：如果损坏严重且无法修复，需从备份恢复或重新索引数据。

   curl -s -X PUT "http://localhost:9200/${index_name}_rebuilt" -H 'Content-Type: application/json' -d '{
     "settings": { "number_of_replicas": 1 },
     "mappings": { ... }
   }'
   

4.3 调整配置预防复发 #

• 适当提高节点的 ulimit -n 值（建议 65535 或更高）。
• 为 JVM 堆设置合理上限（不超过物理内存的 50%，且不超过 30GB）。
• 调整 translog 刷盘策略，降低数据丢失风险：

  index.translog.flush_threshold_size: 512mb
  index.translog.sync_interval: 5s
  

5. 预防措施与最佳实践 #

• 监控磁盘使用率：配置告警，在磁盘使用率超过 80% 时提前介入，避免写满导致引擎异常。
• 定期执行 _forcemerge：对不再写入的索引定期合并段文件，减少段文件数量和潜在损坏风险。
• 启用软删除（soft deletes）：确保 index.soft_deletes.enabled: true（默认已开启），提升 translog 恢复能力。
• 合理设置副本数：生产环境建议至少设置 number_of_replicas: 1，确保分片损坏时有可用副本。
• 定期备份：使用 Elasticsearch 的快照功能定期备份索引数据，确保在严重损坏时可以快速恢复。

借助 INFINI 产品提升排障效率 #

• INFINI Console 可以实时查看分片状态、节点磁盘/内存/JVM 指标和异常趋势，帮助快速判断是局部分片问题还是系统性问题。
• INFINI Gateway 可以部署在 Elasticsearch 前面，对 GET 请求进行观测、限流和缓存，减少异常请求对后端集群的冲击，同时记录完整的请求日志便于事后分析。

6. 小结 #

failed to create an in-memory segment for get [id] 不是简单的"文档不存在"错误，而是分片引擎在为实时 GET 临时生成内存段时失败，根因通常涉及 Lucene 段文件或 translog 的完整性、磁盘 I/O 健康状态以及 JVM 内存压力。排查时应优先检查节点日志中的 IOException 和磁盘状态，再根据损坏程度选择副本恢复、强制合并或重建索引等修复方案。

相关错误 #

• 创建引擎失败
• 创建本地检查点跟踪器失败
• 创建新的 translog 文件失败
• flush 失败
• 段文件损坏

附：日志上下文 #

下面保留当前页面中的源码片段，便于结合异常调用栈定位问题：

+ " documents"
);
}
return reader.leaves().get(0).reader();
} catch (IOException e) {
    throw new EngineException(shardId, "failed to create an in-memory segment for get [" + operation.id() + "]", e);
}
}  @Override
public CacheHelper getCoreCacheHelper() {