集群扩容：
集群扩容需求背景：
- 存储容量瓶颈：集群磁盘使用率超过 50% 时需启动扩容评估，超过 75% 时必须立即扩容，避免触发磁盘水位保护机制导致写入异常。
- CPU 与系统负载过高：节点 CPU 使用率长期居高不下、系统 Load 持续高于核数，导致查询与写入响应延迟显著增加。
- 内存资源不足：节点整体内存占用过高，包括 JVM Heap 内存和文件系统缓存（Filesystem Cache）不足，引发频繁 GC、查询性能下降。
- IO 与网络瓶颈：集群出现节点级 IO、机架级 IO 或网络 IO 瓶颈，影响分片迁移、数据同步和业务读写性能。
- 版本性能与功能升级需求：旧版本存在性能局限，新版本（如 ES 7.7+ 引入 off-heap 内存优化、ES 7.13.x 新增 Frozen Tier 冷数据层）有显著性能提升和新特性支持，需通过扩容适配新架构。
集群扩容方案：
横向扩容：
- 增加更多的节点，具体方式参照：文章一：深度掌握Elasticsearch集群组建和集群设置_es组建-CSDN博客
- 增加更多的副本，变相增加数据的并行查询能力
纵向扩容：
- 增加垂直硬件的吞吐能力
- 提升硬件性能提升最明显
程序内核升级:
新的版本的ES的性能一定是优于老版本的，可以采用升级内核的方式解决问题。这也是一种变相扩容的方式。
集群扩容总体方案：
- 集群规模可以：10~20 20~40 40~60.60~80.但是不建议扩充超过100节点的集群，
- 如果超过的话可以使用CCS这种方式解决问题，对于数据的同步可以使用CCR。
集群横向扩容实战：
- 禁用集群自动平衡，因为我们添加新的节点时，他会自动的将分片进行平衡，但是如果我们的节点启动失败，就会造成问题。还有就是假设我们增加多个节点的话，每个节点的加入都会让他进行一次资源的平衡，这个也占用es的资源。
PUT _cluster/settings
{
"persistent": {
"cluster": {
"routing": {
"rebalance.enable":"none"
}
}
}
}
参数含义：让 Elasticsearch 自动把分片均匀分配到所有节点上，不让某个节点压力太大。- 新增节点全部部署之后，重新开启
es集群挂载多个磁盘：
让同一个 ES 节点 同时使用多块本地磁盘（像 Windows C 盘、D 盘一样），提升容量、IO，且一块盘坏了只影响部分数据，不整节点崩溃。
编辑配置文件
# 数据存储路径（多个磁盘/目录）
path.data:
- /data1/es-data
- /data2/es-data
- /data3/es-data
# 其他必须配置
cluster.name: es-cluster
node.name: node-1
network.host: 0.0.0.0授权目录
mkdir -p /data1/es-data /data2/es-data /data3/es-data
chown -R elastic:elastic /data1 /data2 /data3重启es
./bin/elasticsearch -d集群缩容：
ES 缩容不是直接关节点！ 直接关节点 = 数据丢失 / 集群变红 / 业务崩溃。正确缩容 = 先把数据挪走 → 再下线节点 → 最后删除。
java
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.exclude._ip": "要下线的节点IP"
}
}
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.exclude._host": "主机名"
}
}
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.exclude._name": "节点名称"
}
}之后等待当前节点上所有的分片都迁移完成。迁移完成之后在执行关闭节点操作
取消exclude:
java
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.exclude._ip": null
}
}
##其他的配置也同样索引升级实战
下面的案例使用滚动升级的案例，将已有版本进行升级：
升级 Elasticsearch |弹性安装与升级指南 8.19 |弹性 这个是滚动升级的官网。按着官网操作就可以了。
集群降级
集群升级之后不可以进行降级操作，只能是通过原始的方式，reindex这种方式。