Debian 11上Elasticsearch三节点集群搭建与性能调优实践-育师

上个月我把公司内部的全局搜索引擎从单机迁移到了三节点的Elasticsearch集群，服务器清一色用的Debian 11。折腾这件事的原因很直接：原来的单节点每天要扛几百万条增量数据，即便上了SSD，写入延迟和查询耗时的波动也越来越离谱，更头疼的是中文检索准确率——搜一个词，前排总是一堆相似但无关的结果。换到集群并做了一轮针对性优化之后，吞吐量上去了，搜索精度也明显改善。这篇文章就把从系统参数、集群配置，到吞吐量和精度专项调优的完整过程写出来，给那些准备在Debian 11上搭建Elasticsearch集群、并且真正追求性能的朋友当参考。

1. 动手之前的三个关键决策：版本、角色和系统参数

ES集群能不能跑得稳，动手前那半小时的规划比后面任何一步都重要。我见过太多人装完就发现节点起不来、集群一直yellow、或者跑几天就red，回头一查全是基本参数没设对。

1.1 ES版本选型：8.x还是7.x，这直接影响后续配置

很多教程还在用7.x，但新项目我建议直接用8.x系列，尤其是8.10以上的维护版本。我自己这次用的是8.11.3，到写这篇文章时已经比较稳定。8.x有两个变化会让新手困惑，但其实是好事：

默认开启xpack安全认证，节点间通信默认加密，elastic用户有随机密码。
自带捆绑JDK，不用在Debian 11上手动装Java，省掉一个最容易翻车的环节。

如果你确实熟悉7.x，用7.17也完全没问题，它是7.x最后一个大版本，面临的坑更少。但考虑长期演进，8.x是更省心的选择。有一点必须说明：ES版本迭代很快，不要追求最新，选一个已发布半年以上的维护版本，插件生态也更稳。比如ik中文分词插件，就要严格匹配ES版本号，版本对不上就只能干瞪眼。

1.2 节点规划：三台机器怎么分工才不浪费

生产环境至少三个节点，这是写入和HA的地基。我这次就是三台Debian 11，每台4核16G内存，系统装在HDD上，数据目录放到独立的SSD盘。

节点角色分配上，很多人一上来就想着搞专用master节点，但三节点规模根本没必要。我三个节点都是master + data + ingest：

角色	职责	三节点场景下的建议
master	维护集群状态、分配分片	三个节点都可选，避免单点
data	存数据、执行读写	三个节点都承担，充分利用磁盘
ingest	写入前数据管道处理	如果不用ingest pipeline可以不开
ml / transform	机器学习、数据转换	默认不开，用不到就删掉

等集群规模扩大到十几个节点，再考虑拆独立master和独立ingest节点不迟。小型集群强行拆角色，只会浪费机器，还让master节点闲着，数据节点反而压力大。

1.3 系统层参数：改错一个，集群可能连启动都过不去

ES对系统参数有自己的"洁癖"，Debian 11默认值里好几个都达不到要求。先把这些改了，否则启动直接报错，或者跑几天后诡异崩溃：

# 虚拟内存映射数，ES要求至少262144 sysctl -w vm.max_map_count=262144 echo 'vm.max_map_count=262144' >> /etc/sysctl.conf # 文件描述符限制，官方建议65535 ulimit -n 65535 echo '* soft nofile 65535' >> /etc/security/limits.conf echo '* hard nofile 65535' >> /etc/security/limits.conf # 关闭swap，或者尽量降低swap使用 swapoff -a # 同时注释掉/etc/fstab里的swap行，否则重启后swap又回来了 echo 'vm.swappiness=10' >> /etc/sysctl.conf sysctl -p

vm.max_map_count是最常见的启动杀手，如果你在日志里看到max virtual memory areas vm.max_map_count [65530] is too low，就是它没改。文件描述符不够的表现更隐蔽，可能数据量一大就报Too many open files。swap这个问题，很多人忽略，其实ES的JVM一旦被换出到swap，查询延迟立刻飙升，而且很难排查，看起来像随机抖动。

另外，如果Debian 11开着防火墙，记得放行9200和9300端口：

ufw allow 9200/tcp ufw allow 9300/tcp

9200是HTTP访问端口，9300是节点间transport通信端口，两个都要放行，少哪个集群都组不起来。

1.4 JVM堆内存：不是越大越好，30GB以内的讲究

ES的堆内存设置是门学问，原则是"物理内存的一半，且不超过30GB"。我的机器16G物理内存，堆就设8G；如果是64G的大机器，堆设到30G就够，剩下的留给系统文件缓存。

为什么不能贪？因为JVM在堆小于32GB时会启用压缩指针，对象引用更紧凑，GC效率高；一旦超过32GB，压缩指针关闭，内存占用变大但性能反而下降。ES重度依赖OS文件缓存来加速Lucene倒排索引的读取，你把堆撑爆，留给page cache的空间就少，等于自己拖慢查询。

修改方式是在/etc/elasticsearch/jvm.options.d/heap.options里写，不要直接改jvm.options主文件，方便升级时不被覆盖：

-Xms8g -Xmx8g

-Xms和-Xmx必须设成一样的值，防止运行中堆动态扩容和收缩引发抖动。改完之后启动ES，再确认一个事情——bootstrap.memory_lock是否生效。如果启用了内存锁，ES会把堆锁在内存里，杜绝被swap出去：

# elasticsearch.yml bootstrap.memory_lock: true

验证是否真的锁住：

curl -s http://localhost:9200/_nodes?filter_path=**.mlockall

返回的mlockall是true，说明JVM不会进swap。

2. 从零搭建三节点集群：配置文件逐项拆解

环境准备好了，接下来就是安装和配置。整个过程有耐心就不难，很多人栽在配置文件抄得不完整或版本理解错误。

2.1 用apt安装Elasticsearch，绕开JDK配置的坑

ES 8.x自带JDK，所以不用手动装Java。安装方式我推荐官方apt仓库，升级方便，而且自动帮你建好elasticsearch用户和systemd服务脚本。用tar包虽然灵活，但服务管理、开机自启、日志轮转全得自己搞，没必要。

三台服务器上都执行：

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" > /etc/apt/sources.list.d/elastic-8.x.list apt update apt install elasticsearch=8.11.3

如果不想锁定次要版本，直接apt install elasticsearch也行。装完先别急着启动，因为默认配置是单节点模式，直接启动后面还得改。配置文件在/etc/elasticsearch/elasticsearch.yml，改之前先备份：

cp /etc/elasticsearch/elasticsearch.yml /etc/elasticsearch/elasticsearch.yml.bak

2.2 elasticsearch.yml的关键配置与一次成型写法

三台节点配置大同小异，主要差异只有node.name。下面这个配置在三个节点上分别改node.name为node-1、node-2、node-3即可：

cluster.name: es-global-search node.name: node-1 node.roles: [ master, data, ingest ] path.data: /data/elasticsearch path.logs: /var/log/elasticsearch network.host: 0.0.0.0 http.port: 9200 transport.port: 9300 discovery.seed_hosts: - 192.168.1.11:9300 - 192.168.1.12:9300 - 192.168.1.13:9300 cluster.initial_master_nodes: - node-1 - node-2 - node-3 # 临时或内网环境可以关闭安全，生产建议开启，见2.3 xpack.security.enabled: false

几个关键项，经验之谈：

cluster.name必须一致，这是节点加入同一个集群的"身份证"。
network.host必须设置成0.0.0.0或具体内网IP，不能用127.0.0.1，否则其他节点连不上你。
discovery.seed_hosts是节点启动后用来发现其他成员的地址列表，写三个节点的transport端口。
cluster.initial_master_nodes只在集群第一次引导时使用，用于投票选出第一个master，这个参数如果漏了，集群会一直处于等待主节点状态，日志里反复刷master not discovered yet。
path.data我改成独立的/data/elasticsearch，不建议放系统盘，ES是IO密集应用，数据目录单独挂载SSD，后续扩容也方便。记得把目录属主改成elasticsearch：

mkdir -p /data/elasticsearch && chown -R elasticsearch:elasticsearch /data/elasticsearch

2.3 8.x安全问题：证书生成与关闭安全的取舍

8.x默认开启安全，直接启动后会自动生成证书和随机密码。这对纯内网测试环境是个障碍，但生产环境我强烈建议保留。

如果你决定内网临时关掉安全，在上述yml里显式写xpack.security.enabled: false即可。注意，8.x版本只写这一行还不够保险，建议同时注释掉或删掉安装时自动生成的其他安全相关配置。

如果开启安全，节点间传输需要证书。在三台节点里挑一台生成证书，然后分发：

/usr/share/elasticsearch/bin/elasticsearch-certutil ca --out /etc/elasticsearch/certs/elastic-stack-ca.p12 --pass "" /usr/share/elasticsearch/bin/elasticsearch-certutil cert --ca /etc/elasticsearch/certs/elastic-stack-ca.p12 --pass "" --out /etc/elasticsearch/certs/elastic-certificates.p12

把生成的elastic-certificates.p12复制到另外两台机器，设置权限：

chown root:elasticsearch /etc/elasticsearch/certs/*.p12 chmod 660 /etc/elasticsearch/certs/*.p12

然后在每个节点的yml里追加：

xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/certs/elastic-certificates.p12 xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/certs/elastic-certificates.p12

启动后设置elastic用户的密码：

/usr/share/elasticsearch/bin/elasticsearch-setup-passwords auto

2.4 启动三节点，验证集群是否真的"串"起来

三个节点配置都改好后，依次启动并观察日志：

systemctl start elasticsearch systemctl enable elasticsearch tail -f /var/log/elasticsearch/es-global-search.log

看到类似[node-1] started或new_master {node-1}{...}的日志，说明节点正常加入集群。然后访问健康接口：

curl -s http://192.168.1.11:9200/_cluster/health?pretty

如果一切正常，你会看到status为green，number_of_nodes为3。如果status是yellow，说明分片有副本没分配，通常是副本数大于数据节点总数，比如三节点但副本设了2，两个副本在同一节点上就可以，但如果是2节点集群副本1也有可能yellow。red才是最严重的，有主分片没起来。这三者的区别，后面第5章细说。

再确认节点列表：

curl -s http://192.168.1.11:9200/_cat/nodes?v

看到三行记录，node-1/node-2/node-3都在线，集群部分就完成了。

3. 吞吐量优化：从单条写入到批量导入的完整调优

集群跑起来，只是第一步。接下来是本文的重头戏之一——吞吐量。我这次迁移的第一天，用原来单机时代的写入代码怼上去，发现三节点集群的吞吐居然还不如单机，原因全在写入链路的用法上。

3.1 先看瓶颈：CPU高、IO高、GC高分别怎么处理

调优前一定要先定位瓶颈，不能瞎改配置。我一般同时看几个指标：

观察到的现象	常见原因	优先调整方向
写入时CPU被吃满，磁盘空闲	单个bulk太大、分词/索引开销过高、字段冗余	减小批次大小、增加并发、清理无用字段
磁盘util接近100%，CPU不高	磁盘IO能力不足、fsync或段合并太频繁	换SSD、调大translog.sync_interval、暂停刷新
GC时间占比超过5%	堆偏小或对象分配过快	提高堆到物理内存一半、降低bulk并发
write线程池出现rejected	写入请求超过节点承受力	调大队列、减少客户端并发、升级硬件

查看GC可以用JVM自带的命令：

jstat -gcutil $(pidof java) 1000

如果FGC那一列增长很快，说明full GC频繁，需要动堆或者检查是不是有大字段导致对象分配爆炸。

3.2 批量写入bulk的正确参数与客户端写法

ES单条document写入没有任何优势，每次请求都有HTTP开销、分片路由、返回确认，吞吐量很难看。我这次的性能翻身仗，第一刀就是全面改走_bulk批量接口。

但批量不是越大越好。我自己的经验是单批2000~5000条，或者压缩前5~15MB，二选一先到为准。批次太大反而会导致单个请求长时间占用线程池、GC压力剧增，吞吐下降还容易超时。

Python客户端我用elasticsearch.helpers.bulk，它会自动分批和重试：

from elasticsearch import Elasticsearch from elasticsearch.helpers import bulk es = Elasticsearch( ["http://192.168.1.11:9200", "http://192.168.1.12:9200", "http://192.168.1.13:9200"], basic_auth=("elastic", "你的密码"), request_timeout=120 ) def gen_actions(records): for doc in records: yield { "_index": "global_search_v1", "_id": doc["id"], "_source": doc, } bulk(es, gen_actions(reader), chunk_size=2000, max_retries=3, raise_on_error=False)

chunk_size我建议2000起步，再根据节点CPU和GC表现微调。写入失败不要直接抛异常，先打印错误样本分析，raise_on_error=False有助于识别哪些字段需要清洗。

如果用的是Java客户端，思路一样——用BulkRequest攒够一批再发，或者直接上批量异步监听回调，别一个for循环单条index。

3.3 刷新间隔、translog与副本数：速度和安全如何取舍

这是吞吐量调优里见效最猛的一组参数，但也是风险最高的一组。先说结论，再解释为什么。

大批量导入时，我通常把临时索引这样设置：

curl -X PUT "http://192.168.1.11:9200/global_search_v1/_settings" \ -H 'Content-Type: application/json' \ -d '{ "index": { "refresh_interval": "30s", "number_of_replicas": 0, "translog.durability": "async", "translog.sync_interval": "5s" } }'

这三个参数的意义：

refresh_interval默认1秒，意思是每秒生成一个新段。改成30秒，等于把写盘频次降下来，吞吐能涨一大截。代价是数据写入后最多30秒才能被搜到。
number_of_replicas设为0，写入时不用同步副本，吞吐提升非常明显。代价是这段时间如果节点宕机，这部分数据有丢失风险。
translog.durability默认request，每条写入都刷盘，改成async后，每隔5秒才刷一次批量的translog，IO负担大幅下降。代价是极端断电情况下可能丢几秒数据。

这套组合拳适合"先灌数、再上线"的场景，而不是在线业务直接改。更优雅的做法是：先写好临时索引，批量导入完成后，用reindex搬到正式索引，或者直接切别名。正式索引的副本数保持1，刷新间隔恢复默认或按业务需求调整。

3.4 段合并、强制合并与磁盘IO管理

Lucene的段是搜索的最小单位，段越多，查询时需要扫描的文件越多，吞吐越差。ES后台会自动合并段，但你也可以主动干预。

调低合并线程，避免和写入抢IO。机械硬盘建议：

index.merge.scheduler.max_thread_count: 1

SSD可以默认或设2~4。官方文档说这是按CPU数量自动调整的，但机械盘场景默认值经常过高，写入时会明显感觉IO被合并任务拖垮。

对只读的历史索引，可以执行强制合并：

curl -X POST "http://192.168.1.11:9200/global_search_v1/_forcemerge?max_num_segments=1"

强制合并会把所有小段合成一个大段，查询吞吐显著提升。但要注意：这个操作极其吃IO，而且如果是热索引还在写，会阻塞新写入。我一般只在每天凌晨低峰期对昨天的索引执行一次，或者对彻底冻结的历史索引执行。

分片数量也要一并考虑。三节点集群我建索引时一般设3个或6个分片，保证每个节点都有分片承担读写。每个分片的数据量控制在20~50G之间，太小浪费分片开销，太大则单分片查询压力过高。需要说明的是，分片数量在索引创建后不可调整，只能reindex，所以创建前就要想清楚。

4. 搜索精度优化：映射、分词与相关性三者缺一不可

搜索引擎领域的"精度"本质上就是Precision和Recall的平衡：既要把真正匹配用户意图的文档排在前面，又不能漏掉应有的结果。ES没有一键"提高精度"的按钮，精度是映射、分词、查询和评分规则共同决定的。我这次优化完，首屏点击率提升非常明显，下面拆开讲。

4.1 映射设计：text与keyword混用，一个字段解决两类需求

很多搜索不准的问题，根源是映射设计偷懒。最常见的就是把所有字段都交给dynamic mapping自动生成，结果数值被当成keyword，日期格式乱了，有些不该被全文检索的长文本也被索引，搜索时噪声一大堆。

在全局搜索引擎场景，我的建议是禁掉动态映射，显式定义字段。至少要区分好两类核心类型：

text：全文检索，会被分词，适合标题、正文、描述。
keyword：不分词，精确匹配、过滤、聚合、排序。

一个非常经典的组合是"标题同时需要模糊搜索和精确聚合"：

{ "mappings": { "properties": { "title": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "content": { "type": "text" }, "author": { "type": "keyword" }, "publish_date": { "type": "date" }, "status": { "type": "keyword" } }, "dynamic": "false" } }

这样搜索引擎里可以用title做全文检索，用title.keyword做精确匹配或聚合，一个字段当两个用。不需要被搜索的字段，比如内部标记、大段日志原文，直接不索引或设置"index": false，既减少索引体积，也提升写入吞吐。

dynamic: false的意思是，写入时遇到映射里没定义的字段，会忽略但不会报错。这能避免脏数据把索引搞乱。如果希望严格拒绝未知字段，可以用dynamic: "strict"，但业务变动频繁时不建议，容易把写入搞挂。

4.2 中文分词器选型：ik_max_word与ik_smart的分工

中文搜索精度最大变量就在分词器。ES自带的standard分词器按单个汉字切分，搜"华为手机"会拆成"华""为""手""机"，返回的结果里大量只有"华"或"机"的文档排在前面，精度一塌糊涂。

我用的是analysis-ik中文分词插件，安装前确认和ES版本匹配：

/usr/share/elasticsearch/bin/elasticsearch-plugin install \ https://github.com/infinilabs/analysis-ik/releases/download/v8.11.3/elasticsearch-analysis-ik-8.11.3.zip

装完重启ES。接着创建索引时，指定analyzer和search_analyzer：

{ "mappings": { "properties": { "title": { "type": "text", "analyzer": "ik_max_word", "search_analyzer": "ik_smart" } } } }

这里有个很容易被忽视的细节：ik_max_word和ik_smart的职责不同。索引时用ik_max_word，因为它把句子切到最细粒度，覆盖到各种可能的词；搜索时用ik_smart，它偏向长词优先，减少噪音。比如"中华人民共和国"，ik_max_word会切成"中华人民共和国/中华人民/中华/华人/人民/共和国"等多个词，ik_smart更倾向于切成"中华人民共和国"这种完整词。索引时多想一层、搜索时少放噪声，精度自然上来。

用_analyze接口可以验证分词效果：

curl -X POST "http://192.168.1.11:9200/_analyze?pretty" \ -H 'Content-Type: application/json' \ -d '{"analyzer": "ik_max_word", "text": "全局搜索引擎"}'

另外，业务专有词一定要加自定义词典。我遇到过搜"全局搜索引擎"时"搜索引擎"被分开，导致召回不足。ik支持自定义词典，修改/etc/elasticsearch/analysis-ik/IKAnalyzer.cfg.xml，把词加进ext_dict，比如：

全局搜索引擎 搜索引擎 搜狗输入法

4.3 BM25参数调优：词频饱和度和文档长度惩罚怎么调

ES默认的相关性算法是BM25，涉及两个关键参数：

k1控制词频饱和度，默认1.2。词频越高，评分涨得越快，但超过一定阈值后增益递减。如果发现重复关键词的垃圾文档排名过高，可以把k1调小到0.8~1.0。
b控制文档长度惩罚，默认0.75。值越大，长文档被惩罚得越狠。搜索场景里，商品描述或新闻正文经常很长，如果只有标题和正文两个字段混合检索，调小b到0.5~0.6，能让关键信息密度高的短文档更容易排前面。

修改方法，注意只能在创建索引时设置或离线关闭索引后设置：

{ "settings": { "index": { "similarity": { "default": { "type": "BM25", "k1": 1.0, "b": 0.6 } } } } }

数值没有黄金标准，要结合业务反复试。我的做法是拉一批真实用户搜过的词，建立一个小型评估集，每次调参后用评估集跑一遍，对比Top10结果的人工满意度，再决定要不要上线。

4.4 查询改写：bool、boost、filter与深分页的实战编排

映射和分词是搜索引擎的"底子"，查询写法是"临门一脚"。我见过很多团队映射做得好，但查询就一个裸match，精度照样不行。

优先用bool查询组合条件和权重：

{ "query": { "bool": { "must": [ { "match": { "title": { "query": "华为手机", "operator": "and" } } } ], "should": [ { "match": { "content": { "query": "华为手机", "boost": 0.5 } } } ], "filter": [ { "term": { "status": "published" } }, { "range": { "publish_date": { "gte": "2024-01-01" } } } ] } } }

几个关键点：

operator: "and"意味着所有词都必须命中，精度高，但召回会低；如果觉得太严格，可以换成minimum_should_match: "80%"，允许少量词缺失，这是精度和召回的折中。
标题命中应该比正文命中更重要，用boost调权重。但boost不要大到离谱，3倍以内通常足够。
精确筛选条件比如状态、时间范围，放到filter里，不要放must。filter不参与评分、可以走缓存，既提升精度也提升吞吐。

如果搜索结果排序还觉得不满意，可以用function_score加入业务因子。比如让点击量高、发布时间近的结果适当靠前：

{ "query": { "function_score": { "query": { "bool": { "must": [...] } }, "functions": [ { "field_value_factor": { "field": "click_count", "factor": 0.1, "modifier": "log1p" } }, { "gauss": { "publish_date": { "origin": "now", "scale": "30d" } } } ], "boost_mode": "sum", "score_mode": "avg" } } }

boost_mode: sum是加和而不是乘，这样业务因子只是轻微修正相关性评分，不会把本来最相关的文档挤出首页。这一点很多人调反了，默认的multiply会把业务因子放大到覆盖BM25，最后结果反而怪。

同义词在全局搜索引擎里也值得做。比如用户搜"电脑"，你希望也能搜到"计算机""PC"。在ik同义词词典里配好映射，搜索精度和召回都能提升。中文同义词的粒度根据业务来，别铺太开。

最后提醒一个影响查询吞吐的大坑：深分页。全局搜索引擎的循环翻页需求很少，但一旦出现，from: 10000这种写法会瞬间拖垮集群，因为ES需要从每个分片都取from+size条再聚合。解决方案是search_after或scroll。深度翻页用前者，全量导出用后者。

5. 集群上线后必然遇到的监控和排障经验

集群搭好、性能调完不代表结束，运行期的监控和排障才是常态。我这次上线后一个月内踩了好几个坑，有的是磁盘水印，有的是分片未分配，都总结在这一章。

5.1 一眼看穿集群状态的几条常用命令

我习惯把这几条命令设成脚本，随时看：

# 集群健康 curl -s "http://192.168.1.11:9200/_cluster/health?pretty" # 各分片分配情况 curl -s "http://192.168.1.11:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason" # 节点资源和堆使用 curl -s "http://192.168.1.11:9200/_cat/nodes?v&h=name,heap.percent,ram.percent,cpu,load_1m,disk.used_percent" # 线程池写入拒绝情况 curl -s "http://192.168.1.11:9200/_cat/thread_pool/write?v&h=node_name,active,queue,rejected"

_cat/thread_pool/write的rejected如果持续大于0，说明写入端已经开始丢请求了，这是吞吐瓶颈最直接的红灯信号。disk.used_percent超过85%后ES会拒绝写入新索引，超过95%可能直接让分片只读，后面细说。

5.2 慢查询日志怎么开启、怎么读

搜索慢不一定等于集群有问题，也可能是某个查询写得烂。开启慢查询日志能精确抓住这类"问题查询"：

curl -X PUT "http://192.168.1.11:9200/global_search_v1/_settings" \ -H 'Content-Type: application/json' \ -d '{ "index.search.slowlog.threshold.query.warn": "5s", "index.search.slowlog.threshold.query.info": "2s", "index.search.slowlog.threshold.fetch.warn": "2s", "index.search.slowlog.threshold.took.warn": "2s" }'

查询执行完，日志会打到/var/log/elasticsearch/下的index_search_slowlog.json文件里。里面会记录具体的查询语句、执行时间、命中的分片信息。我排查慢查询的经验：先看是query阶段慢还是fetch阶段慢。query慢通常是过滤条件没走filter缓存、或者wildcard查询太多；fetch慢通常是返回字段太大、深分页拉取太多文档。

5.3 磁盘水印导致只读和red分片的恢复流程

这是最容易让人慌的一个坑。某天系统突然不能写入了，日志里看到blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]，第一反应以为是权限问题，其实多半是磁盘水印触发了。

ES默认磁盘使用率超过85%时，会禁止分配新分片；超过95%时，会把相关索引置为只读。这时候应该先确认磁盘：

df -h

最彻底的办法是加磁盘或清理数据。如果只是暂时想恢复写入，可以临时调大水印并重置只读状态：

curl -X PUT "http://192.168.1.11:9200/_cluster/settings" \ -H 'Content-Type: application/json' \ -d '{ "persistent": { "cluster.routing.allocation.disk.watermark.low": "90%", "cluster.routing.allocation.disk.watermark.high": "95%", "cluster.routing.allocation.disk.watermark.flood_stage": "98%" } }' curl -X PUT "http://192.168.1.11:9200/global_search_v1/_settings" \ -H 'Content-Type: application/json' \ -d '{"index.blocks.read_only_allow_delete": null}'

这只是应急，水印调高意味着ES可能把分片分配到空间不足的节点上，长期有风险。正确姿势是快速清理数据或加节点。

red分片恢复流程，我一般这样：

# 先看哪几个分片是未分配 curl -s "http://192.168.1.11:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason" | grep UNASSIGNED

如果unassigned.reason是ALLOCATION_FAILED或NODE_LEFT，先确认其他节点空间足够，再重试分配：

curl -X POST "http://192.168.1.11:9200/_cluster/reroute?retry_failed=true"

等待一会儿再查，如果还是red，多半是磁盘或者分片数据损坏了，需要从快照恢复或者reindex备份数据。

5.4 几个"反直觉"的运维建议

有些经验不看监控根本想不到，我列几个自己踩过之后才理解的：

不要轻易调整indices.query.bool.max_clause_count。很多报错"too many clauses"不是ES配置问题，而是应用层把一个查询塞进了几百个should子句。调整配置只是掩盖了病根，真正该做的是优化查询逻辑，比如改成terms查询或拆成多次请求。
不要让bootstrap.memory_lock: false裸奔。不锁内存，JVM堆被swap只是时间问题，表现是延迟偶发飙到秒级。开了之后如果启动报Unable to lock JVM Memory，一般是LimitMEMLOCK没设好，把systemd服务文件里的LimitMEMLOCK=infinity打开。
索引生命周期要趁早规划。每天一滚的索引还是按月一滚，取决于查询模式。全局搜索引擎如果只查近三个月数据，老索引可以冻结或者定期关闭，节省堆内存和磁盘IO。
如果业务能接受几秒的缓存延迟，在ES前面加一层Redis缓存，把热门查询结果挡住，能省出大量CPU给写入实时查询。我这次优化后，缓存命中率大约35%，集群峰值负载直接降了一个档次。

我个人实测调优后的数据供参考：三节点Debian 11集群，单节点4核16G，日常写入从原来的每秒几百条提升到稳定每秒8000条以上，大批量灌数时能到每秒2万条左右；搜索接口P99从迁移前的480ms降到120ms以内，中文检索Top10结果的人工满意度也明显提升。这套方案不是银弹，每个集群的瓶颈点都不一样，但如果你也是"Debian 11 + Elasticsearch集群 + 全局搜索引擎"的组合，先把系统参数、批量写入、映射分词和查询结构这几块打牢，吞吐量和精度都不会差。