Elasticsearch Alias 与 Reindex 怎么配合：不停机重建索引更稳的做法

Elasticsearch 很多结构问题，最后都绕不过一件事：

• 重建索引

因为 mapping 一旦定下去，很多改动并不能直接在线修。

先说结论

更稳妥的索引升级方式通常是：

1. 新建目标索引
2. 用 reindex 或双写把数据迁过去
3. 用 alias 做流量切换
4. 验证后再清理旧索引

不要在生产里直接把索引当成“可以随便在线改结构的表”。

一、为什么 alias 很重要

因为 alias 本质上是在做：

• 稳定入口

业务方访问的是 alias，不是写死的物理索引名。

这样一来，后面无论你：

• 重建索引
• 迁移数据
• 变更模板

业务入口都不用跟着频繁改。

二、什么时候必须考虑 reindex

常见场景包括：

• 字段类型设计不合理
• 动态字段失控
• 旧索引结构过脏
• 需要调整分片和 mapping 模型

这类问题如果继续在旧索引上缝缝补补，后面成本会越来越高。

三、为什么“直接删了重建”很危险

因为生产里往往同时存在：

• 历史数据
• 在线写入
• 正在运行的查询

如果直接删索引重建，很容易带来：

• 数据中断
• 查询报错
• 写入丢失窗口

四、一个更稳妥的迁移顺序

1. 先建好新索引

把模板、mapping、分片策略一次定清楚。

2. 迁历史数据

先确认：

• 数据量多大
• 是否需要限速
• 是否会影响线上集群

3. 处理迁移期间的新写入

很多问题就出在这一段。

如果迁历史时线上还在写，就要明确：

• 是双写
• 是短暂停写
• 还是最终做增量补齐

4. alias 切换

切换前要验证：

• 数据量
• 查询结果
• 写入路径

五、最容易踩的坑

1. alias 只用于查，不用于写

这样后面写路径改起来还是很痛苦。

2. reindex 前不评估集群压力

历史数据量大时，很容易把线上写入和查询一起拖慢。

3. 切换时没有回滚方案

更稳妥的做法是：

• 保留旧索引一段时间
• 明确能快速切回

一句话总结

Elasticsearch 做索引升级时，真正稳妥的关键不是 reindex 命令本身，而是把：

• 新索引准备
• 数据迁移
• alias 切换
• 回滚预案

这一整套链路设计好。