真实问题：脑裂导致数据丢失

2023年底，我负责的ES 7.17.5日志集群（3节点，4核16G，SSD）在凌晨网络抖动后出现脑裂。两个节点各自选主，恢复后分片无法分配，最终丢失约2%的索引数据。事后排查：discovery.zen.minimum_master_nodes虽设置2，但新版ES7.x已不推荐手动设置；节点角色未区分master/data，导致多节点同时参与选举。这个过程彻底暴露了我们对ES部署理解的不足。

方案对比：单节点 vs 3节点 vs 5节点

生产环境通常不会选择单节点。但为了对比，我搭建了三种配置并跑压测（ES 8.10.2，各节点8核32G SSD，1000万文档，每条1KB）。

结论：3节点+副本1是性价比最优选，适合大多数中小规模生产。

完整部署与调优方案

环境准备

操作系统：Ubuntu 22.04 LTS
JDK：OpenJDK 17.0.8（ES 8.x必需）
ES版本：8.10.2
硬件：每节点至少8核32G内存，SSD（推荐NVMe），网卡万兆。

系统参数优化（bash）

# 调整文件句柄和进程数
cat >> /etc/security/limits.conf <> /etc/sysctl.conf

# 网络优化
sysctl -w net.core.somaxconn=65535
echo "net.core.somaxconn=65535" >> /etc/sysctl.conf
sysctl -w net.ipv4.tcp_tw_reuse=1
echo "net.ipv4.tcp_tw_reuse=1" >> /etc/sysctl.conf
sysctl -w net.ipv4.tcp_fin_timeout=30
echo "net.ipv4.tcp_fin_timeout=30" >> /etc/sysctl.conf

ES配置文件（yaml）

# /etc/elasticsearch/elasticsearch.yml
cluster.name: production-logs
node.name: node-1
path.data: /data/es/data
path.logs: /var/log/elasticsearch
network.host: 0.0.0.0
http.port: 9200
transport.port: 9300

# 发现与初始化（8.x使用）
discovery.seed_hosts:
  - node1:9300
  - node2:9300
  - node3:9300
cluster.initial_master_nodes:
  - node-1
  - node-2
  - node-3

# 节点角色（建议分离master/data，小集群可用混合）
node.roles: [ master, data, ingest ]

# 索引默认设置
index.number_of_shards: 3
index.number_of_replicas: 1

# 恢复设置
gateway.recover_after_nodes: 2
gateway.expected_nodes: 3
gateway.recover_after_time: 5m

# 线程池调整（通常默认即可，高并发可微调）
thread_pool.write.queue_size: 1000
thread_pool.search.queue_size: 1000
# 注意：不能手动改线程数，ES自动根据CPU核心数设置

JVM调优（jvm.options）

# /etc/elasticsearch/jvm.options.d/custom.options
-Xms16g
-Xmx16g   # 堆大小≤物理内存50%且≤32GB
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:ParallelGCThreads=4
-XX:ConcGCThreads=2
-XX:+AlwaysPreTouch
-XX:+ExitOnOutOfMemoryError  # 内存溢出时自动退出，方便k8s重启

启动集群并验证（bash）

# 启动各节点（需要先初始化安全配置，8.x默认开启安全）
sudo -u elasticsearch /usr/share/elasticsearch/bin/elasticsearch -d

# 查看日志
tail -f /var/log/elasticsearch/production-logs.log

# 生成密码（首次启动自动生成，或手动设置）
/usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic -i

# 检查集群健康
curl -k -u elastic:yourpassword https://localhost:9200/_cluster/health?pretty

# 期望输出（green状态）
{
  "cluster_name" : "production-logs",
  "status" : "green",
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 3,
  "active_shards" : 6,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0
}

索引模板与性能压测

创建索引模板（json via Kibana Dev Tools）

PUT _index_template/logs_template
{
  "index_patterns": ["logs-*"],
  "template": {
    "settings": {
      "number_of_shards": 3,
      "number_of_replicas": 1,
      "refresh_interval": "30s",
      "translog.durability": "async",
      "translog.sync_interval": "5s",
      "index.routing.allocation.total_shards_per_node": 2
    },
    "mappings": {
      "properties": {
        "@timestamp": { "type": "date" },
        "message": { "type": "text", "analyzer": "standard" },
        "level": { "type": "keyword" },
        "service": { "type": "keyword" },
        "host": { "type": "keyword" }
      }
    }
  }
}

使用esrally压测（bash）

# 安装esrally（需Python3）
pip3 install esrally

# 执行压测（使用http_logs workload）
rally --pipeline=benchmark-only \
  --target-hosts=node1:9200,node2:9200,node3:9200 \
  --workload=http_logs \
  --client-options="basic_auth_user:'elastic',basic_auth_password:'yourpassword',use_ssl:true,verify_certs:false" \
  --challenge=append-no-conflicts \
  --number-of-shards=3 \
  --number-of-replicas=1 \
  --report-format=csv \
  --report-file=/tmp/rally_result.csv

效果数据对比

数据来自同一3节点集群，使用esrally压测1000万文档。调优涉及：系统参数、JVM、刷新间隔、translog异步、线程池队列调整。

避坑指南（10条实际踩过的坑）

1. 脑裂坑：ES 8.x已废弃discovery.zen.minimum_master_nodes，改为自适应。但必须确保cluster.initial_master_nodes在第一次启动时包含所有master候选节点。如果忘记设置，或者节点重启后变更，可能导致选举失败。
2. 堆大小超32GB：JDK压缩指针失效后，性能下降30%以上。务必保持Xmx≤32GB。若需要更大内存，分多个节点。
3. path.data指向/tmp：默认是/var/lib/elasticsearch，但不少教程让改成/opt/elasticsearch/data，若不小心写成/tmp，重启后数据全丢。
4. 副本数超过节点数-1：3节点集群副本数设为2，会导致分片无法分配，集群变yellow。副本数应≤节点数-1。
5. 索引刷新间隔默认1s：对于日志类批量写入，1s刷新会造成合并压力。改为30s后写入性能翻倍。
6. 未关闭swap：ES对swap极敏感，一旦触发GC会显著变慢。务必swapoff -a并在fstab中注释。
7. 使用root运行ES：ES强制不允许root启动，但有些人用sudo或者改配置绕过，会导致安全漏洞和数据权限问题。
8. 忽略网络调优：默认net.core.somaxconn=128，在高并发下会丢请求。改为65535。
9. 分片过多：每个分片有内存开销，建议分片大小10-50GB。若总数据量100GB，分5-10个分片即可。
10. 不监控GC：使用GET _nodes/stats/jvm查看GC次数和耗时。若Young GC频繁，需调整新生代大小或增加堆。

深入原理：为什么这样调优有效

分片与路由

ES索引由分片组成，每个分片是一个Lucene索引。查询时默认广播到所有分片，分片数越多，查询越慢。通过合理设置number_of_shards并利用routing key，可以将查询限制到少数分片。部署时建议按照节点数*副本数的倍数规划分片，例如3节点、副本1，则主分片数设置为3×2=6的因子，这里设为3。

translog异步写入

默认translog.durability=request，每次写入刷盘，保证数据不丢但性能差。改为async后每5s同步一次，写入吞吐提升2-3倍。但极端宕机可能丢失最近5s数据。日志场景可接受。

线程池配置

ES内置线程池：search、write、analyze等。默认线程数为CPU核数。我们不手动改线程数，而是增大队列容量，避免拒绝请求。注意write线程池队列溢出错误（es_rejected_execution_exception）可通过调整thread_pool.write.queue_size缓解。如果持续溢出，说明需要增加节点。

GC选择G1

ES官方推荐G1GC，相比CMS可减少暂停时间。我们设置MaxGCPauseMillis=200，让G1智能调整区域大小。同时AlwaysPreTouch在启动时预占内存，避免运行时再分配导致延迟。

节点角色分离

大集群（>10节点）建议将master、data、ingest角色分到不同节点。master节点只负责集群状态，不存储数据，减轻压力。本文中3节点混合角色也可以，但需要确保master候选节点为奇数（这里3个）。

监控与运维

推荐使用Prometheus + elasticsearch_exporter + Grafana快速搭建监控。另外安装Cerebro（原kopf）用于可视化查看分片分配。

# 安装elasticsearch_exporter（使用Docker）
docker run -d --restart=always \
  --net=host \
  prometheuscommunity/elasticsearch-exporter:latest \
  --es.uri=https://elastic:password@localhost:9200 \
  --es.all \
  --es.indices \
  --es.cluster_settings

# Prometheus.yml添加job：
scrape_configs:
  - job_name: 'elasticsearch'
    static_configs:
      - targets: ['localhost:9114']

Grafana推荐使用ID 6483的ES监控仪表板。

故障恢复速查

• 集群变red：部分主分片未分配。检查GET _cluster/allocation/explain找出原因，通常是磁盘满或节点故障。
• 写入被拒绝：查看GET _nodes/stats/thread_pool，若rejected增加，调大队列或增加节点。
• 慢查询：开启慢日志index.search.slowlog.threshold.query.warn: 10s，通过_search?profile=true定位瓶颈。
• GC超时：检查JVM堆使用率，若持续>90%，需要增加堆或减少分片。

结语

ES集群部署不是配一个yml就能高枕无忧。本文所有配置和命令已经在生产环境验证，复制可跑。真实生产建议先压测再上线，根据自身数据量调整分片和刷新间隔。避坑指南里的10条，每一条都是我掏心窝的血泪教训。