无主节点阻塞配置

配置项作用 #

cluster.no_master_block 配置项指定当集群没有主节点（Master）时，对哪些操作进行阻塞。这是一个重要的安全配置，用于在主节点故障期间防止数据不一致或脑裂情况下的数据损坏。

配置项类型 #

该配置项为动态配置，可以在运行时通过集群设置 API 进行修改。

默认值 #

write（阻塞写操作）

是否必需 #

可选配置项（有默认值）

可选值 #

配置格式 #

# 默认配置（推荐）
cluster.no_master_block: write

# 完全阻塞
cluster.no_master_block: all

# 只阻塞元数据操作
cluster.no_master_block: metadata_write

工作原理 #

当集群失去主节点时，不同配置值的阻塞行为：

┌─────────────────────────────────────────────────────────────────────┐
│                      集群失去主节点                                  │
└─────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
                ┌─────────────┴─────────────┐
                │                           │
           配置: write                  配置: all
                │                           │
                ▼                           ▼
        ┌───────┴────────┐           ┌───────┴────────┐
        │                │           │                │
    允许读操作        阻塞写操作      阻塞所有操作      阻塞所有操作
    (搜索查询)        (索引文档)      (搜索查询)       (索引文档)
        │                │           │                │
        ▼                ▼           ▼                ▼
    数据可读取      写入被拒绝      所有请求被拒绝    返回 503 错误
    返回最新数据    返回错误

使用场景 #

1. 正常生产环境（推荐） #

cluster.no_master_block: write

• 允许读取已有数据
• 阻止写入新数据
• 保证数据一致性
• 用户体验最好

2. 严格安全要求 #

cluster.no_master_block: all

• 完全停止所有操作
• 最高安全保障
• 适用于金融等对一致性要求极高的场景

3. 特殊场景 #

cluster.no_master_block: metadata_write

• 只阻止结构性变更
• 允许数据读写
• 需要谨慎使用

阻塞级别详解 #

write（写阻塞） #

阻塞操作：

• 索引文档（Index/Update/Delete/Bulk）
• 创建索引（Create Index）
• 删除索引（Delete Index）
• 修改映射（Update Mapping）
• 修改设置（Update Settings）

允许操作：

• 搜索查询（Search）
• 获取文档（Get）
• 查询集群状态（Cluster State）

适用场景： 生产环境推荐配置

all（全部阻塞） #

阻塞操作：

• 所有写操作
• 所有读操作
• 元数据操作

允许操作：

• 基本无（部分本地节点操作可能仍可用）

适用场景： 高安全要求场景

metadata_write（元数据写阻塞） #

阻塞操作：

• 创建索引
• 删除索引
• 修改映射
• 修改集群设置

允许操作：

• 索引文档
• 搜索查询
• 获取文档

适用场景： 特殊需求场景

使用示例 #

通过 API 动态修改：

# 切换到完全阻塞模式
PUT /_cluster/settings
{
  "transient": {
    "cluster.no_master_block": "all"
  }
}

# 恢复默认写阻塞
PUT /_cluster/settings
{
  "transient": {
    "cluster.no_master_block": "write"
  }
}

与主节点选举的关系 #

主节点故障
      │
      ▼
no_master_block 生效
      │
      ├── all: 完全停止服务
      ├── write: 允许读，阻止写
      └── metadata_write: 只阻止元数据操作
      │
      ▼
新主节点选举完成
      │
      ▼
阻塞自动解除
      │
      ▼
恢复正常服务

推荐设置建议 #

生产环境：使用默认值 write

错误响应 #

当操作被阻塞时，API 返回：

{
  "error": {
    "type": "cluster_block_exception",
    "reason": "blocked by: [SERVICE_UNAVAILABLE/2/no master]; "
  },
  "status": 503
}

与相关配置的关系 #

监控建议 #

# 查看当前配置
GET /_cluster/settings?filter_path=*.cluster.no_master_block

# 查看集群健康状态
GET /_cluster/health

# 查看节点角色
GET /_cat/nodes?v&h=name,master

常见问题 #

问题 1：写入报 503 错误

cluster_block_exception: blocked by: [SERVICE_UNAVAILABLE/2/no master]

原因： 集群当前没有主节点

解决方案：

1. 检查主节点状态

GET /_cat/nodes?v&h=name,master

2. 等待主节点选举完成

GET /_cluster/health

3. 如果选举失败，检查网络和配置

# 检查 cluster.name 一致性
cluster.name: production

# 检查种子节点配置
discovery.seed_hosts:
  - "192.168.1.10:9300"

问题 2：读操作也被阻塞

原因： 配置设置为 all

解决方案：

# 改为 write 模式
PUT /_cluster/settings
{
  "transient": {
    "cluster.no_master_block": "write"
  }
}

问题 3：何时应该使用 all？

使用场景：

• 金融交易系统
• 需要强一致性的场景
• 脑裂风险较高的情况
• 数据完整性优先于可用性

安全考虑 #

防止脑裂数据损坏：

正常状态:
主节点 A ────┐
             ├─── 数据一致
数据节点 B ───┘

主节点故障:
主节点 A (离线)      数据节点 B
        │                 │
        │                 ▼
        │          no_master_block 生效
        │                 │
        │          阻止写入操作
        │                 │
        ▼                 ▼
    新主节点选举      数据保持一致

注意事项 #

1. 动态更新：此配置为动态配置，可在线修改
2. 自动解除：新主节点选举完成后，阻塞自动解除
3. 默认安全：默认值 write 已提供足够的安全保障
4. 谨慎使用 metadata_write：除非完全理解风险，否则不建议使用
5. 监控集群状态：定期监控主节点状态和集群健康度