
ClickHouse v25.6.6.29-stable 版本更新详解25.6 稳定线关键缺陷修复与回移清单【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本文以 ClickHouse 官方 2025 年 Changelog 中的 v25.6.6.29-stable 发布记录为主体逐条解析该版本相对 v25.6.5.41-stable 回移的全部改进Improvement与缺陷修复Bug Fix。读完本文后你将能够准确判断这一补丁版本修复了哪些查询正确性、Keeper 日志一致性、数据湖写入与稳定性问题并评估是否需要在生产环境中升级到该版本。一、版本定位这是一次怎样的发布根据 v25.6.6.29-stable 发布记录该版本对应提交63e6c7573e5是相对于上一个 25.6 稳定版v25.6.5.41-stable提交533d68057fc的差异发布全部条目均为从主干master回移Backported到 25.6 维护分支的变更。发布记录按官方惯例分为四个类别Improvement对用户可见的改进Bug Fix官方稳定版中出现过的、用户可见的错误行为修复NO CL ENTRY对已有改动的回退或内部修正不单独成文NOT FOR CHANGELOG / INSIGNIFICANT不影响用户行为的杂项变更本次仅一项测试超时修复。这类“全回移、无新功能”的版本是典型的小版本维护发布核心目标是把主干上已验证的缺陷修复带到 25.6 维护线上适合在低风险前提下滚动升级。二、改进项Improvement逐条解析2.1 PostgreSQL 元数据库同步修复与上游行为不一致的问题第一条改进PR #83298作者 Konstantin Vedernikov对应 issue #81156、#83324涉及 ClickHouse 将 PostgreSQL 作为外部元数据源的场景。Changelog 原文指出该修复对齐了 PostgreSQL 自身的同类“feature”并引用了 src/Databases/PostgreSQL 目录下DatabasePostgreSQL.cpp的实现位置。从源码结构看ClickHouse 的system.databases元数据同步逻辑位于该目录中当通过postgresql()引擎或engine PostgreSQL的数据库定义读取外部表结构时此前某些元数据字段的处理与 PostgreSQL 原生行为不一致本条目即修复该不一致属于外部库对接场景的兼容性改进。如果你的集群依赖 PostgreSQL 元数据库做跨引擎联合查询升级到本版本可消除相关边界差异。2.2 S3Queue 有序模式shutdown 调用后更早退出第二条改进PR #84463作者 Kseniia Sumarokova对应 issue #84597修复了S3Queue存储引擎在ordered有序处理模式下的停机时序问题当shutdown()被调用时处理循环应更早退出避免停机窗口内继续拉取/处理对象存储中的文件。该行为的源码落点可以从 ObjectStorageQueueMetadata.h 中的设计注释得到印证——该文件明确区分了 ordered 与 unordered 两种队列处理模式并说明有序模式下文件元数据的追踪与有序列举ordered S3 listing策略不同。修复“shutdown 后更快退出”保证了 DROP TABLE 或实例停止时的语义确定性有序队列不再可能因残留的 in-flight 处理任务而拖延关闭。三、缺陷修复Bug Fix按子系统逐条解析本版本共回移 9 个 Bug Fix下面按子系统归类逐条给出影响面与源码落点。3.1 存储与数据正确性Dynamic 列解析失败时的回滚修复PR #82169issue #84395修复 Dynamic 列ColumnDynamic在数据解析失败时未能正确回滚的问题。ClickHouse 的 Dynamic 列实现位于 ColumnDynamic.h该类继承自COWHelperIColumnHelperColumnDynamic, ColumnDynamic内部维护“已定型类型 待解析原始数据”的混合结构。当一行数据按已有类型解析失败、需要回退到原始值重解析时此前可能存在状态未完全还原的窗口导致同一列内的类型一致性被破坏。该修复保证了 Dynamic 列在解析失败路径上的回滚完整性对使用 Dynamic 列写入半结构化数据的用户直接影响写入正确性。Keeper changelog修复乱序写入导致的可能数据丢失PR #84434issue #84652这是本版本中严重级别最高的修复之一。官方说明为修复 Keeper changelog 的乱序写入问题——此前可能存在指向 changelog 的 in-flight 写入而 rollback 可能并发地改变目标文件从而产生不一致的日志甚至造成数据丢失。Changelog 是 KeeperClickHouse 内置的 ZooKeeper 协议兼容组件持久化的核心结构其实现位于 Changelog.h其中定义了ChangelogVersion枚举第 58 行附近、ChangelogWriter前向声明第 191 行附近与Changelog主类第 564 行附近负责将状态机日志分段写入带版本号的文件。当 rollback 与 in-flight 写入并发时若两者对“当前目标文件”的切换缺乏互斥就会出现两条日志分叉到不同文件——恢复时只能按单一顺序回放分叉部分即丢失。本修复消除了这一竞态是对 Keeper 数据一致性的实质性加固依赖 Keeper 做元数据协调如 Distributed 表、物化视图任务、副本协调的集群应优先升级。3.2 查询与分析过滤器合并进 JOIN 条件修复类型不一致与常量操作数场景PR #84145issue #84671修复 issue #83432分析器在优化时可能把 WHERE 中的过滤条件合并merge进 JOIN 的条件中。此前当等式两侧操作数类型不同或引用常量时该合并会产生错误的 JOIN 条件进而导致查询结果不正确。这是典型的正确性缺陷错误结果比报错更危险本修复使该优化仅在安全的前提下生效。若你曾遇到“加了 WHERE 后 JOIN 结果行数异常”的疑难杂症且查询中存在跨类型等值比较或常量比较本版本值得纳入排查范围。array() 函数修复空元组的错误构造PR #84297issue #84493修复 issue #84202修复array()函数构造空元组empty tuple时构造逻辑错误的问题。array()常用于把单个表达式包装为单元素数组在传入Tuple()常量这类空结构时触发了错误分支。该修复影响面相对局部但属于函数语义正确性问题。后台取消检查线程死锁PR #84203issue #84558修复由后台取消检查器cancellation checker线程引起的死锁。该机制的实现位于 CancellationChecker.cpp查询执行期间周期性检查查询是否已被终止如kill mutation、超时或KILL QUERY此前该检查线程在特定锁序下可能与其他线程构成死锁。修复后消除了这一可用性隐患属于高负载、频繁杀查询场景下的稳定性收益。3.3 数据湖与对象存储数据湖中按虚拟列裁剪文件的修复PR #84520issue #84627修复在数据湖Delta Lake / Iceberg 等格式经由dataLakeIngestionMode相关能力读取场景下基于虚拟列做文件级裁剪pruning不生效或错误的问题。文件裁剪是查询数据湖时跳过无关文件、降低扫描量的关键优化裁剪条件依赖虚拟列时此前的逻辑存在缺陷修复后既保证不漏扫文件也能正确跳过无关文件。allow_experimental_delta_kernel_rs默认值回改PR #84587issue #84632为兼容 25.5 之前的行为将allow_experimental_delta_kernel_rs在 25.5 之前版本的默认值改为false。该设置定义于 Settings.cppBETA 级别设置其历史变更记录可参见 SettingsChangesHistory.cpp。这是一个“设置默认值的历史修正”类修复保证system.settings_changes_history等元信息在不同版本间的取值一致避免因默认值漂移影响跨版本行为对比。3.4 可靠性与元数据zoutofmemory归类为硬件错误PR #84420issue #84453将zoutofmemory错误归类为硬件错误hardware error否则会被当作逻辑错误抛出。zoutofmemory是 ClickHouse 在分配内存失败时上报的 OOM 类信号本质属于环境/硬件资源不足而非程序逻辑问题。错误分类直接影响监控告警的准确性与“可重试性”判断——硬件错误通常提示扩容或限流逻辑错误则提示缺陷。若你基于错误类型做分级告警本版本会让 OOM 归位到正确类别。RefreshTask获取 zookeeper 时的互斥锁修复PR #84699issue #84727修复刷新任务RefreshTask支撑物化视图、REFRESH与外部元数据刷新等能力在从 view 对象获取 ZooKeeper/Keeper 连接时未加锁的问题。缺少mutex保护意味着刷新线程可能读到正在析构/重建的连接句柄产生竞态。该修复收敛了元数据刷新路径上的并发风险。四、NO CL ENTRY递归 CTE 条件缓存的回退与再修复本版本还有两条不单独成文的记录NO CL ENTRY但技术含义值得关注因为它们共同构成了一组“修复—回退—再修复”PR #84408Raúl Marín回退了“对递归 CTE 禁用查询条件缓存”这一改动原 #84026 的 25.6 回移。也就是说25.6 上先被禁用的递归 CTE 条件缓存在本版本重新恢复启用PR #84622Robert Schulze修复查询条件缓存query condition cache在非确定性 IN 集合下的使用问题。组合起来看条件缓存在处理递归 CTE 与非确定性 IN 集时曾产生不正确结果此前采取“一刀切禁用”的保守策略本版本先用 #84408 恢复缓存启用再依靠 #84622 精准修复非确定性 IN 集场景下的缓存误用。对重度使用递归 CTE 与IN (SELECT ...)子查询的用户这组变更意味着相关查询重新获得条件缓存的性能收益同时规避了此前的正确性风险。五、NOT FOR CHANGELOG测试层面的小修复唯一的杂项条目PR #84234issue #84362是修复test_storage_rabbitmq集成测试的超时问题作者 Pablo Marcos。该变更不改变任何用户可见行为仅提升 CI 稳定性对升级决策没有影响。六、升级建议与版本影响面小结综合本次回移清单v25.6.6.29-stable 对用户的影响面可归纳为影响面涉及条目风险/收益Keeper 数据一致性changelog 乱序写入修复消除不一致日志与潜在数据丢失建议依赖 Keeper 的集群优先升级查询结果正确性JOIN 条件合并、array()、Dynamic 列回滚修复错误结果类缺陷属正确性收益数据湖写入与查询S3Queue 有序停机、虚拟列裁剪、delta_kernel_rs 默认值改善对象存储队列停机语义与湖格式文件裁剪稳定性取消检查线程死锁、RefreshTask 锁、zoutofmemory 分类减少死锁与错误分类噪声性能与缓存递归 CTE 条件缓存回退再修复恢复缓存收益并修复非确定性 IN 集误用外部元数据PostgreSQL 元数据库行为对齐跨引擎联合查询边界一致性该版本不含任何新功能全部为已验证的回移修复属于低风险的补丁升级。若你当前运行的是 v25.6.5.41-stable 或更早的 25.6 小版本且生产环境依赖 Keeper 协调、数据湖接入S3Queue/Delta Lake或递归 CTE本版本是 25.6 维护线上值得部署的节点。七、延伸阅读仓库内对应位置完整发布记录v25.6.6.29-stable.md同目录下按版本组织的 changelog 全集见 docs/changelogsKeeper 日志持久化src/Coordination/Changelog.h、src/Coordination/KeeperDispatcher.h对象存储队列S3Queue 有序/无序模式src/Storages/ObjectStorageQueue/ObjectStorageQueueMetadata.hDynamic 列实现src/Columns/ColumnDynamic.h取消检查机制src/Interpreters/CancellationChecker.cpp设置定义与变更历史src/Core/Settings.cpp、src/Core/SettingsChangesHistory.cppPostgreSQL 外部元数据引擎src/Databases/PostgreSQL说明本文所有条目均严格对应官方 changelog 中 Backported 的 PR/issue 编号未包含任何未经仓库证据支持的额外结论PR 编号仅作追溯标识可在仓库的 Git 历史中检索对应提交。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考