ClickHouse v25.7.7.68-stable 版本更新解析：25.x LTS 稳定线关键修复与回移（Backport）全览

ClickHouse v25.7.7.68-stable 版本更新解析：25.x LTS 稳定线关键修复与回移（Backport）全览

【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse

本篇以 v25.7.7.68-stable 官方变更日志 为主体，系统梳理该 ClickHouse 25.x LTS 稳定版本相对 v25.7.6.21-stable 的全部回移修复：从 Keeper 协调层性能、Replicated Database 恢复、Delta Lake 引擎到 JSON/Dynamic 类型与子列（Subcolumn）语义修正。读完后，你将理解每个修复对应的故障场景与影响面，并能据此评估生产环境的升级收益。

1. 版本定位：25.x LTS 稳定线上的例行加固

该变更日志记录了 ClickHouse releasev25.7.7.68-stable（构建哈希 7e68b82051a），并明确给出对比基线：

ClickHouse release v25.7.7.68-stable (7e68b82051a) FIXME as compared to v25.7.6.21-stable (a81134c5c92)

这是 25.7 系列（25.x 长期支持线）的第 3 个稳定点版本。其核心特征可以从文档结构直接读出：

• 所有条目均以 “Backported in #xxxxx” 开头，即这些修复先在 master 主线完成，再回移到 25.7 LTS 分支；
• 条目分为四个类别：Improvement（改进）、Bug Fix（用户可见缺陷修复）、Build/Testing/Packaging Improvement（构建/测试/打包改进）、NO CL CATEGORY与NOT FOR CHANGELOG / INSIGNIFICANT（内部性变更）；
• 每条修复附带主线 PR 编号与提交者署名，便于追溯实现细节。

这类变更日志由 CI 发布流程自动生成（仓库中 版本号文件 的注释指明版本变量由ci/jobs/scripts/create_release.py自动维护）。需要说明：当前仓库检出的是 master 开发线（版本号 v26.9.1.1-testing），本文对 25.7 修复的源码印证均基于当前主干中仍保留的相关实现。

2. Keeper 协调层：性能优化与会话健壮性

本版本对内置协调服务（Keeper，兼容 ZooKeeper 协议）的修复最多，可分为三类。

2.1 RemoveRecursive 请求性能改进

Keeper 的递归删除（RemoveRecursive，语义上等价于 ZooKeeper 的deleteRecursive）此前需要逐节点遍历删除。本版本包含两条相关改进：

• Backported in #86825：Improve performance of RemoveRecursive request in Keeper（PR #86789，作者 Antonio Andelic）；
• Backported in #86680（内部条目）：Check feature flag when adding RemoveRecursive request to Multi（PR #86554）。

后者说明性能优化路径由 feature flag 控制，在 Multi 事务中追加 RemoveRecursive 请求时会先校验协商后的能力标志，保证旧客户端不受影响。在当前主干中，相关请求与存储逻辑可见于 KeeperStorageImpl.cpp、KeeperCommon.cpp 与 KeeperContext.cpp，删除类请求（remove / removeRecursive / multi 组装）均在此链路中实现。

这一改进的实际收益场景包括：大批量删除分布式 DDL 任务节点、KeeperMap数据清理、以及任何使用zookeeper_delete_tree风格的批处理作业。

2.2 S3Queue 与 Keeper 会话过期的逻辑错误修复

• Backported in #86872：Fix S3Queue logical error “Expected current processor {} to be equal to {}”，根因是 Keeper 会话过期（PR #86615）。
• Backported in #86861：修复在部分任务缺失某些 Keeper 节点时查询system.distributed_ddl_queue的问题（PR #86848）。

这两条对依赖 Keeper 的分布式工作负载（S3Queue 消费队列、SYSTEM分布式 DDL 队列）非常重要：它们属于“节点/会话状态不一致时抛出 LOGICAL_ERROR”一类问题，此前会直接使查询失败，修复后系统能在节点缺失时正确降级处理。

2.3 KeeperMap DROP 残留数据清理

• Backported in #87311：修复 25.1 之前创建的KeeperMap表在 DROP 后仍把数据留在 ZooKeeper 中的问题（PR #87112，作者 Nikolay Degterinsky）。

在当前主干中，KeeperMap引擎实现位于 StorageKeeperMap.cpp。该修复意味着：老版本建表、新/老版本执行 DROP，现在都能彻底清理事件数据，避免元数据目录无限膨胀。

2.4 Catalog 元数据损坏时的 SYSTEM DROP REPLICA

• Backported in #86732（Improvement 类）：修复对元数据损坏的 Catalog 执行SYSTEM DROP REPLICA时的错误（PR #86391，作者 Nikita Mikhaylov）。

这是典型的“故障恢复路径”加固：Catalog 元数据损坏本身是严重事故，而SYSTEM DROP REPLICA往往是运维者最后可用的恢复手段之一。修复后该命令在损坏场景下也能正确执行，降低了集群重建成本。

3. Replicated Database 与副本恢复安全性

• Backported in #86612：Shutdown tables properly when recovering database replica。不当的关闭方式会在数据库副本恢复（database replica recovery）期间导致部分表引擎抛出 LOGICAL_ERROR（PR #84744）。
• Backported in #86977：修复TimeSeries引擎表破坏 Replicated Database 中新副本创建的问题（PR #86845）。

Replicated Database 是 ClickHouse 元数据级复制的核心机制，其恢复流程（重启后拉取远端元数据、重建本地表）对引擎 shutdown 语义要求极高：各表引擎必须在恢复事务边界外被安全地 attach/detach。第一条修复正是把恢复路径中的表关闭流程改正确；第二条则修复了TimeSeries引擎在该流程中未正确响应元数据变更、导致新副本无法创建的缺陷。主干中 TimeSeries 引擎实现位于 StorageTimeSeries.h 及其 TimeSeries 子目录 下的 Sink/协议组件。

对生产含义：如果你的集群使用 Replicated Database（尤其是混有TimeSeries引擎表），升级到该版本可显著降低“副本起不来”“恢复期 LOGICAL_ERROR”两类故障概率。

4. Delta Lake 引擎与 delta-kernel-rs：崩溃与读取修复

本版本包含两条 Delta Lake 相关修复：

• Backported in #86520：Fix segfault in delta-kernel implementation（PR #85160，作者 Kseniia Sumarokova）——delta-kernel（Rust 实现的 Delta 协议内核）中的段错误，属于严重稳定性缺陷；
• Backported in #85255：修复DeltaLake引擎在禁用 delta-kernel 时读取分区数据的错误，该问题由 25.7 引入（PR #81136 引入、PR #85223 修复）。

第二条尤其值得注意：它表明在 25.7 中，DeltaLake引擎的默认读取路径切换到了 delta-kernel，而未启用 kernel 的旧路径在“分区数据”场景下回归。对于仍依赖 25.7 且显式禁用 delta-kernel 的用户，这是必读修复项。构建层面，delta-kernel 作为 Rust 依赖集成，其 CMake 封装位于 delta-kernel-rs-cmake，与仓库中大量xxx-cmake封装第三方库的模式一致。

5. JSON / Dynamic 类型与子列语义修复

本版本对JSON半结构化类型与子列（Subcolumn）语义的修复集中且密集，均由 Pavel Kruglov 提交，反映 25.x 中 JSON 类型快速迭代期间的稳定性收尾：

• Backported in #86199：修复 JSON 中带Enum提示（hint）的路径使用错误默认值的问题（PR #86065）；
• Backported in #86947：修复LowCardinality(Nullable(T))到Dynamic的 cast（PR #86365）；
• Backported in #86878：修复GROUP BY Nullable(JSON)（PR #86410）；
• Backported in #87057：修复 RowBinary 输入格式向 JSON 共享数据写入 NULL 的问题，并在ColumnObject中增加额外校验（PR #86812）。

此外是子列相关的 ALTER 语义收紧与修复：

• Backported in #86955：修复对“子列被其他列物化表达式引用”的列执行ALTER ... UPDATE时物化列更新不正确的缺陷（PR #85985）；
• Backported in #86693：禁止 ALTER 其子列被主键（PK）或分区表达式引用的列（PR #86005）。

这组修复共同指向一个主题：JSON 类型的子列在 25.x 中既是存储层优化（按路径物化），又引入了跨列依赖（物化表达式引用子列、PK/分区键引用子列）。此前 ALTER 与 cast 路径未完整处理这种依赖图，导致更新结果错误或非法结构变更。该版本把“子列依赖检查”补进了 DDL 校验逻辑，属于数据正确性层面的加固。

6. SQL 语义与执行计划修复

• Backported in #87157：仅在关联子查询引用外层查询列时，才允许其出现在 FROM 子句中；同时修复两个既有缺陷（PR #85966，作者 Dmitry Novik）。这是解析器层面的语义收紧，防止非法关联子查询产生歧义计划。
• Backported in #87191：修复uniqExact在ROLLUP/CUBE修饰符下可能产生错误结果的问题（PR #87014，作者 Nikita Taranov）——聚合函数与分组展开组合下的正确性缺陷，直接影响报表类查询。
• Backported in #87070：正确 cast 被拆分为多步执行的 PREWHERE 的输出（PR #87040）。PREWHERE 是列存引擎的预过滤优化，拆分执行时的类型转换必须与单步等价，否则过滤结果可能偏离预期。

7. IO、缓存与内存边界修复

• Backported in #86518：修复文件系统缓存动态扩缩容（dynamic resize）期间的逻辑错误（PR #86130）。
• Backported in #87054：修复在解压缩块末尾 seek 的问题（PR #86906）——涉及压缩 IO 层的边界位置处理。
• Backported in #87393：修复max_temporary_data_on_disk_size限额跟踪中临时数据释放量的错误记账（PR #87140）。此前错误的记账可能使限额在磁盘临时文件已被释放后仍被持续占用，误伤后续查询的临时空间申请。
• Backported in #87435：修复 JOIN 中常量块与非常量块混合导致分配器收到过大尺寸而抛出 “Too large size passed to allocator” LOGICAL_ERROR 的问题（PR #87231，作者 Azat Khuzhin）。

这四条都属于执行引擎边界条件类修复：单看描述抽象，但都对应“特定数据形态/并发状态下必然复现”的缺陷，对高负载生产环境有实际价值。

8. 服务端启动/停止与认证安全

• Backported in #86058：修复“使用no_password创建的用户，在服务器设置allow_no_password改为 0 后尝试登录导致服务端崩溃”的问题（PR #84426）。这是一个可被触发的崩溃路径（认证分支未处理该组合），修复后该场景下行为降级为正常的登录拒绝。
• Backported in #86580：在关闭过程中忽略日志 flush 阶段的异常，使 shutdown 更安全，避免 SIGSEGV（PR #86546）。
• Backported in #86891：修复启用send_chunk_header且 UDF 通过 HTTP 协议调用时缺失 chunk header 的问题（PR #86606）。
• Backported in #85652：修复 HTTP multipart 请求中date_time_input_format等参数被忽略的问题（PR #85570）。

前两条对“服务器干净停机”这一运维基本盘很有意义：日志系统自身的异常不应升级为进程段错误，这直接关系到重启窗口与故障排查期间的日志完整性。

9. 构建与打包改进：openldap 2.6.10

• Backported in #86806：Build/Testing/Packaging 类条目——使用 openldap 2.6.10（PR #86623，作者 Konstantin Bogdanov）。

LDAP 客户端库是 ClickHouse 认证与集成能力的组成部分，升级依赖版本通常伴随安全补丁。当前仓库中 openldap 的 CMake 封装位于 openldap-cmake，其 CMakeLists.txt 将源码目录指向contrib/openldap子模块，并针对不同平台维护了预编译二进制目录（linux_x86_64、darwin_aarch64等）。

10. 内部变更与不对外条目

变更日志还包含两条通常不影响用户行为、但体现工程质量管控的条目：

• NO CL CATEGORY：Backported in #86568（PR #86558），无描述，属于未归类变更；
• NOT FOR CHANGELOG / INSIGNIFICANT：Backported in #86680——即为 2.1 节提到的 RemoveRecursive feature flag 校验（PR #86554）。

这类条目与用户可见修复并列记录，保证回移清单的完整性：每一条主线 PR 都有对应的回移追踪编号，便于审计 LTS 分支与主线之间的差异收敛情况。

11. 升级评估与验证建议

综合本版本的 25 条变更，可给出如下升级决策参考（适用前提：你运行的是 25.7 LTS 线、或 25.x 中受同类缺陷影响的版本）：

1. 必须关注（稳定性/正确性直接风险）：
   • KeeperRemoveRecursive大批量删除作业的性能与 feature flag 兼容性；
   • no_password用户 +allow_no_password=0组合下的服务崩溃；
   • delta-kernel 段错误与 DeltaLake 禁用 kernel 时的分区读取；
   • uniqExact+ROLLUP/CUBE的错误结果；
   • Replicated Database 恢复期 LOGICAL_ERROR。
2. 建议关注（语义与 DDL 行为变化）：子列相关列的 ALTER 被新增限制（#86693），此前依赖“子列被 PK/分区表达式引用仍可 ALTER”的自动化脚本需要调整；FROM 子句关联子查询的解析收紧（#87157）可能使个别此前“碰巧能跑”的查询报语法/语义错误——这属于预期的正确性收紧。
3. 验证方式：升级后可在测试集群执行针对性回归——SYSTEM DROP REPLICA与副本恢复流程、KeeperMapDROP 后检查协调目录、Delta 表分区查询、uniqExact(... ) WITH ROLLUP抽样对比、Replicated Database 中新建TimeSeries表并加副本，均可直接对应本文各条修复。

12. 小结

v25.7.7.68-stable 是 25.x LTS 线一次覆盖面相当广的加固性发布：Keeper 协调层（递归删除性能、会话过期容错、元数据清理）、Replicated Database 恢复安全、Delta Lake/delta-kernel 崩溃修复、JSON 与子列语义收敛、执行引擎边界条件、服务启停与认证健壮性，以及 openldap 依赖升级。对于以 25.x 作为生产基线的用户，该版本的完整条目记录见 docs/changelogs/v25.7.7.68-stable.md，各修复在主干中的对应实现可沿本文给出的源码路径（如 src/Coordination、src/Storages/StorageKeeperMap.cpp、contrib/delta-kernel-rs-cmake）进一步深入。

【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse