ClickHouse v20.10.4.1-stable 发布说明详解S3 代理兼容性与 9 项稳定性修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本篇技术文章基于 ClickHouse 官方版本说明v20.10.4.1-stable相对上一稳定版 v20.10.3.30-stable逐条解读该版本的 1 项改进与 9 项缺陷修复。读完后你将了解该版本在 S3 访问路径兼容、MySQL/MaterializeMySQL 引擎、Distributed 表、Avro 输入解析与查询执行层等方面修复了哪些具体问题并结合当前仓库源码定位每一类修复对应的实现位置帮助你判断生产环境是否需要升级到该补丁版本。版本概览本版本是 v20.10.3.30-stable 之后的稳定性补丁版本stable 分支维护发布说明中未包含新功能或 breaking change全部为Improvement改进与Bug Fix缺陷修复两类条目。对于使用 v20.10 系列稳定版的用户这类版本通常只包含向后兼容的缺陷修复是生产环境中风险较低的升级目标。改进S3 经 Nginx 反向代理访问的 URL 兼容性本版本唯一的改进项是一个workaround变通修复解决 ClickHouse 通过 Nginx 反向代理访问 S3 兼容对象存储时的 URL 格式问题问题背景当前版本的 Nginx 不接受空 path 的 URL例如http://domain.com?delete而原版 aws-sdk-cpp 在构造删除对象等请求时恰好会生成这种空 path URL。修复方式该版本使用了打过补丁的 aws-sdk-cpp在此类场景下将 path 补为/例如生成http://domain.com/?delete从而让 Nginx 能正确转发删除请求。来源发布说明标注对应提交为 PR #16813作者 ianton-ru。适用前提与限制该 workaround 仅影响通过 Nginx 代理访问 S3这一部署形态。直连 S3 或 S3 兼容存储的用户不受影响如果你的对象存储网关对?delete这类 URL 有其它要求需要另行验证。当前仓库中第三方依赖由contrib/aws-cmake/下的 CMake 集成脚本管理S3 读写路径的顶层实现在src/Disks/目录DiskObjectStorage、S3 相关 Disk 类该改进通过替换/修补 aws-sdk-cpp 依赖而非修改 ClickHouse 自身 Disk 层代码来实现这也是此类第三方 SDK 兼容性问题通常的处理方式。缺陷修复1/9MySQL 引擎在下游服务器宕机时不应被牵连问题当 ClickHouse 使用 MySQL 作为数据库引擎MySQLengine且远端 MySQL 服务器宕机时一些本不该访问 MySQL 的查询也会抛出异常——因为它们仍会尝试从已失效的服务器获取表列表。发布说明给出的典型例子是SELECT ... FROM system.parts这类只应作用于 MergeTree 表的查询根本不应触碰 MySQL 数据库。源码佐证当前仓库中该数据库引擎的实现位于 DatabaseMySQL.h其中DatabaseMySQL类约 L41继承自DatabaseWithAltersOnDiskBase。该修复属于按需获取表元数据的行为修正只有真正需要读取该库表结构的查询路径才触发远端元数据请求避免了单点故障对无关查询的传染。缺陷修复2/9过滤集合未创建导致返回数据部分丢失修复了返回数据的一部分可能被意外丢弃的不一致行为原因是用于数据过滤的集合set尚未创建。对应 PR #16308作者 Nikita Mikhaylov。这类问题通常表现为同一查询重复执行结果行数不一致排查困难该修复属于查询执行层的状态初始化顺序修正。缺陷修复3/9复制队列中超大条目的处理超大表结构 ALTER问题复制队列replication queue中出现超大条目时处理失败。此类条目可能出现在 ALTER 查询中——当表结构极大接近 1 MB时ZooKeeper 中记录的操作元数据会超出常规假设。源码佐证当前仓库中复制队列与副本同步的核心实现位于src/Storages/MergeTree/目录例如 ReplicatedMergeTree 相关部分 所在的 Compaction 子目录以及数据块交换逻辑 DataPartsExchange。从源码结构看该修复扩大了复制队列条目序列化/反序列化对大 payload 的容忍度避免大 ALTER 语句在副本间同步时失败。适用提示如果你的 MergeTree 表列数极多例如数千篇列的宽表副本节点同步此类 ALTER 时曾出现异常升级到包含本修复的版本是直接的解决途径。缺陷修复4/9DROP TABLE 作用于 Distributed 表时与 INSERT 的竞态问题对 Distributed 表执行 DROP TABLE 时如果同时有 INSERT 正在进行两者存在竞态racy可能导致未定义行为或异常。对应 PR #16409作者 Azat Khuzhin。Distributed 表的写入路径会经过本地临时存储再异步/同步分发到远端分片drop 与 write 并发时的资源回收顺序是该类竞态的典型来源。该修复属于并发正确性问题对高频建删表的场景如按 TTL 批量滚动表、测试环境反复初始化有实际价值。缺陷修复5/9MaterializeMySQL 链路中 GTID 集合膨胀问题在MySQL Master - MySQL Slave - ClickHouse的 MaterializeMySQL 同步链路中如果 MySQL Slave 上开启了slave_parallel_workerClickHouse 侧元数据会快速膨胀。原因是并行复制产生的 GTID 集合没有被正确收缩shrinking导致元数据持续累积。修复方式通过正确收缩 GTID 集合解决对应 PR #16504作者 TCeason。适用前提该修复针对的是多主/并行复制parallel replication环境下的增量同步单线程复制的 GTID 集合天然紧凑不易触发此问题。使用 MaterializeMySQL 引擎的用户若监控到系统元数据目录体积异常增长可对照本条目排查。缺陷修复6/9Avro 输入解析时移除 LowCardinality 包装解析 Avro 输入数据时目标列类型中的LowCardinality包装会被去掉后再做类型匹配。此前该行为会导致 Avro 数据导入目标LowCardinality(...)列时出现类型不匹配问题。对应 PR #16521作者 Mike Kot。当前仓库的 Avro 输入格式实现位于src/Formats/目录AvroRowInputFormat 相关文件该修复属于输入层类型归一化逻辑对通过INSERT INTO ... FORMAT Avro或file()表函数导入 Avro 数据的用户是兼容性修正。缺陷修复7/9修复 #16081 关联问题该条目为对 issue #16081 的修复对应 PR #16613作者 Nikita Mikhaylov发布说明未附详细描述属于常规缺陷修复的 backport。若你的工作流涉及相关 issue 场景可在升级后针对性回归验证。缺陷修复8/9ORDER BY 含表达式时按序读优化失效问题optimize_read_in_order/optimize_aggregation_in_order两个优化在max_threads 0且ORDER BY中是表达式而非裸列时会失效。对应 PR #16637作者 Azat Khuzhin。源码佐证当前仓库中该设置项定义于 Settings.cpp默认值为true用于让SELECT ... ORDER BY按排序键顺序读取数据以避免全局排序。修复之后形如ORDER BY toDate(timestamp_col) DESC这类表达式排序也能正确走按序读取优化路径对大结果集查询的内存占用与延迟有直接改善。缺陷修复9/9atransform_null_in 开启后 IN 多列/元组比较出错问题当设置transform_null_in开启时IN运算符作用于多列/元组tuple的比较结果不正确。对应 PR #16722作者 Anton Popov。源码佐证transform_null_in同样定义于 Settings.cpp作用是在IN右操作数为子查询时把 NULL 值从结果中剔除因为 SQL 语义下x IN (NULL, ...)结果应为 NULL 而非匹配。该修复覆盖了IN 右侧是多个列或 tuple 子查询这一分支属于 NULL 语义正确性问题对开启该设置的精确去重/半连接查询场景有实际影响。缺陷修复9/9b查询分析器开启时在特定 glibc 下罕见静默崩溃问题开启查询分析器query profiler时在部分 glibc 版本的操作系统上会出现罕见的静默崩溃silent crash。根因是指定 glibc 版本中某些函数的**异步展开表asynchronous unwind tables**存在缺陷导致栈回溯时读取了损坏的展开信息。对应 PR #16846作者 Alexey Milovidov。排查与规避建议典型症状是开启enable_analyzer相关功能或查询剖析后偶发崩溃、且没有常规异常日志若你的发行版 glibc 属于受影响版本升级到包含本修复的补丁版本即可ClickHouse 侧对损坏的展开表做了防御性处理。升级建议与小结v20.10.4.1-stable是一个典型的稳定性补丁版本按影响面可归纳为三条主线外部系统集成S3 经 Nginx 代理的 URL 兼容性Improvement、MySQL / MaterializeMySQL 引擎的可用性修复数据正确性过滤集合缺失导致数据丢失、transform_null_in下 IN 元组比较、Avro 解析 LowCardinality 类型匹配并发与鲁棒性Distributed 表 DROP/INSERT 竞态、复制队列超大条目、按序读优化在表达式排序下失效、特定 glibc 下的剖析器崩溃。如果你在 v20.10.3.30-stable 上遇到上述任一症状尤其是 S3 代理部署、超大宽表副本同步、MySQL 链路元数据膨胀升级到v20.10.4.1-stable是对应的修复版本由于本版本不引入新功能升级回归成本较低。本文所有修复条目均以官方发布说明为准实现位置佐证来自当前仓库对应模块的源码结构供进一步深入阅读参考。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ClickHouse v20.10.4.1-stable 发布说明详解：S3 代理兼容性与 9 项稳定性修复
ClickHouse v20.10.4.1-stable 发布说明详解S3 代理兼容性与 9 项稳定性修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本篇技术文章基于 ClickHouse 官方版本说明v20.10.4.1-stable相对上一稳定版 v20.10.3.30-stable逐条解读该版本的 1 项改进与 9 项缺陷修复。读完后你将了解该版本在 S3 访问路径兼容、MySQL/MaterializeMySQL 引擎、Distributed 表、Avro 输入解析与查询执行层等方面修复了哪些具体问题并结合当前仓库源码定位每一类修复对应的实现位置帮助你判断生产环境是否需要升级到该补丁版本。版本概览本版本是 v20.10.3.30-stable 之后的稳定性补丁版本stable 分支维护发布说明中未包含新功能或 breaking change全部为Improvement改进与Bug Fix缺陷修复两类条目。对于使用 v20.10 系列稳定版的用户这类版本通常只包含向后兼容的缺陷修复是生产环境中风险较低的升级目标。改进S3 经 Nginx 反向代理访问的 URL 兼容性本版本唯一的改进项是一个workaround变通修复解决 ClickHouse 通过 Nginx 反向代理访问 S3 兼容对象存储时的 URL 格式问题问题背景当前版本的 Nginx 不接受空 path 的 URL例如http://domain.com?delete而原版 aws-sdk-cpp 在构造删除对象等请求时恰好会生成这种空 path URL。修复方式该版本使用了打过补丁的 aws-sdk-cpp在此类场景下将 path 补为/例如生成http://domain.com/?delete从而让 Nginx 能正确转发删除请求。来源发布说明标注对应提交为 PR #16813作者 ianton-ru。适用前提与限制该 workaround 仅影响通过 Nginx 代理访问 S3这一部署形态。直连 S3 或 S3 兼容存储的用户不受影响如果你的对象存储网关对?delete这类 URL 有其它要求需要另行验证。当前仓库中第三方依赖由contrib/aws-cmake/下的 CMake 集成脚本管理S3 读写路径的顶层实现在src/Disks/目录DiskObjectStorage、S3 相关 Disk 类该改进通过替换/修补 aws-sdk-cpp 依赖而非修改 ClickHouse 自身 Disk 层代码来实现这也是此类第三方 SDK 兼容性问题通常的处理方式。缺陷修复1/9MySQL 引擎在下游服务器宕机时不应被牵连问题当 ClickHouse 使用 MySQL 作为数据库引擎MySQLengine且远端 MySQL 服务器宕机时一些本不该访问 MySQL 的查询也会抛出异常——因为它们仍会尝试从已失效的服务器获取表列表。发布说明给出的典型例子是SELECT ... FROM system.parts这类只应作用于 MergeTree 表的查询根本不应触碰 MySQL 数据库。源码佐证当前仓库中该数据库引擎的实现位于 DatabaseMySQL.h其中DatabaseMySQL类约 L41继承自DatabaseWithAltersOnDiskBase。该修复属于按需获取表元数据的行为修正只有真正需要读取该库表结构的查询路径才触发远端元数据请求避免了单点故障对无关查询的传染。缺陷修复2/9过滤集合未创建导致返回数据部分丢失修复了返回数据的一部分可能被意外丢弃的不一致行为原因是用于数据过滤的集合set尚未创建。对应 PR #16308作者 Nikita Mikhaylov。这类问题通常表现为同一查询重复执行结果行数不一致排查困难该修复属于查询执行层的状态初始化顺序修正。缺陷修复3/9复制队列中超大条目的处理超大表结构 ALTER问题复制队列replication queue中出现超大条目时处理失败。此类条目可能出现在 ALTER 查询中——当表结构极大接近 1 MB时ZooKeeper 中记录的操作元数据会超出常规假设。源码佐证当前仓库中复制队列与副本同步的核心实现位于src/Storages/MergeTree/目录例如 ReplicatedMergeTree 相关部分 所在的 Compaction 子目录以及数据块交换逻辑 DataPartsExchange。从源码结构看该修复扩大了复制队列条目序列化/反序列化对大 payload 的容忍度避免大 ALTER 语句在副本间同步时失败。适用提示如果你的 MergeTree 表列数极多例如数千篇列的宽表副本节点同步此类 ALTER 时曾出现异常升级到包含本修复的版本是直接的解决途径。缺陷修复4/9DROP TABLE 作用于 Distributed 表时与 INSERT 的竞态问题对 Distributed 表执行 DROP TABLE 时如果同时有 INSERT 正在进行两者存在竞态racy可能导致未定义行为或异常。对应 PR #16409作者 Azat Khuzhin。Distributed 表的写入路径会经过本地临时存储再异步/同步分发到远端分片drop 与 write 并发时的资源回收顺序是该类竞态的典型来源。该修复属于并发正确性问题对高频建删表的场景如按 TTL 批量滚动表、测试环境反复初始化有实际价值。缺陷修复5/9MaterializeMySQL 链路中 GTID 集合膨胀问题在MySQL Master - MySQL Slave - ClickHouse的 MaterializeMySQL 同步链路中如果 MySQL Slave 上开启了slave_parallel_workerClickHouse 侧元数据会快速膨胀。原因是并行复制产生的 GTID 集合没有被正确收缩shrinking导致元数据持续累积。修复方式通过正确收缩 GTID 集合解决对应 PR #16504作者 TCeason。适用前提该修复针对的是多主/并行复制parallel replication环境下的增量同步单线程复制的 GTID 集合天然紧凑不易触发此问题。使用 MaterializeMySQL 引擎的用户若监控到系统元数据目录体积异常增长可对照本条目排查。缺陷修复6/9Avro 输入解析时移除 LowCardinality 包装解析 Avro 输入数据时目标列类型中的LowCardinality包装会被去掉后再做类型匹配。此前该行为会导致 Avro 数据导入目标LowCardinality(...)列时出现类型不匹配问题。对应 PR #16521作者 Mike Kot。当前仓库的 Avro 输入格式实现位于src/Formats/目录AvroRowInputFormat 相关文件该修复属于输入层类型归一化逻辑对通过INSERT INTO ... FORMAT Avro或file()表函数导入 Avro 数据的用户是兼容性修正。缺陷修复7/9修复 #16081 关联问题该条目为对 issue #16081 的修复对应 PR #16613作者 Nikita Mikhaylov发布说明未附详细描述属于常规缺陷修复的 backport。若你的工作流涉及相关 issue 场景可在升级后针对性回归验证。缺陷修复8/9ORDER BY 含表达式时按序读优化失效问题optimize_read_in_order/optimize_aggregation_in_order两个优化在max_threads 0且ORDER BY中是表达式而非裸列时会失效。对应 PR #16637作者 Azat Khuzhin。源码佐证当前仓库中该设置项定义于 Settings.cpp默认值为true用于让SELECT ... ORDER BY按排序键顺序读取数据以避免全局排序。修复之后形如ORDER BY toDate(timestamp_col) DESC这类表达式排序也能正确走按序读取优化路径对大结果集查询的内存占用与延迟有直接改善。缺陷修复9/9atransform_null_in 开启后 IN 多列/元组比较出错问题当设置transform_null_in开启时IN运算符作用于多列/元组tuple的比较结果不正确。对应 PR #16722作者 Anton Popov。源码佐证transform_null_in同样定义于 Settings.cpp作用是在IN右操作数为子查询时把 NULL 值从结果中剔除因为 SQL 语义下x IN (NULL, ...)结果应为 NULL 而非匹配。该修复覆盖了IN 右侧是多个列或 tuple 子查询这一分支属于 NULL 语义正确性问题对开启该设置的精确去重/半连接查询场景有实际影响。缺陷修复9/9b查询分析器开启时在特定 glibc 下罕见静默崩溃问题开启查询分析器query profiler时在部分 glibc 版本的操作系统上会出现罕见的静默崩溃silent crash。根因是指定 glibc 版本中某些函数的**异步展开表asynchronous unwind tables**存在缺陷导致栈回溯时读取了损坏的展开信息。对应 PR #16846作者 Alexey Milovidov。排查与规避建议典型症状是开启enable_analyzer相关功能或查询剖析后偶发崩溃、且没有常规异常日志若你的发行版 glibc 属于受影响版本升级到包含本修复的补丁版本即可ClickHouse 侧对损坏的展开表做了防御性处理。升级建议与小结v20.10.4.1-stable是一个典型的稳定性补丁版本按影响面可归纳为三条主线外部系统集成S3 经 Nginx 代理的 URL 兼容性Improvement、MySQL / MaterializeMySQL 引擎的可用性修复数据正确性过滤集合缺失导致数据丢失、transform_null_in下 IN 元组比较、Avro 解析 LowCardinality 类型匹配并发与鲁棒性Distributed 表 DROP/INSERT 竞态、复制队列超大条目、按序读优化在表达式排序下失效、特定 glibc 下的剖析器崩溃。如果你在 v20.10.3.30-stable 上遇到上述任一症状尤其是 S3 代理部署、超大宽表副本同步、MySQL 链路元数据膨胀升级到v20.10.4.1-stable是对应的修复版本由于本版本不引入新功能升级回归成本较低。本文所有修复条目均以官方发布说明为准实现位置佐证来自当前仓库对应模块的源码结构供进一步深入阅读参考。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考