ClickHouse v25.6.7.23-stable 补丁版本详解：Keeper 请求日志开关、日志缓存限条与四类缺陷修复

ClickHouse v25.6.7.23-stable 补丁版本详解Keeper 请求日志开关、日志缓存限条与四类缺陷修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本文基于 ClickHouse 官方发布记录 v25.6.7.23-stable逐项解读该补丁版本commit4efdb9097eb对照基线 v25.6.6.29-stablecommit63e6c7573e5引入的 3 项改进与 4 个用户可见缺陷修复并结合当前仓库src/Coordination等模块的源码说明新增 4LW 命令lgrq的底层实现、Keeper 日志缓存阈值参数的默认值与语义、watch 计数统计的计量位置等细节帮助维护 ClickHouse Keeper 集群和升级 25.6 分支的读者快速评估升级收益。版本概览v25.6.7.23-stable 是一个面向 25.6 维护分支的稳定补丁版本全部条目均为从主线回合backport而来分为三类Improvement改进3 项全部集中在 Keeper协调服务新增 4LW 命令lgrq、降低存储锁争用、限制日志条目缓存规模Bug Fix用户可见缺陷修复4 项覆盖访问存储日志使用、lazy 列与外部排序组合、Keeper watch 总数统计、后台线程池内存计量漂移NOT FOR CHANGELOG / INSIGNIFICANT3 项不列入用户可见变更的内部改动涉及FilterTransform常量false处理、MergeTreeBackgroundExecutor全局锁持有时间、SharedLockGuard显式加锁能力。改进一Keeper 新增 4LW 命令lgrq开关请求日志该版本为 Keeper 增加了第 4LWfour-letter-word命令lgrq用于在运行时切换“对收到的请求进行日志记录”的行为无需重启进程即可在排查高 QPS 场景的日志压力与定位客户端问题时动态开关。从源码结构看lgrq的实现位于 src/Coordination/FourLetterCommand.hstruct ToggleRequestLogging : public IFourLetterCommand { explicit ToggleRequestLogging(KeeperDispatcher keeper_dispatcher_) : IFourLetterCommand(keeper_dispatcher_) { } String name() override { return lgrq; } String run() override; ~ToggleRequestLogging() override default; };其执行逻辑在 src/Coordination/FourLetterCommand.cpp 中是一个典型的“读旧值—翻转—返回新状态”的切换器String ToggleRequestLogging::run() { const auto keeper_context keeper_dispatcher.getKeeperContext(); auto old_value keeper_context-shouldLogRequests(); keeper_context-setLogRequests(!old_value); return old_value ? disabled : enabled; }也就是说每次执行lgrq都会把请求日志状态取反并返回切换后的状态字符串enabled/disabled调用方据此确认生效结果。该命令在工厂中随其他 4LW 命令一并注册见 src/Coordination/FourLetterCommand.cpp并且已被加入 Keeper 侧合法的 4LW 名称白名单见 src/Coordination/CoordinationSettings.cpp 中...pfev,lgrq的字符串列表。使用方式与其他 4LW 命令一致向 Keeper 端口发送裸的lgrq四字命令例如通过clickhouse-keeper-client的交互模式或原始 socket 客户端即可即时生效。配合同一列表中的stat、wchs等诊断命令运维人员可以在线上快速完成“开日志—抓样本—关日志”的操作闭环。改进二降低 Keeper 存储锁争用本版本回合了对 Keeper 存储层锁竞争的优化PR #84732。Keeper 的节点/watch 存储集中在KeeperNodesStorage/KeeperStorage见 src/Coordination/KeeperNodesStorage.h读多写少的会话型负载下存储锁是热点路径。该改动通过缩小临界区降低锁争用从而在高并发会话操作创建/删除节点、设置 watch场景下提升吞吐。此项为内部性能改进无新增配置项升级后直接生效。改进三按条目数限制 Keeper 日志缓存本版本引入并回合了两个keeper_server.coordination_settings参数用于按“条目数量”约束 Keeper changelog 的内存缓存参数默认值说明latest_logs_cache_entry_count_threshold200000最新日志条目内存缓存的最大条目数commit_logs_cache_entry_count_threshold100000已废弃提交日志缓存的最大条目数当前标记为 OBSOLETE不再起作用请使用log_readahead_commit_window_bytes替代参数声明位于 src/Coordination/CoordinationSettings.cppDECLARE(UInt64, latest_logs_cache_size_threshold, 1_GiB, Maximum memory held by the in-memory cache of latest log entries, counting the per-entry allocation overhead and not just the entries themselves., 0) \ DECLARE(UInt64, latest_logs_cache_entry_count_threshold, 200000, Maximum number of entries in in-memory cache of latest log entries., 0) \ DECLARE(UInt64, commit_logs_cache_size_threshold, 500_MiB, Deprecated. Used as the value of log_readahead_commit_window_bytes if that setting is not itself set., SettingsTierType::OBSOLETE) \ DECLARE(UInt64, commit_logs_cache_entry_count_threshold, 100000, Deprecated, has no effect. Use log_readahead_commit_window_bytes instead., SettingsTierType::OBSOLETE) \结合 src/Coordination/Changelog.h 中LogEntryStorage的设计注释可以理解其语义Keeper 的日志读取依赖“最新日志缓存”latest logs cache其中保存尚未落盘的日志尾部加上已落盘的日志后缀该缓存同时受字节数阈值latest_logs_cache_size_threshold默认 1 GiB按驻留内存计费而非仅计载荷字节与条目数阈值latest_logs_cache_entry_count_threshold默认 20 万条双重约束由于 Raft 复制与提交对日志是顺序访问源码注释明确指出 LRU/SLRU 类缓存帮助有限因此采用“近期日志 顺序读前”的结构。实际配置示例keeper_server节点下keeper_server coordination_settings latest_logs_cache_entry_count_threshold500000/latest_logs_cache_entry_count_threshold latest_logs_cache_size_threshold1073741824/latest_logs_cache_size_threshold /coordination_settings /keeper_server需要特别注意的证据边界在当前仓库源码中commit_logs_cache_entry_count_threshold已被标记为OBSOLETEDeprecated, has no effect提交侧缓存改由log_readahead_commit_window_bytes字节窗口控制。因此对于本版本引入的“按条目数限缓存”能力实际生效的是latest_logs_cache_entry_count_threshold配置commit_logs_cache_entry_count_threshold不会产生效果。这一点以当前源码声明为准。缺陷修复一览1. 修复IAccessStorage中的日志器使用PR #84365 修复了访问控制存储层src/Access下的IAccessStorage及其派生实现中 logger 的使用问题避免日志输出异常或元数据缺失。这是可观察性相关的修复不改变权限语义。2. 修复 lazy 列配合外部排序时误报CORRUPTED_DATAPR #84738 修复了一个数据路径缺陷当查询使用惰性lazy物化的列并触发外部排序内存不足时将中间结果落盘时会错误地抛出CORRUPTED_DATA。该类排序路径的实现位于 src/Processors/Transforms/MergeSortingTransform.cpp本修复使两者组合下不再误报数据损坏。如果你此前将CORRUPTED_DATA与外部排序组合归因为存储损坏并做了数据修复可以先升级验证很多案例升级即可消除。3. 修复 Keeper 返回的 watch 总数统计错误PR #84890 修复了 Keeper 统计接口返回的 watch 总数total watches count不准确的问题。从源码结构看该计数维护在 src/Coordination/KeeperStorage.cpp 的getTotalWatchesCount()中watch 在设置与擦除时分别增减total_watches_count见同文件 L994、L1073、L1083 附近该值同时供 4LW 命令stat/wchs输出与KeeperWatchCount异步指标使用见 src/Coordination/KeeperAsynchronousMetrics.cpp。修复前某些增减路径不对称会导致计数漂移进而影响依赖该指标的监控告警。4. 修复后台调度池与执行器导致的内存计量漂移PR #84946 修复了由后台 schedule 线程池和查询执行器引入的内存跟踪memory tracking漂移问题。ClickHouse 对线程级内存计量一致性要求很高system.processes、system.metrics的 MemoryTracking 等指标都依赖它漂移会导致指标值与实际 RSS 长期不一致进而干扰max_memory_usage类限制与 OOM 排查升级后相关指标的可信度得到恢复。不列入变更说明的内部改动发布记录中还有 3 条标注为 “NOT FOR CHANGELOG / INSIGNIFICANT” 的内部改动虽面向内部行为但对理解引擎稳定性有帮助FilterTransform常量false处理PR #83855此前FilterTransform在某个 chunk 的过滤表达式求值为常量false时可能提前停止读取由于执行过程中允许出现常量列、且多数函数默认实现会保留常量这会造成读取不完整的问题本次修复消除了该隐患见 src/Processors 下的 FilterTransform 实现。缩短MergeTreeBackgroundExecutor全局锁持有时间PR #84311此前删除临时 part尤其在 S3 等慢磁盘上耗时较长且发生在持有全局锁期间当因连接丢失需要重启所有表并等待后台任务结束时表可能长时间停留在只读模式最坏可达一小时量级。改动后发现调用cancel并不需要该锁从而降低了锁持有时间。SharedLockGuard支持显式 lock/unlockPR #84687为共享锁守卫增加了显式加锁/解锁能力用于上述后台执行器改造等需要精细控制锁时机的场景。升级建议与验证要点适用前提本版本仅面向 ClickHouse 25.6 维护分支。若你运行的是更新的维护分支25.7上述修复很可能已包含请以各分支的 docs/changelogs 记录为准若运行 25.6.x 且使用 Keeper建议直接升级到 v25.6.7.23-stable。Keeper 侧验证升级后可用 4LW 命令lgrq验证新命令已注册返回enabled/disabled通过KeeperWatchCount指标或stat命令观察 watch 计数是否与实际会话规模一致确认第 3 项修复生效。参数核对如需限制 Keeper 日志缓存内存按上文配置latest_logs_cache_entry_count_threshold与latest_logs_cache_size_threshold不要依赖已标记 OBSOLETE 的commit_logs_cache_entry_count_threshold。回归关注点若此前遇到过 lazy 列 大结果集排序报CORRUPTED_DATA的查询升级后可重放原查询验证是否消除误报。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考