ClickHouse v21.6.3.14-stable 补丁版解析S3 零拷贝复制、LDAP 角色映射与复制队列稳定性修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse导读本篇文章基于当前仓库 docs/changelogs/archive/v21.6.3.14-stable.md 的发布说明系统梳理 ClickHouse v21.6 系列第二个稳定补丁版v21.6.3.14-stable相对 v21.6.2.7-prestable 引入的全部 2 项改进与 5 项 Bug 修复。文中将逐条还原每个修复对应的技术背景、问题根因与影响范围并结合当前仓库源码如src/Disks/DiskObjectStorage、src/Access/LDAPAccessStorage.cpp、src/Storages/MergeTree等给出源码级佐证帮助读者判断该补丁与自己生产环境的关联程度并据此制定升级与验证策略。一、版本背景stable 补丁版在发布节奏中的定位ClickHouse 的发布流程分为 prestable 与 stable 两条线功能特性先在-prestable版本中合入经过回归验证后进入-stable分支而形如v21.6.3.14-stable的补丁版本则是在主版本发布后针对回归缺陷与高优先级问题的小步快修版本。本补丁直接对比对象是v21.6.2.7-prestable说明它是 v21.6 主版本线在向稳定态收敛过程中的一次集中修复。本补丁值得关注的原因在于修复面覆盖了存储层S3 零拷贝复制、低内存下 merge 失败、访问控制层LDAP 角色映射死锁、复制与数据一致性层ZooKeeper 断连后的复制队列脏数据、HTTP 协议层multipart/form-data 边界解析以及列式格式层Arrow 堆缓冲区溢出属于典型的发布后集中收口版本。二、Improvement两项行为改进2.1 修复多 S3 volume 场景下的 Zero-Copy 复制原文条目Fix Zero-Copy replication with several S3 volumesFixes #22679对应 PR #22864。问题背景零拷贝复制Zero-Copy Replication是 ClickHouse 针对对象存储S3、Azure Blob Storage 等设计的一种复制优化。与本地磁盘复制不同它不把数据 part 实际拷贝到每个副本而是让所有副本共享同一个底层对象存储对象仅通过 ZooKeeper 复制元数据与 part 的引用关系从而大幅节省存储空间与网络开销。问题根因当一张复制表被配置在多个 S3 volume上时不同 part 可能落在不同的 bucket / 存储桶组合中零拷贝复制的元数据路由逻辑若不能正确处理这种多 volume 分布会导致副本间元数据不一致或 part 归属错乱。源码佐证当前仓库 src/Disks/DiskObjectStorage/DiskObjectStorage.h 中定义了supportZeroCopyReplication()/// Keeper metadata replicates itself; in-memory metadata is transient and has no local /// metadata files zero-copy could ship (see getReplicatedFilesDescriptionForRemoteDisk). bool supportZeroCopyReplication() const override { return metadata_storage-getType() ! MetadataStorageType::Keeper metadata_storage-getType() ! MetadataStorageType::Memory; }这说明零拷贝复制的能力与元数据存储类型强绑定Keeper / 内存元数据不支持只有普通对象存储元数据才可启用同一磁盘还需具备将本地路径映射到对象存储对象的元数据机制见 src/Disks/DiskObjectStorage/DiskObjectStorage.h 中关于 metadata 的描述。零拷贝复制是可选配置项生产环境若使用对象存储需在表引擎或磁盘配置中显式开启并验证多 volume 场景下的复制行为。2.2 标量子查询不再吞掉超限错误原文条目Avoid hiding errors likeLimit for rows or bytes to read exceededfor scalar subqueries。问题背景标量子查询scalar subquery要求查询最多返回一行。此前某些内部处理路径会把子查询执行过程中的限制类异常如Limit for rows or bytes to read exceeded即max_rows_to_read/max_bytes_to_read等配额被触达吞掉或改写导致用户无法看到真正的原因。修复效果本补丁后标量子查询在触达行数/字节数读取上限时错误信息能够如实透传给客户端便于定位是数据量问题还是配额配置问题。三、Bug Fix五类稳定性与正确性修复3.1 multipart/form-data 消息中 boundary 前 CRLF 的处理原文条目In multipart/form-data message consider the CRLF preceding a boundary as part of itFixes #23905。问题背景HTTP 接口以multipart/form-data上传数据时boundary分界符之前的 CRLF回车换行在协议语义中属于该消息的一部分。如果解析器忽略这一点可能把分界符前的空行误判为数据内容导致多部分消息的切分错位。修复效果解析逻辑把 boundary 前的 CRLF 纳入边界判定保证各 part 的内容切分严格符合协议。当前仓库中 S3 / 对象存储相关的 HTTP 客户端均包含 multipart 组装与解析逻辑见 src/IO/S3/Client.cpp、src/IO/S3/PocoHTTPClient.cpp说明该类边界处理对上传路径的正确性至关重要。3.2 LDAP 角色重映射期间的死锁原文条目Fixed the deadlock that can happen during LDAP role (re)mapping, when LDAP group is mapped to a nonexistent local role。问题背景ClickHouse 的 LDAP 认证支持把 LDAP 组动态映射到本地角色role从而实现对用户权限的集中管理。此前当映射目标是不存在的本地角色时角色重映射过程可能因加锁顺序问题触发死锁导致访问控制模块卡死。修复效果在 LDAP 角色映射/重映射路径上修复了锁竞争使映射到不存在的角色这类配置错误不再导致服务不可用。源码佐证LDAP 访问存储实现在 src/Access/LDAPAccessStorage.cpp其中setConfiguration在持锁状态下更新 LDAP 服务器配置角色解析、映射与访问控制通知通过 src/Access/ExternalAuthenticators.cpp 联动锁的嵌套获取是死锁风险的典型来源。若你在配置中使用了 LDAP 组到角色的映射建议升级后重点回归验证动态加角色/删角色的场景。3.3 ZooKeeper 断连后的复制队列脏数据与相交虚拟 parts 崩溃原文条目两条If ZooKeeper connection was lost and replica was cloned after restoring the connection, its replication queue might contain outdated entries. Its fixed.Fixed crash when replication queue contains intersecting virtual parts. Print error in log instead of terminating.问题背景ReplicatedMergeTree 的所有变更插入、merge、mutation都先写入 ZooKeeper 的复制日志log各副本通过复制队列replication queue异步拉取执行。存在两类隐患断连后克隆副本副本与 ZooKeeper 连接丢失期间若重新连接后该副本执行了克隆从其他副本复制 part其本地复制队列中可能残留连接中断前的过期条目导致重复执行或与已克隆数据冲突。相交的虚拟 parts复制队列中若出现相互重叠的虚拟 parts通常发生在某数据 part 意外丢失后旧逻辑直接终止进程crash可用性差。修复效果断连场景下清理/校正过期队列条目对相交虚拟 parts 改为记录错误日志而非终止进程提升容错性。复制队列实现位于 src/Storages/MergeTree/ReplicatedMergeTreeQueue.h日志条目结构见 src/Storages/MergeTree/ReplicatedMergeTreeLogEntry.h。若你的集群经历过 ZooKeeper 抖动或 part 丢失这条修复直接关系到能否在不重启副本的情况下自愈。3.4Mutation was killed异常被过早抛出原文条目Fix bug when exceptionMutation was killedcan be thrown to the client on mutation wait when mutation not loaded into memory yet。问题背景执行ALTER TABLE ... DELETE/UPDATE即 mutation时客户端通常需要等待 mutation 完成。此前在 mutation 尚未从 ZooKeeper 加载进副本内存、正等待加载的阶段如果用户取消了等待可能把Mutation was killed异常误抛给客户端产生误导性报错。修复效果修正了 mutation 等待路径的状态判断避免在尚未加载与已被 kill之间误报。mutation 的 ZooKeeper 条目定义见 src/Storages/MergeTree/ReplicatedMergeTreeMutationEntry.h。3.5 低内存服务器上 merge 无法执行需要重启的罕见问题原文条目Fix extremely rare bug on low-memory servers which can lead to the inability to perform merges without restartPossibly fixes #24603。问题背景在内存较小的服务器上merge 任务的调度/执行路径中存在一个罕见缺陷一旦触发所有后续 merge 都无法执行只能通过重启恢复严重影响后台合并吞吐与查询性能未合并 part 增多。修复效果修复后低内存环境下 merge 不再因该缺陷卡死无需重启即可恢复后台合并能力。3.6 Arrow 格式解析的堆缓冲区溢出风险原文条目Fix possible heap-buffer-overflow in Arrow。问题背景Arrow 是 ClickHouse 支持的表格式之一可通过INSERT ... FORMAT Arrow/SELECT ... FORMAT Arrow与 Arrow 生态互操作使用。解析外部传入的 Arrow 数据时存在潜在的堆缓冲区越界读写属于安全与稳定性双相关的缺陷。修复效果对 Arrow 反序列化路径补充边界校验杜绝越界访问。若你的链路中有外部系统以 Arrow 格式写入 ClickHouse建议优先升级并配合回归验证。四、升级与验证建议优先升级场景使用 S3 / Azure 等对象存储并开启 Zero-Copy 复制且配置了多个 volume 的集群使用 LDAP 认证且配置了角色映射的实例经历过 ZooKeeper 断连、part 丢失或复制队列出现异常的副本对外开放 HTTP 上传接口multipart/form-data或以 Arrow 格式接入外部数据的服务。回归测试重点多 S3 volume 下执行SYSTEM SYNC REPLICA并检查各副本 part 元数据一致性配置映射到不存在角色的 LDAP 组验证认证与角色列表展示不卡死断连 ZooKeeper 后重新连接观察复制队列是否有过期条目构造超行数限制的标量子查询确认错误信息如实透出。五、小结v21.6.3.14-stable 是一个典型的稳定化收口补丁没有新功能但每一项修复都直指对象存储复制、LDAP 访问控制、复制队列一致性、mutation 状态机与外部格式解析等生产环境的高频痛点。建议相关场景的用户在充分回归后尽快升级以获得更稳的复制行为与更少的异常崩溃。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ClickHouse v21.6.3.14-stable 补丁版解析：S3 零拷贝复制、LDAP 角色映射与复制队列稳定性修复
ClickHouse v21.6.3.14-stable 补丁版解析S3 零拷贝复制、LDAP 角色映射与复制队列稳定性修复【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse导读本篇文章基于当前仓库 docs/changelogs/archive/v21.6.3.14-stable.md 的发布说明系统梳理 ClickHouse v21.6 系列第二个稳定补丁版v21.6.3.14-stable相对 v21.6.2.7-prestable 引入的全部 2 项改进与 5 项 Bug 修复。文中将逐条还原每个修复对应的技术背景、问题根因与影响范围并结合当前仓库源码如src/Disks/DiskObjectStorage、src/Access/LDAPAccessStorage.cpp、src/Storages/MergeTree等给出源码级佐证帮助读者判断该补丁与自己生产环境的关联程度并据此制定升级与验证策略。一、版本背景stable 补丁版在发布节奏中的定位ClickHouse 的发布流程分为 prestable 与 stable 两条线功能特性先在-prestable版本中合入经过回归验证后进入-stable分支而形如v21.6.3.14-stable的补丁版本则是在主版本发布后针对回归缺陷与高优先级问题的小步快修版本。本补丁直接对比对象是v21.6.2.7-prestable说明它是 v21.6 主版本线在向稳定态收敛过程中的一次集中修复。本补丁值得关注的原因在于修复面覆盖了存储层S3 零拷贝复制、低内存下 merge 失败、访问控制层LDAP 角色映射死锁、复制与数据一致性层ZooKeeper 断连后的复制队列脏数据、HTTP 协议层multipart/form-data 边界解析以及列式格式层Arrow 堆缓冲区溢出属于典型的发布后集中收口版本。二、Improvement两项行为改进2.1 修复多 S3 volume 场景下的 Zero-Copy 复制原文条目Fix Zero-Copy replication with several S3 volumesFixes #22679对应 PR #22864。问题背景零拷贝复制Zero-Copy Replication是 ClickHouse 针对对象存储S3、Azure Blob Storage 等设计的一种复制优化。与本地磁盘复制不同它不把数据 part 实际拷贝到每个副本而是让所有副本共享同一个底层对象存储对象仅通过 ZooKeeper 复制元数据与 part 的引用关系从而大幅节省存储空间与网络开销。问题根因当一张复制表被配置在多个 S3 volume上时不同 part 可能落在不同的 bucket / 存储桶组合中零拷贝复制的元数据路由逻辑若不能正确处理这种多 volume 分布会导致副本间元数据不一致或 part 归属错乱。源码佐证当前仓库 src/Disks/DiskObjectStorage/DiskObjectStorage.h 中定义了supportZeroCopyReplication()/// Keeper metadata replicates itself; in-memory metadata is transient and has no local /// metadata files zero-copy could ship (see getReplicatedFilesDescriptionForRemoteDisk). bool supportZeroCopyReplication() const override { return metadata_storage-getType() ! MetadataStorageType::Keeper metadata_storage-getType() ! MetadataStorageType::Memory; }这说明零拷贝复制的能力与元数据存储类型强绑定Keeper / 内存元数据不支持只有普通对象存储元数据才可启用同一磁盘还需具备将本地路径映射到对象存储对象的元数据机制见 src/Disks/DiskObjectStorage/DiskObjectStorage.h 中关于 metadata 的描述。零拷贝复制是可选配置项生产环境若使用对象存储需在表引擎或磁盘配置中显式开启并验证多 volume 场景下的复制行为。2.2 标量子查询不再吞掉超限错误原文条目Avoid hiding errors likeLimit for rows or bytes to read exceededfor scalar subqueries。问题背景标量子查询scalar subquery要求查询最多返回一行。此前某些内部处理路径会把子查询执行过程中的限制类异常如Limit for rows or bytes to read exceeded即max_rows_to_read/max_bytes_to_read等配额被触达吞掉或改写导致用户无法看到真正的原因。修复效果本补丁后标量子查询在触达行数/字节数读取上限时错误信息能够如实透传给客户端便于定位是数据量问题还是配额配置问题。三、Bug Fix五类稳定性与正确性修复3.1 multipart/form-data 消息中 boundary 前 CRLF 的处理原文条目In multipart/form-data message consider the CRLF preceding a boundary as part of itFixes #23905。问题背景HTTP 接口以multipart/form-data上传数据时boundary分界符之前的 CRLF回车换行在协议语义中属于该消息的一部分。如果解析器忽略这一点可能把分界符前的空行误判为数据内容导致多部分消息的切分错位。修复效果解析逻辑把 boundary 前的 CRLF 纳入边界判定保证各 part 的内容切分严格符合协议。当前仓库中 S3 / 对象存储相关的 HTTP 客户端均包含 multipart 组装与解析逻辑见 src/IO/S3/Client.cpp、src/IO/S3/PocoHTTPClient.cpp说明该类边界处理对上传路径的正确性至关重要。3.2 LDAP 角色重映射期间的死锁原文条目Fixed the deadlock that can happen during LDAP role (re)mapping, when LDAP group is mapped to a nonexistent local role。问题背景ClickHouse 的 LDAP 认证支持把 LDAP 组动态映射到本地角色role从而实现对用户权限的集中管理。此前当映射目标是不存在的本地角色时角色重映射过程可能因加锁顺序问题触发死锁导致访问控制模块卡死。修复效果在 LDAP 角色映射/重映射路径上修复了锁竞争使映射到不存在的角色这类配置错误不再导致服务不可用。源码佐证LDAP 访问存储实现在 src/Access/LDAPAccessStorage.cpp其中setConfiguration在持锁状态下更新 LDAP 服务器配置角色解析、映射与访问控制通知通过 src/Access/ExternalAuthenticators.cpp 联动锁的嵌套获取是死锁风险的典型来源。若你在配置中使用了 LDAP 组到角色的映射建议升级后重点回归验证动态加角色/删角色的场景。3.3 ZooKeeper 断连后的复制队列脏数据与相交虚拟 parts 崩溃原文条目两条If ZooKeeper connection was lost and replica was cloned after restoring the connection, its replication queue might contain outdated entries. Its fixed.Fixed crash when replication queue contains intersecting virtual parts. Print error in log instead of terminating.问题背景ReplicatedMergeTree 的所有变更插入、merge、mutation都先写入 ZooKeeper 的复制日志log各副本通过复制队列replication queue异步拉取执行。存在两类隐患断连后克隆副本副本与 ZooKeeper 连接丢失期间若重新连接后该副本执行了克隆从其他副本复制 part其本地复制队列中可能残留连接中断前的过期条目导致重复执行或与已克隆数据冲突。相交的虚拟 parts复制队列中若出现相互重叠的虚拟 parts通常发生在某数据 part 意外丢失后旧逻辑直接终止进程crash可用性差。修复效果断连场景下清理/校正过期队列条目对相交虚拟 parts 改为记录错误日志而非终止进程提升容错性。复制队列实现位于 src/Storages/MergeTree/ReplicatedMergeTreeQueue.h日志条目结构见 src/Storages/MergeTree/ReplicatedMergeTreeLogEntry.h。若你的集群经历过 ZooKeeper 抖动或 part 丢失这条修复直接关系到能否在不重启副本的情况下自愈。3.4Mutation was killed异常被过早抛出原文条目Fix bug when exceptionMutation was killedcan be thrown to the client on mutation wait when mutation not loaded into memory yet。问题背景执行ALTER TABLE ... DELETE/UPDATE即 mutation时客户端通常需要等待 mutation 完成。此前在 mutation 尚未从 ZooKeeper 加载进副本内存、正等待加载的阶段如果用户取消了等待可能把Mutation was killed异常误抛给客户端产生误导性报错。修复效果修正了 mutation 等待路径的状态判断避免在尚未加载与已被 kill之间误报。mutation 的 ZooKeeper 条目定义见 src/Storages/MergeTree/ReplicatedMergeTreeMutationEntry.h。3.5 低内存服务器上 merge 无法执行需要重启的罕见问题原文条目Fix extremely rare bug on low-memory servers which can lead to the inability to perform merges without restartPossibly fixes #24603。问题背景在内存较小的服务器上merge 任务的调度/执行路径中存在一个罕见缺陷一旦触发所有后续 merge 都无法执行只能通过重启恢复严重影响后台合并吞吐与查询性能未合并 part 增多。修复效果修复后低内存环境下 merge 不再因该缺陷卡死无需重启即可恢复后台合并能力。3.6 Arrow 格式解析的堆缓冲区溢出风险原文条目Fix possible heap-buffer-overflow in Arrow。问题背景Arrow 是 ClickHouse 支持的表格式之一可通过INSERT ... FORMAT Arrow/SELECT ... FORMAT Arrow与 Arrow 生态互操作使用。解析外部传入的 Arrow 数据时存在潜在的堆缓冲区越界读写属于安全与稳定性双相关的缺陷。修复效果对 Arrow 反序列化路径补充边界校验杜绝越界访问。若你的链路中有外部系统以 Arrow 格式写入 ClickHouse建议优先升级并配合回归验证。四、升级与验证建议优先升级场景使用 S3 / Azure 等对象存储并开启 Zero-Copy 复制且配置了多个 volume 的集群使用 LDAP 认证且配置了角色映射的实例经历过 ZooKeeper 断连、part 丢失或复制队列出现异常的副本对外开放 HTTP 上传接口multipart/form-data或以 Arrow 格式接入外部数据的服务。回归测试重点多 S3 volume 下执行SYSTEM SYNC REPLICA并检查各副本 part 元数据一致性配置映射到不存在角色的 LDAP 组验证认证与角色列表展示不卡死断连 ZooKeeper 后重新连接观察复制队列是否有过期条目构造超行数限制的标量子查询确认错误信息如实透出。五、小结v21.6.3.14-stable 是一个典型的稳定化收口补丁没有新功能但每一项修复都直指对象存储复制、LDAP 访问控制、复制队列一致性、mutation 状态机与外部格式解析等生产环境的高频痛点。建议相关场景的用户在充分回归后尽快升级以获得更稳的复制行为与更少的异常崩溃。【免费下载链接】ClickHouseClickHouse® is a real-time analytics database management system项目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考