ES 的 Transform 通知索引兼容别名不再自动创建了

7.x 到 8.x 迁移时，.data-frame-notifications-1 这个 Transform 通知索引被 .transform-notifications-000002 取代。为了兼容，会在旧索引上建别名让读操作还能读到历史数据。9.0 起这个别名不再自动创建——已有集群保留，新建集群没有。

说明

来源和边界先交代：本文的依据出自 v9.4.2 标签下的官方文件（9.0.0.yml、Transform.java），文中引用的原文均来自这些文件。我没有启动集群、也没有跑测试，示例取自官方示例；哪些是文档写明、哪些是我的推断，正文里逐处标注。

图 1：官方文件 9.0.0.yml（v9.4.2 标签）。来源：GitHub elastic/elasticsearch v9.4.2 9.0.0.yml

官方条目

9.0 的 changelog 标为 deprecation（9.0.0.yml 第 670–680 行 @ v9.4.2），PR 117583，area: Machine Learning。

details 讲了一段完整的迁移史：

As part of the migration from 7.x to 8.x, the .data-frame-notifications-1 index was deprecated and replaced with the .transform-notifications-000002 index. The index is no longer created by default, all writes are directed to the new index, and any clusters with the deprecated index will have an alias created to ensure that reads are still retrieving data that was written to the index before the migration to 8.x. This change removes the alias from the deprecated index in 9.x. Any clusters with the alias present will retain it, but it will not be created on new clusters.

impact 一句：

No known end user impact.

图 2：官方文件 Transform.java（v9.4.2 标签）。来源：GitHub elastic/elasticsearch v9.4.2 Transform.java

把这段历史拆开

官方 details 信息量不小，按时间线重排一下：

第一步（7.x → 8.x 迁移时）：

• 旧索引 .data-frame-notifications-1 被弃用；
• 新索引 .transform-notifications-000002 取代它；
• 写入全部指向新索引；
• 但旧索引里还有迁移前写的数据——为了能读到，在旧索引上建一个别名。

第二步（9.0 本次改动）：

• 别名不再自动创建；
• 已有别名的集群保留（不会被删）；
• 新建的集群不再有这个别名。

这个别名解决什么问题

值得说清楚，因为它是理解"为什么现在能删"的关键。

迁移过程中有个典型难题：数据在两个地方。

• 迁移前写的数据 → 在旧索引里；
• 迁移后写的数据 → 在新索引里。

读的时候要两边都读才能拿到完整历史。别名的做法就是：让一个名字同时指向两个索引，读操作用这个名字就自动覆盖了两边。

代价是：这个兼容状态要一直维护——每次读都要查两个索引，而且新集群也得保留这套逻辑（哪怕它们根本没有旧索引）。

什么时候可以去掉：当旧数据不再需要、或者已经被合并到新索引时。到 9.0，距离 8.x 已经隔了一个大版本——官方判断这个兼容层可以收掉了。

从维护者的角度看这个决定很合理：一个为了兼容 7.x 而存在的逻辑，在 9.x 里还要为所有新集群保留，成本是持续的。而收益只对极少数还有旧索引的集群存在。收掉它是把成本从"所有人的常态开销"变回"极少数人的特殊情况"。

图 3：官方页面 PR #117583。来源：GitHub elastic/elasticsearch pull/117583

为什么"没有已知影响"

官方说没有已知影响，逻辑和 单数据节点水位线开关移除 里分析过的那条一样：

• 别名只在旧索引存在时才需要；
• 而旧索引是 7.x 时代的产物——能升到 9.0 的集群，要么早就没有这个索引了，要么已经处理过；
• 已经存在的别名不会被删除，所以存量集群的读取行为不变。

三条合起来：没有集群会因为这次改动而读不到东西。

这个推理是完整的。不过和上次一样，把推理过程写出来——impact 说"没影响"时自己确认一遍前提，是读 breaking/deprecation 时的好习惯。

源码里能看到什么

Transform 模块的代码里保留着这几个索引模板名的处理（Transform.java @ v9.4.2，第 436–438 行）：

templates.remove(".data-frame-notifications-1");
templates.remove(".transform-notifications-000001");
templates.remove(".transform-notifications-000002");

三个索引名都在：

• .data-frame-notifications-1——7.x 的；
• .transform-notifications-000001——8.x 早期的一版；
• .transform-notifications-000002——8.x 之后的。

能看到这个通知索引换了三代名字：7.x 的 .data-frame-notifications-1、8.x 早期的 .transform-notifications-000001、之后的 .transform-notifications-000002。这也解释了为什么需要兼容层——改名改了不止一次，每次都要照顾上一代的数据。

三代名字还说明一件事：以 . 开头的内部索引，其命名和结构都不保证稳定。这对使用者是个提醒，正文后面会再提。

（说明：这段代码上下文未完整看，不清楚 templates.remove(...) 是在做什么具体操作——是清理旧模板、还是排除它们。不确定，所以不做进一步推断。）

谁需要关心

按判断，绝大多数人不用管。理由是：

• 不用 Transform → 完全无关；
• 用 Transform 但集群是 8.x 之后建的 → 根本没用过旧索引，无关；
• 8.x 之前建的集群 → 别名已经存在且会保留，读取行为不变。

唯一需要处理的情况：你自己写了代码直接读那个旧索引名（.data-frame-notifications-1），而不是通过别名或新索引名。这种情况下——

• 存量集群：别名还在，能读；
• 新建集群：没有别名，读不到。

不过这种写法本来就少见（谁会直接读一个内部索引的旧名字呢）。真正可能受影响的是自己开发了 Transform 监控面板、且硬编码了索引名的团队——但这属于极少数。

这里说一条通用的做法：我的建议是不要直接读 ES 的内部索引。它们的前缀（.）就表示内部用途，名字和结构都可能随版本变化。要拿数据就走官方 API 或者 Kibana。这条建议不限于本例。

通知索引是干什么的

既然说到 Transform 的通知索引，把它是什么讲清楚——不然"读不到通知数据"这句话没有分量。

Transform 是 ES 的数据转换功能：把源索引的数据按配置做聚合（pivot）或者最新值（latest）处理，写到目标索引。常用于把原始明细预聚合成分析用的宽表。

通知索引（notifications index）记录的则是 Transform 任务运行过程中的异常信息——比如某次运行失败了、某个文档处理出错了。它相当于 Transform 的运行日志/错误记录。

所以它的实际用途是：

• 排查"为什么这个 transform 没跑出预期结果"；
• 查看历史上有哪些处理失败的文档。

这是运维排查用的数据，不是业务数据。这也解释了为什么官方判断"没有已知影响"——很少有人直接读它，多数情况是通过 Kibana 的 Transform 界面查看（那个界面会读新索引）。

旧索引还有数据时还能不能读到

想确认"旧索引还有数据时，9.0 之后读操作还能不能读到"。

按 details 的说法：别名的目的是"确保读操作仍能取到迁移前写的数据"。9.0 起不自动创建别名，那么——

• 如果集群里既有旧索引又有别名（存量情况）→ 能读到；
• 如果集群里有旧索引但没别名（理论上可能吗？）→ 读不到。

第二种情况是否存在，不确定。按官方说法，只要有旧索引就会建别名，所以理论上不该出现"有索引没别名"的状态。但如果有集群因为某些原因没建成别名，那 9.0 之后读旧数据就会有问题。

这个边界无法确认。如果你依赖读取 Transform 的历史通知数据，建议直接查一下那个索引是否还能访问。

和别的"兼容层收口"放一起看

这是 9.x 里写过的第三条同类改动，模式已经很清楚了：

三者的共同节奏：

1. 上一代迁移时留一个兼容层；
2. 隔一个主版本后收掉；
3. 存量保留、增量不再创建——这次的"已有集群保留，新建集群没有"就是这个模式的标准表述。

第 3 点特别值得记：这是 ES 处理兼容性的一贯做法——不破坏存量，只改变新增。理解这一点，就能对这类改动的影响有准确预期：现有环境不会突然坏掉，但新环境的默认形态变了。

这个原则的实际价值在于判断 urgency：这类改动几乎从不需要紧急处理，因为存量是安全的。它属于"知道就行、按计划更新"那一类，而不是"必须在本轮升级中解决"。把这类条目和真正会破坏存量的 breaking 区分开，能显著减少升级时的无谓紧张。

区分方法也简单：看 changelog 里有没有"已有…保留"这类表述。有就是安全的兼容层收口，没有就要认真评估。

怎么确认自己的集群是哪种情况

如果想实际确认一下，可以这么查：

# 看有没有旧的通知索引
curl -s 'localhost:9200/_cat/indices/.data-frame-notifications-1?v'

# 看有没有新的
curl -s 'localhost:9200/_cat/indices/.transform-notifications-000002?v'

# 看别名情况
curl -s 'localhost:9200/_alias/.transform-notifications-read?pretty'

（说明：最后那个别名名字是按命名习惯猜的，具体别名名未核实。更可靠的办法是查索引自己的别名信息。）

几条命令的结果组合起来判断：

• 只有新索引 → 正常，本次改动和你无关；
• 新旧都有 → 检查旧索引上有没有别名（有的话读取正常）；
• 只有旧索引 → 这种情况值得留意，说明迁移可能没走完。

第一种居多。8.x 之后建的集群根本没经历过那次迁移，自然也没有旧索引。

写在最后

这条 deprecation 影响极小——官方说没有已知影响，这个判断成立（推理见上）。

我的判断是：这条值得写是因为它示范了"兼容层收口"的标准模式：

存量保留，增量不再创建。

这个模式在 ES 的版本演进里反复出现。看到它就能立刻判断影响范围——现有环境安全，但要按新形态规划。

一，绝大多数人不用处理。 存量集群的别名会保留，读取行为不变。这条属于"知道就行"，不需要排进本轮升级的必做清单。

二，"存量保留、增量不再创建"是 ES 收兼容层的标准方式。 看到类似表述就知道：不会破坏现有环境，但新建的东西要按新形态来。这也是判断紧急程度的信号——这类改动几乎从不需要紧急处理。

参考

• changelog 9.0.0：Removing index alias creation for deprecated transforms notification index（第 670–680 行）@ v9.4.2
• Transform.java：三代通知索引模板名的处理（第 436–438 行）@ v9.4.2
• PR 117583

本文对照 Elasticsearch v9.4.2 标签的 changelog 与源码核对，引文与代码逐字取自原文。templates.remove(...) 所在代码段的完整上下文未查看，其具体操作目的本文不做推断；"有旧索引但无别名的集群是否存在"这一边界未确认，已在正文标注。撰写时未启动集群、未运行测试。