十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

ClickHouse v21.2.6.1-stable 变更日志深度解析:8 项关键 Bug 修复的技术内幕与实战影响

ClickHouse v21.2.6.1-stable 变更日志深度解析:8 项关键 Bug 修复的技术内幕与实战影响 ClickHouse v21.2.6.1-stable 变更日志深度解析8 项关键 Bug 修复的技术内幕与实战影响【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本指南以 ClickHouse 官方变更日志 docs/changelogs/archive/v21.2.6.1-stable.md 为骨架逐条剖析 v21.2.5.5-stable → v21.2.6.1-stable 这一补丁版本修复的 8 项缺陷结合当前仓库源码揭示每个 Bug 的触发场景、修复思路与底层原理帮助你在升级、运维和 SQL 编写中避开这些历史陷阱。版本背景与补丁性质v21.2.6.1-stable 是 ClickHouse 2021 年 2 月 21.x 系列的一个维护性补丁版本changelog 归类于 2022 归档目录内容实为 2021 年发布。它相比 v21.2.5.5-stable 不含新特性全部为Bug Fix且每个修复都以Backported方式从主线 cherry-pick 回 21.2 稳定分支——这体现了 ClickHouse 的发布节奏主分支持续开发稳定分支通过 backport 只吸收经过验证的缺陷修复保证生产环境可安全升级。整个发布周期围绕一个核心矛盾展开在多线程并行执行与元数据一致性/类型正确性之间打补丁。下面逐条解读。1. 标量子查询与索引子查询的线程数修复Backported in [#21352]修复标量子查询和索引子查询的线程数问题在 [#19007] 之后总是使用单线程。修复 [#20457]、[#20512]。Bug 本质标量子查询scalar subquery和用于索引index / prewhere 等的子查询在 #19007 引入的改动中被强制固定为单线程执行导致这类查询在大数据量场景下性能退化。21.2.6.1 恢复了它们对max_threads的正确感知让子查询也可以利用多核并行计算。底层链路子查询的线程分配发生在查询解释与流水线构建阶段。涉及的关键组件src/Interpreters/IInterpreterUnionOrSelectQuery.cppUNION/SELECT 类解释器的公共基类负责把子查询转换为执行流水线src/Interpreters/InterpreterSelectQuery.cppSELECT 解释器内部会根据子查询的语义标量、IN、索引等决定是否限制并行度src/Interpreters/QueryPipeline 相关文件最终将线程数落实到QueryPipeline的 processors 调度。从源码结构看该修复的本质是在InterpreterSelectQuery内部为标量/索引用途的子查询显式回传线程数配置而不是粗暴地用 1 覆盖。修复后标量子查询如SELECT (SELECT max(x) FROM big_table) 1可按max_threads并行用于分区裁剪、索引indexHint / PREWHERE的子查询同样受益表现为主查询本身的性能回归消除而非引入新的行为。2. ReplicatedMergeTree 的 default_replica_path / default_replica_name 修复Backported in [#21262]修复在 Replicated(*)MergeTree 引擎需要指定其他参数时default_replica_path和default_replica_name的值失效的问题。触发场景ReplicatedMergeTree家族ReplicatedMergeTree、ReplicatedSummingMergeTree、ReplicatedAggregatingMergeTree等的引擎参数中前两个位置被约定为 ZooKeeper 路径和副本名。当用户需要指定第三个及以后的引擎参数例如ReplicatedSummingMergeTree(/path, {replica}, sum_col)中的聚合列时会省略前两个参数以使用默认值——而该 Bug 导致省略后默认值没有正确生效。源码实现印证当前仓库在 src/Storages/MergeTree/registerStorageMergeTree.cpp 中完整保留了这套参数补全逻辑第 324-349 行当引擎参数个数不足arg_cnt 0或仅为 Graphite 等特殊情形时代码会构造空的 path/name 字面量再通过expand_macro用服务端配置中的默认值server_settings[ServerSetting::default_replica_path]、default_replica_name填充最后把填充结果回写到元数据中服务端默认值示例同文件 4604-4605 行附近default_replica_path/clickhouse/tables/{shard}/{database}/{table}/default_replica_path default_replica_name{replica}/default_replica_name该文件 4688 行附近的注释明确说明ReplicatedMergeTree 表将使用default_replica_path与default_replica_name设置创建。其中{shard}、{database}、{table}、{replica}是宏运行时分别替换为分片名、库名、表名、副本标识默认取主机名。v21.2.6.1 之前的缺陷在于当显式提供了第三个参数但省略前两个时旧逻辑没有走默认值填充分支导致前两个参数以空串写入 ZooKeeper 路径进而造成副本元数据错乱。修复后参数解析统一按省略即默认处理。3. CAST Tuple → Map 的类型转换 BugBackported in [#21156]修复 cast tuple to map元组转 Map相关的 Bug。修复 [#21029]。Bug 本质将 Tuple 类型CAST为Map类型时例如CAST((1, a), Map(UInt8, String))旧版本在特定输入如元素类型不完全匹配、或嵌套结构下会产生类型错误或错误结果。实现位置Tuple→Map 的转换实现集中在 src/Functions/FunctionsConversion.cpp 与 src/Functions/FunctionsConversion.h。CAST 引擎会把目标类型Map(K, V)的构造委托给tupleToMap类函数族由它负责将等长元组的两两相邻元素配对为 key/value校验并转换 key 与 value 的实际类型到Map的声明类型处理LowCardinality等包装类型的剥壳。该修复的关键价值在于涉及 Map 的迁移脚本与 ETL 管道中CAST 不再是黑盒风险点。21.2.6.1 之后CAST(tuple, Map(...))的类型转换遵循与map()函数一致的严格语义。4. 仅允许支持 Mutation 的引擎执行变更Mutation 白名单Backported in [#21234]现在仅允许支持 Mutation 的表引擎MergeTree 家族、Memory、MaterializedView执行 Mutation其他引擎将报告更清晰的错误。修复 [#21168]。背景ALTER TABLE ... UPDATE/DELETE依赖引擎的Mutation机制。旧版本中对不支持 Mutation 的引擎如Log、TinyLog、StripeLog、Kafka等执行ALTER ... UPDATE时错误信息晦涩甚至可能触发未定义行为。21.2.6.1 引入了显式的引擎能力检查报错清晰化。源码印证基类默认行为定义在 src/Storages/IStorage.cpp 第 301-321 行附近checkMutationIsPossible等接口的默认实现直接抛出ErrorCodes::NOT_IMPLEMENTED消息为 Mutations are not supported by storage {name}MergeTree 家族在 src/Storages/MergeTree/MergeTreeData.cpp 的checkMutationIsPossible第 6239 行附近中实现了完整的校验包括对不可变磁盘immutable disk的拒绝Mutations are not supported for immutable disk {disk}Memory、MaterializedView引擎各自覆写支持 Mutation。实战建议从 21.2.6.1 起当你在Log/Kafka等表上执行ALTER ... UPDATE时会立即得到明确的 Mutations are not supported by storage xxx 错误而不是默默失败或产生不一致状态。运维侧应把该报错视为设计如此改走重建表或使用支持 Mutation 的引擎。5. EXPLAIN UNION 查询崩溃修复Backported in [#21427]修复含 UNION 的查询执行 EXPLAIN 时的崩溃。修复 [#20876]、[#21170]。Bug 本质EXPLAIN如EXPLAIN PIPELINE、EXPLAIN PLAN对包含UNION/UNION ALL的查询构建执行计划时旧代码在合并多个 SELECT 子查询的流水线pipeline阶段存在空指针或错误的内存访问导致服务端崩溃而非返回错误。源码位置src/Interpreters/InterpreterExplainQuery.cppEXPLAIN 解释器负责将目标查询解释后的流水线序列化为 PLAN/PIPELINE 文本src/Interpreters/IInterpreterUnionOrSelectQuery.cppUNION 的公共执行逻辑。实战影响这是 8 个修复中风险等级最高的一个——因为它可能导致clickhouse-server 进程崩溃crash而不仅是查询报错。在 21.2.6.1 之前的版本中对生产库直接执行EXPLAIN ... SELECT ... UNION ...存在触发崩溃的风险。升级后该场景变为安全的正常输出。6. 冗余 ZooKeeper 重连与双会话问题Backported in [#21301]修复单个 clickhouse-server 对 ZooKeeper 的冗余重连以及可能出现两个活动会话的问题。两个问题均由 [#14678] 引入。Bug 本质#14678 引入了会话管理改动却带来两个副作用冗余重连redundant reconnectsserver 频繁与 ZooKeeper 重新建立连接增加 ZK 集群负载与网络抖动敏感性双活动会话two active sessions单个 server 实例与 ZooKeeper 之间出现两个同时有效的会话这在分布式协调场景下极其危险——可能造成重复回调、分布式 DDL 重复执行、复制队列状态错乱。影响面涉及 src/Coordination 与 src/Storages/MergeTree 中所有 ZooKeeper 会话持有者ReplicatedMergeTree 副本、Replicated 数据库、分布式 DDL 队列等。修复后会话生命周期管理恢复为单实例单活动会话 按需重连显著提升多副本集群的稳定性。7. ALTER MODIFY COLUMN 未级联更新分区键 / 跳数索引 / TTLBackported in [#21553]现在ALTER MODIFY COLUMN查询将正确影响分区键、跳数索引skip indices、TTL 等的变更。修复 [#13675]。Bug 本质ALTER TABLE t MODIFY COLUMN c TYPE ...修改列类型时若该列同时被分区键、跳数索引或 TTL 表达式引用这些派生元数据没有同步更新导致分区裁剪partition pruning使用旧类型产生错误结果跳数索引INDEX ... TYPE minmax/granularity基于旧类型计算索引失效或崩溃TTL 表达式的类型与列实际类型不一致。源码印证该修复的落点在 Mutation 命令的元数据变更机制中src/Storages/MergeTree/AlterConversions.cpp维护列类型变更的转换映射src/Storages/MergeTree/MergeTreeDataMergerMutator.cpp 与 MutateTask.cpp执行 Mutation 时同步重写分区键表达式、索引定义与 TTL 中的列引用MergeTreeData.h 中isSupported*Mutation系列接口用于判断哪些 Mutation 可被AlterConversions安全处理。修复前这类变更会产生静默不一致——表结构元数据与派生对象脱节修复后MODIFY COLUMN会在 Mutation 执行阶段统一重建受影响的分区键/索引/TTL 定义。8. VALUES 格式写入 LowCardinality 列的 Bad cast 崩溃Backported in [#21380]修复通过Values格式向含LowCardinality列的表插入数据时的Bad cast from type ... to DB::ColumnLowCardinality错误。修复 [#21140]。Bug 本质INSERT INTO t VALUES (...)使用Values格式时输入解析器对目标列类型的感知与LowCardinality包装层不一致导致把普通列数据直接强转cast为ColumnLowCardinality时抛出Bad cast from type ... to DB::ColumnLowCardinality。这是从客户端直连插入时最容易踩中的错误之一。相关实现src/Formats/EscapingRuleUtils.cppValues/CSV 等基于转义规则的格式在解析时调用deserializeText需正确剥开LowCardinality的字典包装src/Formats/insertNullAsDefaultIfNeeded.cpp处理插入时的类型适配src/DataTypes/DataTypeLowCardinality.cppLowCardinality数据类型的嵌套解析入口。修复后的行为Values格式下向LowCardinality(String)等列插入普通字符串字面量时解析器先写入底层字典再构建ColumnLowCardinality不再发生跨类型直接 cast。升级与验证建议该版本为纯 Bug Fix 补丁升级路径平滑但建议先在测试环境验证涉及 ZooKeeper修复 6与 Mutation修复 4、7的场景修复 5EXPLAINUNION 崩溃与修复 8VALUESLowCardinality 报错可以通过回归 SQL 快速验证EXPLAIN PLAN SELECT number FROM system.numbers LIMIT 1 UNION ALL SELECT number FROM system.numbers LIMIT 1应正常输出计划CREATE TABLE t (s LowCardinality(String)) ENGINEMemory; INSERT INTO t VALUES (a), (b);不应再报Bad cast修复 2 涉及副本路径升级前建议核对config.xml中的default_replica_path/default_replica_name是否符合预期参考 src/Storages/MergeTree/registerStorageMergeTree.cpp 第 4604-4605 行附近的默认值模板。小结v21.2.6.1-stable 的 8 项修复覆盖了三类典型问题性能回归标量子查询线程数、稳定性与崩溃EXPLAINUNION、ZK 双会话、Mutation 白名单、LowCardinality cast、元数据一致性ReplicatedMergeTree 默认参数、MODIFY COLUMN 级联、Tuple→Map CAST。虽然该版本距今已久但其修复模式——backport 机制、Mutation 能力白名单、LowCardinality 包装类型解析——至今仍是 ClickHouse 演进与排障的核心方法论理解它们有助于你在更现代的版本中快速定位同类问题。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表