# **说明**

本文描述问题及解决方法同样适用于 [腾讯云 Elasticsearch Service（ES）](https://cloud.tencent.com/document/product/845?from=20421&from_column=20421)。


# **背景**
最近在做 ES 集群快照备份的时候踩了个坑。我们有一堆历史索引为了省内存都 close 掉了，结果发现 6.8 版本根本不让你对 close 的索引做快照，报错说索引被 block 了。后来升级到 7.x 就没这问题了。

这就让我好奇了：到底是哪个版本开始支持的？ES 团队是怎么实现的？于是我翻了翻源码和 Git 历史，发现了一些有意思的东西。


# **先说问题：6.8 版本的坑**

在 6.8 版本里，要是对一个 close 的索引做快照，直接就报错了。看看测试代码就知道：

```java
public void testSnapshotSingleClosedIndex() throws Exception {
    Client client = client();
    
    logger.info("-->  creating repository");
    assertAcked(client.admin().cluster().preparePutRepository("test-repo")
            .setType("fs").setSettings(Settings.builder()
                    .put("location", randomRepoPath())));

    createIndex("test-idx");
    ensureGreen();
    logger.info("-->  closing index test-idx");
    assertAcked(client.admin().indices().prepareClose("test-idx"));

    logger.info("--> snapshot");
    // 在 6.8 中，这里会抛出 INDEX_CLOSED_BLOCK_ID 错误
    assertBlocked(client.admin().cluster().prepareCreateSnapshot("test-repo", "test-snap-1")
            .setWaitForCompletion(true).setIndices("test-idx"), 
            MetaDataIndexStateService.INDEX_CLOSED_BLOCK_ID);
}
```

测试里直接用 `assertBlocked` 断言，说明这就是预期行为——close 的索引就是不让你快照。

这个限制挺烦人的：

- 你有一堆历史索引 close 着省资源，但要备份的话得先 open，备份完再 close。这一套流程下来又麻烦又容易出错。
- 临时 open 索引会吃掉大量内存和 CPU，索引多了集群直接顶不住。
- open 和 close 之间那段时间，集群资源紧张，可能影响线上业务。


# **怎么确认是 7.2 开始支持的？**

既然遇到这个问题，我就想搞清楚到底是哪个版本开始支持的。直接翻 Git 历史最靠谱。

**第一步：搜 commit 记录**

```bash
git log --all --grep="close.*index.*snapshot" --oneline
```

跑完这个命令，出来一堆 commit，其中有个特别显眼：

```
fef11f7efc6 Allow snapshotting replicated closed indices (#39644)
```

**第二步：看看这个 commit 改了啥**

```bash
git show fef11f7efc6 --stat
```

commit 信息如下：

```
commit fef11f7efc6f94ce750b106ccb5aae75cca14cbd
Author: Yannick Welsch <yannick@welsch.lu>
Date:   Wed Mar 6 14:47:41 2019 +0100

    Allow snapshotting replicated closed indices (#39644)
    
    This adds the capability to snapshot replicated closed indices.
    
    It also changes snapshot requests in v8.0.0 to automatically expand 
    wildcards to closed indices and hence start snapshotting closed indices 
    by default. For v7.1.0 and above, wildcards are by default only expanded 
    to open indices, which can be changed by explicitly setting the 
    expand_wildcards option either to all or closed.
    
    Note that indices are always restored as open indices, even if they 
    have been snapshotted as closed replicated indices.
    
    Relates to #33888
```

**第三步：这个 commit 在哪个版本里？**

```bash
git tag --contains fef11f7efc6 | grep "^v7\." | sort -V | head -1
```

答案是：**v7.2.0**

所以结论就是，**ES 从 7.2.0 开始支持 close 索引快照**。

1. 看 `SharedClusterSnapshotRestoreIT.java` 里的 `testSnapshotClosedIndex()` 测试，7.2 之后就不用 `assertBlocked` 了，直接正常执行快照。

2. 看 `SnapshotsService.java`，7.2 版本删掉了这段代码：

```java
// 7.2 之前的代码
} else if (indexMetaData.getState() == IndexMetaData.State.CLOSE) {
    for (int i = 0; i < indexMetaData.getNumberOfShards(); i++) {
        ShardId shardId = new ShardId(indexMetaData.getIndex(), i);
        builder.put(shardId, new SnapshotsInProgress.ShardSnapshotStatus(
            null, State.MISSING, "index is closed"));
    }
}
```

这段代码被删掉，就意味着不再把 close 的索引分片标记为 `MISSING` 了。


# **7.2 是怎么做到的？**

现在来看看技术实现。要明白 7.2 怎么支持 close 索引快照，得先了解 ES 的索引状态和快照机制。

## 索引的两种状态

ES 的索引有两种主要状态：

- **OPEN**：索引处于活跃状态，可以进行读写操作
- **CLOSE**：索引被关闭，释放了大部分内存资源，但磁盘上的数据仍然保留

## 快照的本质

快照其实就是对 Lucene 索引文件的增量备份。**关键点在于：快照操作需要访问底层的 Lucene 文件，但不需要索引处于可搜索状态**。

这就是为什么 close 索引理论上可以做快照——文件还在磁盘上，只是不接受搜索请求而已。

## 关键代码变更

来看看 7.2 版本改了哪些关键代码：

### 变更 1：不再检查 READ block

在 `TransportCreateSnapshotAction.java` 中：

```java
// 7.2 之前
@Override
protected ClusterBlockException checkBlock(CreateSnapshotRequest request, ClusterState state) {
    // 检查全局 metadata 读取 block
    ClusterBlockException clusterBlockException = 
        state.blocks().globalBlockedException(ClusterBlockLevel.METADATA_READ);
    if (clusterBlockException != null) {
        return clusterBlockException;
    }
    // 还要检查索引级别的 READ block（close 索引有这个 block）
    return state.blocks()
        .indicesBlockedException(ClusterBlockLevel.READ, 
            indexNameExpressionResolver.concreteIndexNames(state, request));
}

// 7.2 之后
@Override
protected ClusterBlockException checkBlock(CreateSnapshotRequest request, ClusterState state) {
    // 只检查 metadata block，允许快照 close 的索引（它们有 read block）
    ClusterBlockException clusterBlockException = 
        state.blocks().globalBlockedException(ClusterBlockLevel.METADATA_READ);
    if (clusterBlockException != null) {
        return clusterBlockException;
    }
    return null;  // 不再检查索引级别的 READ block
}
```

**重点**：7.2 删掉了对索引 READ block 的检查。因为 close 的索引虽然有 READ block，但这不应该阻止快照操作。

### 变更 2：不再将 Close 索引标记为 MISSING

在 `SnapshotsService.java` 中：

```java
// 7.2 之前
if (indexMetaData.getState() == IndexMetaData.State.CLOSE) {
    // 将 close 索引的所有分片标记为 MISSING
    for (int i = 0; i < indexMetaData.getNumberOfShards(); i++) {
        ShardId shardId = new ShardId(indexMetaData.getIndex(), i);
        builder.put(shardId, new SnapshotsInProgress.ShardSnapshotStatus(
            null, State.MISSING, "index is closed"));
    }
}

// 7.2 之后
// 这段代码被完全移除，close 索引和 open 索引一样处理
```

### 变更 3：IndexShard 层面的支持

在 `IndexShard.java` 中，早就有对 close 状态快照的支持：

```java
public Engine.IndexCommitRef acquireLastIndexCommit(boolean flushFirst) 
    throws EngineException {
    final IndexShardState state = this.state;
    // 允许在 close 状态下进行快照，因为我们需要在关闭 shard 之后、
    // 关闭 engine 之前做一次快照
    if (state == IndexShardState.STARTED || state == IndexShardState.CLOSED) {
        return getEngine().acquireLastIndexCommit(flushFirst);
    } else {
        throw new IllegalIndexShardStateException(shardId, state, 
            "snapshot is not allowed");
    }
}
```

**重点**：这段代码说明，在 shard 层面，即使索引是 CLOSED 状态，只要 engine 还在，就能获取 index commit 做快照。

## 支撑这个功能的几个特性

7.2 能支持 close 索引快照，靠的是这几个关键特性：

### 1. Replicated Closed Indices（复制的关闭索引）

这是 7.2 引入的一个重要特性。以前 close 一个索引会完全释放分片，主分片和副本都没了。而 7.2 之后：

- Close 索引时，分片的元数据和 Lucene 文件还留着
- 分片的 Engine 保持可访问（虽然不接受读写请求）
- 这样快照操作就能访问底层的 Lucene 文件了

### 2. VERIFIED_BEFORE_CLOSE 设置

在 `RestoreService.java` 里可以看到，恢复时会删掉这个设置：

```java
settingsBuilder.remove(MetaDataIndexStateService.VERIFIED_BEFORE_CLOSE_SETTING.getKey());
```

这个设置用来标记索引在 close 之前已经验证过了，确保数据完整性。

### 3. 更精细的 Block 控制

7.2 对 cluster block 的控制更精细了：

- **METADATA_READ block**：阻止读取集群元数据
- **READ block**：阻止读取索引数据（close 索引有这个 block）
- **WRITE block**：阻止写入操作

快照操作只需要访问元数据和底层文件，不需要真正“读取”索引（即不需要执行搜索），所以可以绕过 READ block。

## 工作流程图

用一个流程图来展示 7.2 中 close 索引快照的完整流程：
![Clipboard_Screenshot_1766391142.png](https://developer.qcloudimg.com/http-save/yehe-7348459/5e9099ba83b64ab242e13d4d7bb9680e.png)


## 6.8 vs 7.2 对比

来对比一下两个版本在处理 close 索引快照时的差异：

| 方面 | 6.8 版本 | 7.2 版本 |
|------|----------|----------|
| **Block 检查** | 检查 METADATA_READ 和 READ block | 只检查 METADATA_READ block |
| **Close 索引处理** | 标记所有分片为 MISSING 状态 | 正常处理，和 OPEN 索引一样 |
| **分片状态** | Close 时完全释放分片 | Close 时保留分片元数据和文件 |
| **Engine 访问** | Close 后无法访问 Engine | Close 后仍可访问 Engine 获取 commit |
| **快照结果** | 失败或被阻塞 | 成功创建快照 |


# ** 实际使用建议 **

## 什么时候应该升级？

如果你的集群有这些情况，建议升级到 7.2 或更高：

- 有大量历史索引需要 close 省资源
- 需要对所有索引（包括 close 的）定期备份
- 想简化备份流程，避免频繁 open/close

## 使用注意事项

1. **恢复后索引总是 OPEN 的**：即使你快照的是 close 索引，恢复后也是 open 状态。需要的话要手动 close。

2. **通配符行为变了**：7.1.0 及以上，快照请求的通配符默认只展开到 open 索引。要包含 close 索引，得显式设置 `expand_wildcards`：

```json
PUT /_snapshot/my_backup/snapshot_1
{
  "indices": "my-index-*",
  "expand_wildcards": "all"  // 或 "closed"
}
```

3. **资源消耗**：虽然 close 索引快照不需要 open 索引，但还是要访问磁盘文件，会有一定 I/O 开销。

## 最佳实践

```bash
# 1. 创建包含所有索引（包括 close 的）的快照
PUT /_snapshot/my_backup/snapshot_all
{
  "indices": "*",
  "expand_wildcards": "all",
  "include_global_state": true
}

# 2. 只快照 close 的索引
PUT /_snapshot/my_backup/snapshot_closed_only
{
  "indices": "*",
  "expand_wildcards": "closed"
}

# 3. 恢复后如果需要保持 close 状态
POST /_snapshot/my_backup/snapshot_all/_restore
{
  "indices": "my-old-index"
}
# 恢复完成后
POST /my-old-index/_close
```


# ** 总结 **

这个功能的演进体现了 Elasticsearch 团队对用户实际需求的关注，也展示了软件设计中"关注点分离"的重要性——快照操作关注的是底层文件，而不是索引的可搜索性。

希望这篇文章能帮助你更好地理解 Elasticsearch 的快照机制，也为你的版本升级决策提供参考。如果你也在使用 Elasticsearch，不妨分享一下你的经验和遇到的问题。

本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service（ES）。

Elasticsearch 的 Close 索引快照：6.8 不支持，7.2 就行了？

ES 6.8不支持对close索引做快照，7.2开始支持。通过Git历史定位到关键commit fef11f7efc6，核心原理是移除READ block检查，利用Replicated Closed Indices特性直接访问Lucene文件完成快照。

官方产研

云计算

大数据

后端

Elasticsearch从7.2版本开始支持对关闭索引进行快照备份，解决了6.8版本必须打开索引才能备份的问题。本文详细分析了版本差异、技术实现原理及使用建议，帮助用户优化备份流程，减少资源消耗。适用于腾讯云ES服务用户参考。

Elasticsearch Service

数据完整性

软件设计

GitHub

JSON

Java

ES特惠专场，新客首购1折起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Elasticsearch 的 Close 索引快照：6.8 不支持，7.2 就行了？-腾讯云开发者社区-腾讯云

Elasticsearch 的 Close 索引快照：6.8 不支持，7.2 就行了？

Elasticsearch 的 Close 索引快照：6.8 不支持，7.2 就行了？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐