ClickHouse v21.3.7.62-stable 版本变更深度解读fetch 线程池调优、正则匹配阈值与关键 Bug 修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本篇技术指南基于 ClickHouse 官方变更日志v21.3.7.62-stable 版本说明撰写系统梳理该补丁版本中两项核心改进background_fetches_pool_size生产调优、extractAllGroupsHorizontal匹配阈值提升与多项关键 Bug 修复并结合当前仓库源码与配置逐项解读其底层实现、影响面与验证方式。读完本文你将能够理解 ReplicatedMergeTree 后台 fetch 线程池的配置原理、正则批量提取函数的资源保护机制以及该版本中 client 提示、Markdown 输出与 AWS 辅助请求等修复的具体含义。版本背景什么是 v21.3.7.62-stablev21.3.7.62-stable 是 ClickHouse 21.3 系列在 LTS 分支之上的一个补丁patch版本其对照基准为 v21.3.6.55-lts。从变更日志docs/changelogs/archive/v21.3.7.62-stable.md可以清晰看到该版本不包含新特性Feature只包含两类内容Improvement改进2 项涉及后台 fetch 线程池默认配置与正则函数匹配上限Bug Fix缺陷修复4 项覆盖 AWS 请求超时、untuple子查询、clickhouse-client 建议提示、Markdown 格式输出对齐NOT FOR CHANGELOG / INSIGNIFICANT1 项LibraryDictionarySource的潜在内存泄漏修复。这类补丁版本通常用于将若干经过验证的修复与调优回移backport到稳定的 21.3 分支改动小、风险低适合生产环境滚动升级。Improvement 1background_fetches_pool_size默认值调整为 8变更内容本次改进源自 PR #22945经 issue #23014 跟踪回移将background_fetches_pool_size设为8官方描述为更适合频繁小批量插入或 ZooKeeper 集群较慢的生产场景原文Setbackground_fetches_pool_sizeto 8 that is better for production usage with frequent small insertions or slow ZooKeeper cluster。该设置的源码实现在当前仓库中background_fetches_pool_size已被声明为服务端配置项server setting并标注为已迁移至 config.xml的废弃 SQL 设置在 src/Core/Settings.cpp 中它被列入MAKE_DEPRECATED_BY_SERVER_CONFIG宏组即旧版通过 SQL 级SETTINGS指定的方式已废弃当前版本必须在服务端配置文件config.xml 及 server settings 层中设置MAKE_DEPRECATED_BY_SERVER_CONFIG(M, UInt64, background_fetches_pool_size, 8)在 src/Core/ServerSettings.cpp 中官方文档化描述为The maximum number of threads that will be used for fetching data parts from another replica for*MergeTree-enginetables in the background.用于在后台从其他副本拉取*MergeTree系列表数据分片data parts的最大线程数在 src/Interpreters/Context.cpp 中服务器启动时会读取该值并初始化对应的后台执行器size_t background_fetches_pool_size server_settings[ServerSetting::background_fetches_pool_size]; // ... LOG_INFO(shared-log, Initialized background executor for fetches with num_threads{}, num_tasks{}, background_fetches_pool_size, background_fetches_pool_size);为什么 8 更有利于生产ReplicatedMergeTree的副本同步依赖后台线程池执行从其他副本拉取缺失数据分片的任务。该线程池过大的风险在于当大量副本同时追赶日志尤其是有频繁小插入、产生大量小分片或 ZooKeeper 响应缓慢导致任务排队时过多并发 fetch 会与合并merge、变更mutation、普通查询争抢磁盘 IO 与网络带宽反而拖慢整体吞吐。调低为 8 后的收益降低 ZooKeeper 与网络压力的放大效应慢 ZooKeeper 场景下每个 fetch 任务在分配/确认阶段都要与 ZK 交互并发过高会加剧 ZK 延迟为小分片插入场景保留吞吐小分片 fetch 本身耗时短适度并发即可打满多余并发只会制造调度开销更平滑的集群行为默认 8 与同族配置background_common_pool_size 8src/Core/ServerSettings.cpp保持一致的数量级避免单个后台池独占资源。配置方式当前仓库适用由于该设置当前版本已被迁移为服务端配置生产环境应按如下方式在config.xml中配置重启生效clickhouse !-- 后台从其他副本拉取数据分片的最大线程数默认 8 -- background_fetches_pool_size8/background_fetches_pool_size /clickhouse若在错误的地方SQL 层使用它会触发废弃提示。在 src/Core/ServerSettings.cpp 的兼容处理中旧设置名仍可被识别并映射到新配置路径。何时调大、何时调小场景建议频繁小批量 INSERT、ZooKeeper 较慢保持 8 或调小如 4避免线程堆积高吞吐大分片同步、节点追赶滞后严重可调大如 16~32并观察磁盘/网络 IO 是否成为瓶颈数据盘 IO 已饱和调小防止 fetch 挤压查询 IO诊断信息可参考 src/Storages/MergeTree/MergeFromLogEntryTask.cpp 中的运行时提示当复制队列卡住时日志会直接指引检查background_fetches_pool_sizeEither pool for fetches is starving, seebackground_fetches_pool_size, or none of active replicas has itImprovement 2extractAllGroupsHorizontal匹配数量上限提高变更内容本次改进PR #23036经 issue #23081 跟踪回移提高了函数extractAllGroupsHorizontal结果中匹配组数量上限的阈值使其能处理匹配数量更多的输入字符串。函数功能回顾extractAllGroupsHorizontal(s, regexp)使用正则表达式匹配字符串的全部组返回一个二维数组每个内层数组对应一个捕获组capturing group收集该组在所有匹配中的取值。其注册与文档元信息位于 src/Functions/extractAllGroupsHorizontal.cppREGISTER_FUNCTION(ExtractAllGroupsHorizontal) { FunctionDocumentation::Description description R( Matches all groups of a string using the provided regular expression and returns an array of arrays, where each array contains all captures from the same capturing group, organized by group number. ); FunctionDocumentation::Syntax syntax extractAllGroupsHorizontal(s, regexp); // ... factory.registerFunction(extractAllGroupsHorizontal, [](ContextPtr ctx){ return FunctionExtractAllGroups::create(ctx, extractAllGroupsHorizontal, ExtractAllGroupsResultKind::HORIZONTAL); }, documentation); }官方示例HTTP 响应头解析场景WITH Server: nginx Date: Tue, 22 Jan 2019 00:26:14 GMT Content-Type: text/html; charsetUTF-8 Connection: keep-alive AS s SELECT extractAllGroupsHorizontal(s, ([\\w\\-]): ([^\\r\\n]));返回[[Server,Date,Content-Type,Connection],[nginx,Tue, 22 Jan 2019 00:26:14 GMT,text/html; charsetUTF-8,keep-alive]]即第一个内层数组是全部键第二个内层数组是全部值。上限阈值在源码中的体现函数的核心实现在 src/Functions/extractAllGroups.h该文件同时服务extractAllGroupsHorizontal与extractAllGroupsVertical通过ExtractAllGroupsResultKind区分enum class ExtractAllGroupsResultKind : uint8_t { VERTICAL, HORIZONTAL };对于 HORIZONTAL 模式逐行匹配并计数超过上限时**快速失败fail fast**并抛出TOO_LARGE_ARRAY_SIZE错误size_t matches_per_row 0; // ... 循环调用 regexp-Match(...) matches_per_row; /// Additional limit to fail fast on supposedly incorrect usage. if (matches_per_row regexp_max_matches_per_row) throw Exception(ErrorCodes::TOO_LARGE_ARRAY_SIZE, Too many matches per row ( {}) in the result of function {}, regexp_max_matches_per_row, getName());其中regexp_max_matches_per_row来自设置项 src/Core/Settings.cppDECLARE(UInt64, regexp_max_matches_per_row, 1000, R(...))该设置通过FunctionExtractAllGroups构造函数从查询上下文读取src/Functions/extractAllGroups.h。本次改进即上调了这一计数上限使单行包含大量匹配例如解析包含数千条键值对的报文时不至于过早报错当确实超过上限时错误信息会给出明确的每行最大匹配数提示方便使用者调整输入或正则。其他硬限制除匹配次数外实现还有如下保护src/Functions/extractAllGroups.h捕获组数量上限MAX_GROUPS_COUNT 128超过则报BAD_ARGUMENTS: Too many groups in regexp正则必须包含至少一个捕获组否则报BAD_ARGUMENTS: There are no groups in regexp空匹配会前移一位字符避免死循环pos matched_groups[0].data() std::maxsize_t(1, matched_groups[0].size())。使用建议解析长文本如整段日志、HTTP 报文、配置文件时可放心使用extractAllGroupsHorizontal其上限已足够覆盖常见场景若仍遇到Too many matches per row报错可通过 SQL 设置调大regexp_max_matches_per_row注意其为查询级设置但应确认正则是否过宽导致误匹配过多对比extractAllGroupsVertical两者的差异在 src/Functions/extractAllGroups.h 有直接注释——Horizontal 按组号组织结果Vertical 按出现顺序组织结果-- extractAllGroupsVertical(abc111, def222, ghi333, ([^]|\w)([^]|\w)) -- [[abc, 111], [def, 222], [ghi, 333]] -- extractAllGroupsHorizontal(abc111, def222, ghi333, ([^]|\w)([^]|\w)) -- [[abc, def, ghi], [111, 222, 333]]Bug Fix 1AWS 辅助请求不再无限等待修复PR #22594经 issue #23156 跟踪回移解决了辅助 AWS 请求可能无限等待的问题。在 ClickHouse 的 S3 相关存储与备份恢复场景中除了主要的数据请求外还存在认证、列举、元数据等辅助请求若这些请求的服务端不响应或连接异常旧实现可能导致线程长时间挂起进而占用连接池与线程资源。该修复为该类请求补充了超时控制避免单点网络故障拖垮整体读写流程。对于依赖 S3s3表引擎、S3磁盘、BACKUP ... TO S3的生产集群此修复能显著提升在网络抖动或对象存储限流场景下的稳定性。Bug Fix 2修复untuple子查询报错Cannot find column in ActionsDAG result修复PR #22991经 issue #23033 跟踪回移同时关闭原始问题 #22290解决了一个查询优化器层面的缺陷当子查询使用untuple时可能报错Cannot find column in ActionsDAG result。untuple用于将元组展开为多个列是常见的表达式变换手段。该错误源于 ActionsDAG动作有向无环图ClickHouse 表达式执行的核心数据结构在特定优化路径下对经untuple产生的列名推断不一致导致优化器在结果中找不到列。本修复保证了untuple展开后的列在后续优化与执行阶段均可被正确解析。相关模块位于 src/Interpreters 与 src/Processors/Transforms 下的 ActionsDAG 实现。此问题多出现在复杂嵌套查询子查询 untuple 外层引用中升级后此类查询可正常执行。Bug Fix 3clickhouse-client 建议提示去除无关细节修复PR #23040 模块。Bug Fix 4Markdown 格式不再将单元格内容居中对齐修复PR #23096经 issue #23170 跟踪回移修正了Markdown输出格式的渲染问题修复前部分值在表格单元格中会被居中对齐Markdown 表格中的:---:分隔写法导致输出与预期通常应为左对齐或保持原样不一致修复后不再强制居中对齐生成的标准 Markdown 表格可被 GitHub、GitLab 等渲染器正确展示。ClickHouse 支持FORMAT Markdown可将查询结果直接输出为 Markdown 表格便于在文档、Issue 或博客中嵌入查询结果。该修复保证了此类输出在各平台渲染一致SELECT number, number * 2 AS double_number FROM numbers(3) FORMAT Markdown;修复前部分列可能被居中渲染修复后所有列保持统一对齐方式。NOT FOR CHANGELOGLibraryDictionarySource潜在内存泄漏修复变更日志末尾附带一项未计入正式 CHANGELOG 的修复PR #21686 模块负责通过动态加载的外部库如clickhouse-library-bridge为字典提供数据源当字典生命周期结束或重载时若库句柄与回调资源未被正确释放则会产生内存泄漏。此修复完善了资源清理路径对长期运行的字典查询场景字典频繁重载有实际意义。升级与验证建议升级路径本版本基于 v21.3 LTS 分支适用于已运行 21.3 系列并希望获得稳定修复的集群跨大版本升级请参考官方升级指引评估兼容性。重点验证项副本较多的集群观察system.replication_queue与日志中 fetch 任务的吞吐确认background_fetches_pool_size默认 8 下追赶正常使用extractAllGroupsHorizontal/extractAllGroupsVertical的长文本解析查询验证匹配数量上限提升后结果正确使用 S3 存储的BACKUP/s3表确认辅助请求超时行为符合预期包含untuple的嵌套子查询确认不再出现Cannot find column in ActionsDAG result。监控指标可通过系统表system.metrics、system.events观察后台任务线程占用结合 src/Interpreters/Context.cpp 中的启动日志确认线程池实际初始化数量。小结v21.3.7.62-stable 是一个小而稳的补丁版本将background_fetches_pool_size定为 8 更贴合高频小插入与慢 ZooKeeper 的生产现实提升extractAllGroupsHorizontal匹配上限释放了长文本正则解析能力四项 Bug 修复分别针对 S3 辅助请求超时、untuple子查询优化、client 建议提示与 Markdown 输出对齐覆盖了存储、查询优化与交互输出多个层面。这些改动均已在当前仓库源码src/Core/ServerSettings.cpp、src/Functions/extractAllGroups.h、src/Storages/MergeTree/MergeFromLogEntryTask.cpp中得到印证可作为 21.3 生产集群评估升级的参考依据。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考