ClickHouse v25.6.10.16-stable 发布解析Keeper 递归删除优化、物化视图修复与稳定性改进【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本文基于 ClickHouse 官方仓库 docs/changelogs/v25.6.10.16-stable.md 中的发布说明逐条剖析 v25.6.10.16-stable 相对 v25.6.9.98-stable 的变更内容并结合src/Coordination、src/Storages等核心模块源码验证其实现原理。读完本文你将理解 KeeperRemoveRecursive请求的性能优化点、物化视图同名重建失效 Bug 的成因与修复思路、数据库副本恢复期间的表关闭顺序问题以及关闭日志刷新相关的崩溃防护机制从而在升级与运维 ClickHouse 时更有把握地评估风险与收益。版本概览v25.6.10.16-stable 是 ClickHouse 25.6 系列的维护性稳定版本commit6007a7b814a发布于 25.6 分支的持续 Bug 修复周期中。与上一稳定版 v25.6.9.98-stable 相比本次发布以稳定性和正确性修复为主包含1 项功能改进ImprovementKeeperRemoveRecursive请求性能优化3 项用户可见 Bug 修复Bug Fix数据库副本恢复时的表关闭、物化视图同名重建、关闭时日志刷新1 项构建/测试/打包改进openldap升级到 2.6.10若干内部改动NO CL CATEGORY / NOT FOR CHANGELOG。下面逐条展开说明。Keeper RemoveRecursive 请求性能优化变更内容ImprovementImprove performance of RemoveRecursive request in Keeper.PR #86789RemoveRecursive是 KeeperClickHouse 内置的 ZooKeeper 兼容协调服务提供的递归删除请求类型用于一次性删除某个路径节点及其全部子孙节点。在节点数量庞大的场景下例如大量临时节点或协调元数据递归删除的耗时直接关系到 Keeper 请求延迟与吞吐。本次改进的目标就是降低该请求在路径树很大时的处理开销。源码级实现原理RemoveRecursive请求的完整处理链路位于 src/Coordination/KeeperStorageImpl.cpp请求分发KeeperStorageImpl通过KeeperRequestHandler将Coordination::OpNum::RemoveRecursive映射到对应的处理函数见 KeeperStorageImpl.cpp#L147-L148预处理preprocess递归遍历目标路径下所有未提交节点逐个进行 ACL 删除权限校验并统计待删除节点集合见 KeeperStorageImpl.cpp#L687-L764正式处理process将预处理阶段累积的DeltaRange增量直接提交到存储见 KeeperStorageImpl.cpp#L766-L774。其中值得注意的实现细节保护系统路径preprocess会拒绝删除/keeper系统路径下的任何节点coordination::matchPath(zk_request.path, keeper_system_path)匹配时返回ZBADARGUMENTS同时拒绝以/根节点为目标防止误删整个数据树remove_nodes_limit 限制请求携带remove_nodes_limit字段通过storage.nodes.visitUncommittedRecursive(zk_request.path, zk_request.remove_nodes_limit, ...)限制单次递归访问的节点数配合 Keeper 的分批删除multi 分片机制避免单个请求占用过长的锁时间先删子后删父遍历为前序pre-order实际删除时通过nodes_to_remove的反向迭代先删除子节点再删除父节点同时更新父节点的cversion与子节点计数见 KeeperStorageImpl.cpp#L745-L761临时节点清理递归删除过程中对每个isEphemeral()节点执行unregisterEphemeralPath保证临时节点的会话所有者映射被正确清理。feature flag 与兼容性RemoveRecursive由 Keeper 的 feature flag 机制控制。在 src/Coordination/KeeperContext.cpp 中KeeperFeatureFlag::REMOVE_RECURSIVE被列为默认启用的 feature flag 之一。feature flag 的启停状态可以通过 Keeper 配置文件keeper_server.feature_flags段调整并可通过四字母命令FourLetterCommand查询相关实现见 src/Coordination/FourLetterCommand.cpp 与 src/Coordination/KeeperConstants.h 中定义的/keeper/feature_flags系统路径。值得注意的是本次变更中还有一条配套的内部修复NOT FOR CHANGELOGCheck feature flag when adding RemoveRecursive request to Multi.PR #86554即在把RemoveRecursive请求加入 Multi事务批处理时检查 feature flag。这意味着优化不仅作用于独立请求也覆盖了 Multi 内的递归删除场景避免在未启用该 feature 的兼容模式下错误执行。测试验证仓库中针对该请求类型有专门的单元测试见 src/Coordination/tests/gtest_coordination_storage.cppTestRemoveRecursiveRequestL205 起覆盖递归删除正常路径、remove_nodes_limit分批限制、对不存在节点返回ZOK、对根路径/返回ZBADARGUMENTS、limit 为 0 时的行为等场景TestRemoveRecursiveInMultiRequestL424 起验证RemoveRecursive嵌入 Multi 请求时的行为与 feature flag 检查逻辑。测试中通过makeRemoveRecursiveRequest(path, remove_nodes_limit)L415-L418构造请求直接印证了remove_nodes_limit参数的设计语义该参数用于控制单次递归删除的节点数上限是分批删除与请求超时控制的根基。Bug 修复一数据库副本恢复时正确关闭表Bug FixShutdown tables properly when recovering database replica. Improper shutdown would lead to LOGICAL_ERROR for some table engines during database replica recovery.PR #84744问题背景在 Replicated 数据库通过Replicated数据库引擎或相关副本机制执行恢复流程时如果某些表引擎的关闭shutdown处理不当会在恢复期间触发LOGICAL_ERROR。根因在于数据库副本恢复会重建/重挂载表若旧表实例没有走完整的shutdown()生命周期包括停止后台任务、释放资源、清理依赖关系新表实例启动时就会与残留状态冲突进而触发内部断言类错误LOGICAL_ERROR。修复思路修复要求恢复流程中对每个涉及的存储引擎表调用正确的 shutdown 路径。以物化视图为例其关闭逻辑在 src/Storages/StorageMaterializedView.cppflushAndPrepareForShutdown()L1080-L1084先停止refresher物化视图刷新调度器这是关闭前的准备步骤shutdown()L1086-L1093移除与源表之间的依赖关系removeViewDependency确保 DETACH TABLE 后视图与源表不再互相持有引用。这组方法体现了 ClickHouse 表引擎标准的先停后台任务、再清理依赖关闭顺序。数据库副本恢复期间如果跳过或部分执行这些步骤残留的依赖关系与后台线程就会成为LOGICAL_ERROR的温床。运维影响对使用 Replicated 数据库的用户而言此修复降低了副本恢复如网络分区后的同步恢复、节点重启后的本地恢复过程中出现内部错误的概率。升级到该版本后建议在测试环境执行一次完整的副本恢复演练验证无LOGICAL_ERROR日志后再在生产环境滚动升级。Bug 修复二物化视图同名重建失效Bug FixFixed a bug in Materialized Views: an MV might not work if it was created, dropped, and then created again with the same name.PR #86413问题现象物化视图Materialized View存在一个隐蔽的状态残留问题当同一名称的 MV 被创建 → 删除 → 再次以同名创建后新建的 MV 可能不工作不消费源表数据、不写入目标表。根因分析问题出在 MV 的依赖注册机制上。从 src/Storages/StorageMaterializedView.cpp 的shutdown()与startup()实现可以看到MV 通过DatabaseCatalog::instance().addViewDependency(...)注册到源表的观察者列表中删除时通过removeViewDependency反注册startup()L1066-L1078负责启动refresher刷新调度器并支持startup_mv_delay_ms服务端配置的随机启动延迟用于错峰启动。如果第一次删除时依赖关系未完全清理或清理顺序存在问题那么第二次以同名创建 MV 时addViewDependency就会面对一个残留的旧依赖记录导致新 MV 无法正确挂接到源表的数据流上——表现为MV 不工作。修复与验证修复在 PR #86413 中完成核心是确保 MV 生命周期中依赖注册/反注册的对称性。物化视图的完整实现集中在 src/Storages/StorageMaterializedView.cpp涉及的辅助组件如刷新调度位于 src/Storages/MaterializedView/ 目录RefreshSchedule.cpp、RefreshTask.cpp、RefreshSet.cpp等。对使用物化视图做实时 ETL 的用户建议升级后重点回归以下场景CREATE MATERIALIZED VIEW ... AS SELECT ...→DROP TABLE→ 同名重建 → 验证新 MV 能持续消费源表新写入数据。Bug 修复三关闭时日志刷新更安全Bug FixIgnore exceptions during flushing log on shutdown and make shutdown more safe (to avoid SIGSEGV).PR #86546问题背景ClickHouse 服务器关闭shutdown流程中需要将日志缓冲区包括系统日志、查询日志等异步写盘队列刷新落盘。在极端情况下如存储介质故障、磁盘已满、文件句柄失效flush 过程可能抛出异常。如果异常在关闭路径上未被捕获可能向上传播到析构/资源回收阶段最终触发SIGSEGV段错误导致进程异常退出、关闭流程不完整。修复思路修复采用两层策略捕获并忽略 flush 阶段的异常关闭时的日志刷新属于尽力而为操作此时服务器本就要退出flush 失败不应中断关闭流程直接记录日志并继续加固关闭路径避免异常沿关闭链路传播到危险区域如静态对象析构、已释放内存访问从源头杜绝SIGSEGV。该修复与 ClickHouse 日志系统的异步日志架构相关日志队列与刷新逻辑位于 src/Loggers/ 目录。对运维而言此修复降低了异常磁盘状态导致的关闭时崩溃风险让服务器在异常情况下也能走完受控的关闭流程如完成同步、释放锁。构建与依赖改进openldap 2.6.10Build/Testing/Packaging ImprovementUse openldap 2.6.10.PR #86623本次发布将构建依赖openldapOpenLDAP 客户端库用于 ClickHouse 的 LDAP 认证与ldap表函数从旧版本升级到2.6.10。该升级主要服务于安全性与兼容性维护涉及构建配置见 contrib/openldap-cmake/。依赖版本由 contrib/update-submodules.sh 管理的 submodule 机制固定。使用 LDAP 做用户认证的部署users.xml中的ldap认证配置建议在升级后验证一次认证链路。升级建议与验证清单结合本版本所有变更给出如下升级与验证建议Keeper 集群升级后观察RemoveRecursive请求延迟可通过 Keeper 的 metrics 与请求统计验证尤其关注大量临时节点清理场景的性能变化Replicated 数据库执行一次副本恢复演练确认无LOGICAL_ERROR日志物化视图回归创建 → 删除 → 同名重建用例确认新 MV 正常工作LDAP 认证验证 LDAP 用户登录链路关闭流程在可控环境模拟异常存储状态确认关闭不再崩溃注意此项属内部健壮性修复常规环境难以直接观测差异。升级时建议从 v25.6 系列的前一稳定版如 v25.6.9.98-stable逐级验证或直接从受影响的 25.6 早期版本直接升级到 v25.6.10.16-stable。完整变更历史可继续查阅 docs/changelogs/ 目录下的月度 changelog。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ClickHouse v25.6.10.16-stable 发布解析：Keeper 递归删除优化、物化视图修复与稳定性改进
ClickHouse v25.6.10.16-stable 发布解析Keeper 递归删除优化、物化视图修复与稳定性改进【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本文基于 ClickHouse 官方仓库 docs/changelogs/v25.6.10.16-stable.md 中的发布说明逐条剖析 v25.6.10.16-stable 相对 v25.6.9.98-stable 的变更内容并结合src/Coordination、src/Storages等核心模块源码验证其实现原理。读完本文你将理解 KeeperRemoveRecursive请求的性能优化点、物化视图同名重建失效 Bug 的成因与修复思路、数据库副本恢复期间的表关闭顺序问题以及关闭日志刷新相关的崩溃防护机制从而在升级与运维 ClickHouse 时更有把握地评估风险与收益。版本概览v25.6.10.16-stable 是 ClickHouse 25.6 系列的维护性稳定版本commit6007a7b814a发布于 25.6 分支的持续 Bug 修复周期中。与上一稳定版 v25.6.9.98-stable 相比本次发布以稳定性和正确性修复为主包含1 项功能改进ImprovementKeeperRemoveRecursive请求性能优化3 项用户可见 Bug 修复Bug Fix数据库副本恢复时的表关闭、物化视图同名重建、关闭时日志刷新1 项构建/测试/打包改进openldap升级到 2.6.10若干内部改动NO CL CATEGORY / NOT FOR CHANGELOG。下面逐条展开说明。Keeper RemoveRecursive 请求性能优化变更内容ImprovementImprove performance of RemoveRecursive request in Keeper.PR #86789RemoveRecursive是 KeeperClickHouse 内置的 ZooKeeper 兼容协调服务提供的递归删除请求类型用于一次性删除某个路径节点及其全部子孙节点。在节点数量庞大的场景下例如大量临时节点或协调元数据递归删除的耗时直接关系到 Keeper 请求延迟与吞吐。本次改进的目标就是降低该请求在路径树很大时的处理开销。源码级实现原理RemoveRecursive请求的完整处理链路位于 src/Coordination/KeeperStorageImpl.cpp请求分发KeeperStorageImpl通过KeeperRequestHandler将Coordination::OpNum::RemoveRecursive映射到对应的处理函数见 KeeperStorageImpl.cpp#L147-L148预处理preprocess递归遍历目标路径下所有未提交节点逐个进行 ACL 删除权限校验并统计待删除节点集合见 KeeperStorageImpl.cpp#L687-L764正式处理process将预处理阶段累积的DeltaRange增量直接提交到存储见 KeeperStorageImpl.cpp#L766-L774。其中值得注意的实现细节保护系统路径preprocess会拒绝删除/keeper系统路径下的任何节点coordination::matchPath(zk_request.path, keeper_system_path)匹配时返回ZBADARGUMENTS同时拒绝以/根节点为目标防止误删整个数据树remove_nodes_limit 限制请求携带remove_nodes_limit字段通过storage.nodes.visitUncommittedRecursive(zk_request.path, zk_request.remove_nodes_limit, ...)限制单次递归访问的节点数配合 Keeper 的分批删除multi 分片机制避免单个请求占用过长的锁时间先删子后删父遍历为前序pre-order实际删除时通过nodes_to_remove的反向迭代先删除子节点再删除父节点同时更新父节点的cversion与子节点计数见 KeeperStorageImpl.cpp#L745-L761临时节点清理递归删除过程中对每个isEphemeral()节点执行unregisterEphemeralPath保证临时节点的会话所有者映射被正确清理。feature flag 与兼容性RemoveRecursive由 Keeper 的 feature flag 机制控制。在 src/Coordination/KeeperContext.cpp 中KeeperFeatureFlag::REMOVE_RECURSIVE被列为默认启用的 feature flag 之一。feature flag 的启停状态可以通过 Keeper 配置文件keeper_server.feature_flags段调整并可通过四字母命令FourLetterCommand查询相关实现见 src/Coordination/FourLetterCommand.cpp 与 src/Coordination/KeeperConstants.h 中定义的/keeper/feature_flags系统路径。值得注意的是本次变更中还有一条配套的内部修复NOT FOR CHANGELOGCheck feature flag when adding RemoveRecursive request to Multi.PR #86554即在把RemoveRecursive请求加入 Multi事务批处理时检查 feature flag。这意味着优化不仅作用于独立请求也覆盖了 Multi 内的递归删除场景避免在未启用该 feature 的兼容模式下错误执行。测试验证仓库中针对该请求类型有专门的单元测试见 src/Coordination/tests/gtest_coordination_storage.cppTestRemoveRecursiveRequestL205 起覆盖递归删除正常路径、remove_nodes_limit分批限制、对不存在节点返回ZOK、对根路径/返回ZBADARGUMENTS、limit 为 0 时的行为等场景TestRemoveRecursiveInMultiRequestL424 起验证RemoveRecursive嵌入 Multi 请求时的行为与 feature flag 检查逻辑。测试中通过makeRemoveRecursiveRequest(path, remove_nodes_limit)L415-L418构造请求直接印证了remove_nodes_limit参数的设计语义该参数用于控制单次递归删除的节点数上限是分批删除与请求超时控制的根基。Bug 修复一数据库副本恢复时正确关闭表Bug FixShutdown tables properly when recovering database replica. Improper shutdown would lead to LOGICAL_ERROR for some table engines during database replica recovery.PR #84744问题背景在 Replicated 数据库通过Replicated数据库引擎或相关副本机制执行恢复流程时如果某些表引擎的关闭shutdown处理不当会在恢复期间触发LOGICAL_ERROR。根因在于数据库副本恢复会重建/重挂载表若旧表实例没有走完整的shutdown()生命周期包括停止后台任务、释放资源、清理依赖关系新表实例启动时就会与残留状态冲突进而触发内部断言类错误LOGICAL_ERROR。修复思路修复要求恢复流程中对每个涉及的存储引擎表调用正确的 shutdown 路径。以物化视图为例其关闭逻辑在 src/Storages/StorageMaterializedView.cppflushAndPrepareForShutdown()L1080-L1084先停止refresher物化视图刷新调度器这是关闭前的准备步骤shutdown()L1086-L1093移除与源表之间的依赖关系removeViewDependency确保 DETACH TABLE 后视图与源表不再互相持有引用。这组方法体现了 ClickHouse 表引擎标准的先停后台任务、再清理依赖关闭顺序。数据库副本恢复期间如果跳过或部分执行这些步骤残留的依赖关系与后台线程就会成为LOGICAL_ERROR的温床。运维影响对使用 Replicated 数据库的用户而言此修复降低了副本恢复如网络分区后的同步恢复、节点重启后的本地恢复过程中出现内部错误的概率。升级到该版本后建议在测试环境执行一次完整的副本恢复演练验证无LOGICAL_ERROR日志后再在生产环境滚动升级。Bug 修复二物化视图同名重建失效Bug FixFixed a bug in Materialized Views: an MV might not work if it was created, dropped, and then created again with the same name.PR #86413问题现象物化视图Materialized View存在一个隐蔽的状态残留问题当同一名称的 MV 被创建 → 删除 → 再次以同名创建后新建的 MV 可能不工作不消费源表数据、不写入目标表。根因分析问题出在 MV 的依赖注册机制上。从 src/Storages/StorageMaterializedView.cpp 的shutdown()与startup()实现可以看到MV 通过DatabaseCatalog::instance().addViewDependency(...)注册到源表的观察者列表中删除时通过removeViewDependency反注册startup()L1066-L1078负责启动refresher刷新调度器并支持startup_mv_delay_ms服务端配置的随机启动延迟用于错峰启动。如果第一次删除时依赖关系未完全清理或清理顺序存在问题那么第二次以同名创建 MV 时addViewDependency就会面对一个残留的旧依赖记录导致新 MV 无法正确挂接到源表的数据流上——表现为MV 不工作。修复与验证修复在 PR #86413 中完成核心是确保 MV 生命周期中依赖注册/反注册的对称性。物化视图的完整实现集中在 src/Storages/StorageMaterializedView.cpp涉及的辅助组件如刷新调度位于 src/Storages/MaterializedView/ 目录RefreshSchedule.cpp、RefreshTask.cpp、RefreshSet.cpp等。对使用物化视图做实时 ETL 的用户建议升级后重点回归以下场景CREATE MATERIALIZED VIEW ... AS SELECT ...→DROP TABLE→ 同名重建 → 验证新 MV 能持续消费源表新写入数据。Bug 修复三关闭时日志刷新更安全Bug FixIgnore exceptions during flushing log on shutdown and make shutdown more safe (to avoid SIGSEGV).PR #86546问题背景ClickHouse 服务器关闭shutdown流程中需要将日志缓冲区包括系统日志、查询日志等异步写盘队列刷新落盘。在极端情况下如存储介质故障、磁盘已满、文件句柄失效flush 过程可能抛出异常。如果异常在关闭路径上未被捕获可能向上传播到析构/资源回收阶段最终触发SIGSEGV段错误导致进程异常退出、关闭流程不完整。修复思路修复采用两层策略捕获并忽略 flush 阶段的异常关闭时的日志刷新属于尽力而为操作此时服务器本就要退出flush 失败不应中断关闭流程直接记录日志并继续加固关闭路径避免异常沿关闭链路传播到危险区域如静态对象析构、已释放内存访问从源头杜绝SIGSEGV。该修复与 ClickHouse 日志系统的异步日志架构相关日志队列与刷新逻辑位于 src/Loggers/ 目录。对运维而言此修复降低了异常磁盘状态导致的关闭时崩溃风险让服务器在异常情况下也能走完受控的关闭流程如完成同步、释放锁。构建与依赖改进openldap 2.6.10Build/Testing/Packaging ImprovementUse openldap 2.6.10.PR #86623本次发布将构建依赖openldapOpenLDAP 客户端库用于 ClickHouse 的 LDAP 认证与ldap表函数从旧版本升级到2.6.10。该升级主要服务于安全性与兼容性维护涉及构建配置见 contrib/openldap-cmake/。依赖版本由 contrib/update-submodules.sh 管理的 submodule 机制固定。使用 LDAP 做用户认证的部署users.xml中的ldap认证配置建议在升级后验证一次认证链路。升级建议与验证清单结合本版本所有变更给出如下升级与验证建议Keeper 集群升级后观察RemoveRecursive请求延迟可通过 Keeper 的 metrics 与请求统计验证尤其关注大量临时节点清理场景的性能变化Replicated 数据库执行一次副本恢复演练确认无LOGICAL_ERROR日志物化视图回归创建 → 删除 → 同名重建用例确认新 MV 正常工作LDAP 认证验证 LDAP 用户登录链路关闭流程在可控环境模拟异常存储状态确认关闭不再崩溃注意此项属内部健壮性修复常规环境难以直接观测差异。升级时建议从 v25.6 系列的前一稳定版如 v25.6.9.98-stable逐级验证或直接从受影响的 25.6 早期版本直接升级到 v25.6.10.16-stable。完整变更历史可继续查阅 docs/changelogs/ 目录下的月度 changelog。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
