小菜鸟

java菜鸟号正在起航

0%

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 2.6k 阅读时长 ≈ 2 分钟

Elasticsearch 索引健康状态为 Red 的排查与解决方案

当 Elasticsearch 索引健康状态显示为 red 时，表示至少有一个主分片未分配（无法使用），这会导致部分或全部数据不可访问。本文以实际案例讲解如何定位 red 状态的根源（如磁盘空间不足、分片分配失败等），并提供针对性解决方案。

Red 状态的核心原因

Elasticsearch 集群健康状态分为三级：

  • green：所有主分片和副本分片均正常分配。
  • yellow：所有主分片正常分配，但至少有一个副本分片未分配。
  • red：至少有一个主分片未分配（数据不可用）。

red 状态的常见触发因素：

  • 主分片所在节点宕机且无副本可用。
  • 分片分配失败（如磁盘空间不足、权限问题、配置冲突）。
  • 索引损坏或数据文件丢失。
  • 节点资源不足（内存、CPU 超限）。

排查步骤：从整体到细节

查看集群与索引健康状态

首先通过 _cluster/health 确认问题范围（是单个索引还是整个集群）：

1
2
# 查看集群健康，包含索引级别的状态
GET _cluster/health?level=indices

响应示例（某索引为 red）：

索引层级健康状态

关键：锁定状态为 red 的索引（如 problem_index）。

检查分片状态与未分配原因

通过 _cat/shards 查看具体分片的状态及未分配原因：

1
2
# 筛选关键信息：索引名、分片号、主/副本、状态、未分配原因
GET _cat/shards?h=index,shard,prirep,state,unassigned.reason&v

输出示例：

分片情况

  • prirep=p 表示主分片，r 表示副本分片。
  • unassigned.reason=ALLOCATION_FAILED 说明主分片分配失败，导致副本也无法分配。

深入分析分配失败原因

使用 _cluster/allocation/explain 查看分片分配失败的详细日志：

1
GET _cluster/allocation/explain

响应示例（磁盘空间不足）：

分配失败原因

关键原因：节点磁盘使用率达 90%，超过 Elasticsearch 默认的高水位阈值（85%），导致分片无法分配。

验证资源状态

针对上述磁盘空间问题，通过 _cat/allocation 确认节点磁盘使用情况：

1
GET _cat/allocation?v

输出示例：

1
2
3
shards disk.used disk.avail disk.total disk.percent host      ip        node
     5      18gb      200mb      20gb          99 192.168.1.1 node-1
     3      10gb       10gb      20gb          50 192.168.1.2 node-2

可见 node-1 磁盘仅剩 200MB，使用率达 99%，触发分配限制。

解决方案：针对性修复

1. 磁盘空间不足（最常见）

解决步骤：

  • 清理空间：删除节点上的非必要文件（如日志、旧快照），释放至少 10% 以上的磁盘空间。

  • 临时调整阈值（紧急情况）：

    1
    2
    3
    4
    5
    6
    7
    8
    # 临时降低高水位阈值（重启后失效）
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.disk.watermark.high": "95%",  # 高水位设为95%
        "cluster.routing.allocation.disk.watermark.flood_stage": "97%"  # 洪水阶段设为97%
      }
    }

  • 长期优化：扩容磁盘，或配置索引生命周期管理（ILM）自动删除过期数据。

验证：空间释放后，Elasticsearch 会自动重试分配分片，可通过 GET _cat/shards 确认状态变为 STARTED。

2. 其他常见问题的解决

（1）分片分配被人为禁用

若通过 cluster.routing.allocation.enable 禁用了分配，需重新开启：

1
2
3
4
5
6
PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "all"  # 允许所有分片分配
  }
}
（2）节点资源不足（内存 / CPU 超限）
  • 检查节点资源：GET _nodes/stats（查看 jvm.mem、process.cpu）。
  • 解决：重启节点释放资源，或扩容节点配置。
（3）索引数据损坏

  • 尝试恢复快照：若有快照，通过 _snapshot API 恢复索引。

  • 重建索引：若数据可重新同步，删除损坏索引后重新写入数据：

    1
    DELETE problem_index  # 谨慎操作！确保数据可恢复
（4）节点间版本不兼容
  • 确认所有节点版本一致（主分片无法分配到版本更低的节点）。
  • 解决：升级节点至统一版本。

预防措施：避免 Red 状态再次发生

  1. 监控磁盘空间：通过 Elasticsearch Monitor 或第三方工具（如 Prometheus + Grafana）监控磁盘使用率，设置阈值告警（如超过 80% 告警）。

  2. 合理配置副本：为每个主分片配置至少 1 个副本（number_of_replicas: 1），避免单点故障导致主分片丢失。

  3. 禁用自动创建索引：防止误写入导致大量小索引占用资源：

    1
    2
    3
    4
    5
    6
    PUT _cluster/settings
    {
      "persistent": {
        "action.auto_create_index": ".monitoring*,*"  # 仅允许特定索引自动创建
      }
    }

  4. 定期备份：通过快照机制定期备份索引，确保数据可恢复。

  5. 配置分片分配重试：自动重试临时分配失败的分片：

    1
    2
    3
    4
    5
    6
    7
    PUT _cluster/settings
    {
      "transient": {
        "cluster.routing.allocation.node_concurrent_recoveries": 5,  # 并发恢复数
        "indices.recovery.max_bytes_per_sec": "100mb"  # 恢复速度
      }
    }

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 7.2k 阅读时长 ≈ 7 分钟

Elasticsearch 6.8.x 基本操作全解析

Elasticsearch 提供了丰富的 RESTful API 用于数据的增删改查及集群管理。以下基于 6.8.x 版本（支持 Type），详细介绍核心操作的语法、示例及注意事项。

统计操作：集群文档数量

通过 _count API 统计集群中匹配查询条件的文档总数（默认统计所有文档）。

语法

1
2
3
4
GET _count?pretty
{
  "query": { "match_all": {} }  // match_all 表示匹配所有文档
}

响应示例

1
2
3
4
5
6
7
8
9
{
  "count": 5091327,  // 匹配的文档总数
  "_shards": {
    "total": 10,     // 参与统计的分片总数
    "successful": 10, // 成功统计的分片数
    "skipped": 0,
    "failed": 0
  }
}

添加数据

通过 PUT 请求向指定索引、类型添加文档，支持自动创建索引（根据字段推断映射）。

基本添加（自动创建索引）

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 3.8k 阅读时长 ≈ 3 分钟

Elasticsearch 6.x 写入性能优化：从配置到实践

Elasticsearch 6.x 的写入性能直接影响数据采集和处理效率，尤其在日志、监控等高频写入场景中至关重要。通过优化 Translog 策略、批量写入、分段刷新等核心配置，可显著提升写入吞吐量。本文结合 6.x 版本特性，详解写入优化的关键手段。

Translog 配置优化：平衡安全性与性能

Translog（事务日志）是 Elasticsearch 保障数据安全的核心组件，但默认配置为了安全性牺牲了部分性能。通过调整 Translog 策略，可在可接受的数据风险范围内提升写入速度。

核心配置解析

默认 Translog 配置（安全性优先）：

1
2
3
4
5
6
7
"index": {
  "translog": {
    "durability": "REQUEST",  // 每次请求后立即刷写Translog到磁盘
    "sync_interval": "5s",    // 即使未触发REQUEST，也每5s刷写一次
    "flush_threshold_size": "512mb"  // Translog达512MB时触发Flush
  }
}
  • durability: "REQUEST"：每个写入请求都会同步刷写 Translog 到磁盘，确保数据不丢失，但频繁 IO 会降低性能。
  • sync_interval：定期刷写未同步的 Translog（默认 5s），作为 REQUEST 策略的补充。

优化配置（性能优先）

对于实时性要求不高、可接受少量数据丢失风险的场景（如日志采集），可调整为异步刷写：

1
2
3
4
5
6
7
8
9
PUT _index_template/optimized_template
{
  "index_patterns": ["logs-*", "metrics-*"],  // 对指定索引生效
  "settings": {
    "index.translog.durability": "async",    // 异步刷写Translog
    "index.translog.sync_interval": "60s",   // 每60s批量刷写一次
    "index.translog.flush_threshold_size": "1gb"  // 扩大触发Flush的阈值
  }
}
阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 1.5k 阅读时长 ≈ 1 分钟

VMware 网络模式：桥接、Host-only 与 NAT 的区别与应用

VMware 虚拟机提供了多种网络模式，用于控制虚拟机与宿主机、其他虚拟机及外部网络的通信方式。理解不同模式的原理和适用场景，能帮助高效配置虚拟机网络环境。

桥接模式（Bridged）

核心原理

桥接模式相当于为虚拟机分配一个独立的网络身份，与宿主机 “平起平坐”，共享宿主机的物理网卡接入网络。虚拟机就像局域网中一台独立的物理机，拥有与宿主机同网段的 IP 地址。

网络特征

  • IP 配置：需手动设置与宿主机同网段的 IP（或通过 DHCP 获取局域网内的独立 IP）。
  • 通信范围：
    • 虚拟机 ←→ 宿主机：可直接通信。
    • 虚拟机 ←→ 局域网内其他设备（物理机 / 虚拟机）：可直接通信。
    • 虚拟机 ←→ 外网：可直接访问（与宿主机上网方式一致）。
  • 网卡使用：直接使用宿主机的物理网卡（如 WiFi、有线网卡）。
阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 4.1k 阅读时长 ≈ 4 分钟

Dockerfile 详解：镜像构建的 “说明书”

Dockerfile 是一个文本文件，包含一系列构建镜像的指令，通过 docker build 命令可自动执行这些指令生成自定义镜像。它就像镜像的 “施工蓝图”，明确了从基础镜像到最终镜像的每一步操作，实现了镜像构建的自动化和可复用性。

Dockerfile 基本结构

Dockerfile 由指令（Instruction） 和注释组成，指令格式为：
INSTRUCTION arguments（指令大写，参数小写，惯例）。

核心指令包括：FROM、RUN、CMD、COPY、ADD 等，下文将详细解析。

核心指令详解

1. FROM：指定基础镜像

  • 作用：声明构建镜像的基础镜像（所有镜像都需基于某个基础镜像构建）。

  • 位置：必须是 Dockerfile 的第一条指令。

  • 示例：

    1
    2
    3
    4
    5
    6
    # 使用官方centos镜像的latest版本作为基础
    FROM centos:latest

    # 使用多阶段构建时，可多次使用FROM（如构建阶段和运行阶段）
    FROM maven:3.8 AS builder  # 构建阶段
    FROM openjdk:8-jre         # 运行阶段

2. MAINTAINER：指定镜像作者（已过时，推荐用 LABEL）

  • 作用：标注镜像的作者信息（姓名、邮箱等）。

  • 示例：

阅读全文 »