布說明詳解：S3 代理兼容性與 9 項(xiàng)穩(wěn)定性修復(fù))
ClickHouse v20.10.4.1-stable 發(fā)布說明詳解S3 代理兼容性與 9 項(xiàng)穩(wěn)定性修復(fù)【免費(fèi)下載鏈接】ClickHouseClickHouse? is a real-time analytics database management system項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本篇技術(shù)文章基于 ClickHouse 官方版本說明v20.10.4.1-stable相對(duì)上一穩(wěn)定版 v20.10.3.30-stable逐條解讀該版本的 1 項(xiàng)改進(jìn)與 9 項(xiàng)缺陷修復(fù)。讀完后你將了解該版本在 S3 訪問路徑兼容、MySQL/MaterializeMySQL 引擎、Distributed 表、Avro 輸入解析與查詢執(zhí)行層等方面修復(fù)了哪些具體問題并結(jié)合當(dāng)前倉(cāng)庫(kù)源碼定位每一類修復(fù)對(duì)應(yīng)的實(shí)現(xiàn)位置幫助你判斷生產(chǎn)環(huán)境是否需要升級(jí)到該補(bǔ)丁版本。版本概覽本版本是 v20.10.3.30-stable 之后的穩(wěn)定性補(bǔ)丁版本stable 分支維護(hù)發(fā)布說明中未包含新功能或 breaking change全部為Improvement改進(jìn)與Bug Fix缺陷修復(fù)兩類條目。對(duì)于使用 v20.10 系列穩(wěn)定版的用戶這類版本通常只包含向后兼容的缺陷修復(fù)是生產(chǎn)環(huán)境中風(fēng)險(xiǎn)較低的升級(jí)目標(biāo)。改進(jìn)S3 經(jīng) Nginx 反向代理訪問的 URL 兼容性本版本唯一的改進(jìn)項(xiàng)是一個(gè)workaround變通修復(fù)解決 ClickHouse 通過 Nginx 反向代理訪問 S3 兼容對(duì)象存儲(chǔ)時(shí)的 URL 格式問題問題背景當(dāng)前版本的 Nginx 不接受空 path 的 URL例如http://domain.com?delete而原版 aws-sdk-cpp 在構(gòu)造刪除對(duì)象等請(qǐng)求時(shí)恰好會(huì)生成這種空 path URL。修復(fù)方式該版本使用了打過補(bǔ)丁的 aws-sdk-cpp在此類場(chǎng)景下將 path 補(bǔ)為/例如生成http://domain.com/?delete從而讓 Nginx 能正確轉(zhuǎn)發(fā)刪除請(qǐng)求。來源發(fā)布說明標(biāo)注對(duì)應(yīng)提交為 PR #16813作者 ianton-ru。適用前提與限制該 workaround 僅影響通過 Nginx 代理訪問 S3這一部署形態(tài)。直連 S3 或 S3 兼容存儲(chǔ)的用戶不受影響如果你的對(duì)象存儲(chǔ)網(wǎng)關(guān)對(duì)?delete這類 URL 有其它要求需要另行驗(yàn)證。當(dāng)前倉(cāng)庫(kù)中第三方依賴由contrib/aws-cmake/下的 CMake 集成腳本管理S3 讀寫路徑的頂層實(shí)現(xiàn)在src/Disks/目錄DiskObjectStorage、S3 相關(guān) Disk 類該改進(jìn)通過替換/修補(bǔ) aws-sdk-cpp 依賴而非修改 ClickHouse 自身 Disk 層代碼來實(shí)現(xiàn)這也是此類第三方 SDK 兼容性問題通常的處理方式。缺陷修復(fù)1/9MySQL 引擎在下游服務(wù)器宕機(jī)時(shí)不應(yīng)被牽連問題當(dāng) ClickHouse 使用 MySQL 作為數(shù)據(jù)庫(kù)引擎MySQLengine且遠(yuǎn)端 MySQL 服務(wù)器宕機(jī)時(shí)一些本不該訪問 MySQL 的查詢也會(huì)拋出異?！?yàn)樗鼈內(nèi)詴?huì)嘗試從已失效的服務(wù)器獲取表列表。發(fā)布說明給出的典型例子是SELECT ... FROM system.parts這類只應(yīng)作用于 MergeTree 表的查詢根本不應(yīng)觸碰 MySQL 數(shù)據(jù)庫(kù)。源碼佐證當(dāng)前倉(cāng)庫(kù)中該數(shù)據(jù)庫(kù)引擎的實(shí)現(xiàn)位于 DatabaseMySQL.h其中DatabaseMySQL類約 L41繼承自DatabaseWithAltersOnDiskBase。該修復(fù)屬于按需獲取表元數(shù)據(jù)的行為修正只有真正需要讀取該庫(kù)表結(jié)構(gòu)的查詢路徑才觸發(fā)遠(yuǎn)端元數(shù)據(jù)請(qǐng)求避免了單點(diǎn)故障對(duì)無關(guān)查詢的傳染。缺陷修復(fù)2/9過濾集合未創(chuàng)建導(dǎo)致返回?cái)?shù)據(jù)部分丟失修復(fù)了返回?cái)?shù)據(jù)的一部分可能被意外丟棄的不一致行為原因是用于數(shù)據(jù)過濾的集合set尚未創(chuàng)建。對(duì)應(yīng) PR #16308作者 Nikita Mikhaylov。這類問題通常表現(xiàn)為同一查詢重復(fù)執(zhí)行結(jié)果行數(shù)不一致排查困難該修復(fù)屬于查詢執(zhí)行層的狀態(tài)初始化順序修正。缺陷修復(fù)3/9復(fù)制隊(duì)列中超大條目的處理超大表結(jié)構(gòu) ALTER問題復(fù)制隊(duì)列replication queue中出現(xiàn)超大條目時(shí)處理失敗。此類條目可能出現(xiàn)在 ALTER 查詢中——當(dāng)表結(jié)構(gòu)極大接近 1 MB時(shí)ZooKeeper 中記錄的操作元數(shù)據(jù)會(huì)超出常規(guī)假設(shè)。源碼佐證當(dāng)前倉(cāng)庫(kù)中復(fù)制隊(duì)列與副本同步的核心實(shí)現(xiàn)位于src/Storages/MergeTree/目錄例如 ReplicatedMergeTree 相關(guān)部分 所在的 Compaction 子目錄以及數(shù)據(jù)塊交換邏輯 DataPartsExchange。從源碼結(jié)構(gòu)看該修復(fù)擴(kuò)大了復(fù)制隊(duì)列條目序列化/反序列化對(duì)大 payload 的容忍度避免大 ALTER 語(yǔ)句在副本間同步時(shí)失敗。適用提示如果你的 MergeTree 表列數(shù)極多例如數(shù)千篇列的寬表副本節(jié)點(diǎn)同步此類 ALTER 時(shí)曾出現(xiàn)異常升級(jí)到包含本修復(fù)的版本是直接的解決途徑。缺陷修復(fù)4/9DROP TABLE 作用于 Distributed 表時(shí)與 INSERT 的競(jìng)態(tài)問題對(duì) Distributed 表執(zhí)行 DROP TABLE 時(shí)如果同時(shí)有 INSERT 正在進(jìn)行兩者存在競(jìng)態(tài)racy可能導(dǎo)致未定義行為或異常。對(duì)應(yīng) PR #16409作者 Azat Khuzhin。Distributed 表的寫入路徑會(huì)經(jīng)過本地臨時(shí)存儲(chǔ)再異步/同步分發(fā)到遠(yuǎn)端分片drop 與 write 并發(fā)時(shí)的資源回收順序是該類競(jìng)態(tài)的典型來源。該修復(fù)屬于并發(fā)正確性問題對(duì)高頻建刪表的場(chǎng)景如按 TTL 批量滾動(dòng)表、測(cè)試環(huán)境反復(fù)初始化有實(shí)際價(jià)值。缺陷修復(fù)5/9MaterializeMySQL 鏈路中 GTID 集合膨脹問題在MySQL Master - MySQL Slave - ClickHouse的 MaterializeMySQL 同步鏈路中如果 MySQL Slave 上開啟了slave_parallel_workerClickHouse 側(cè)元數(shù)據(jù)會(huì)快速膨脹。原因是并行復(fù)制產(chǎn)生的 GTID 集合沒有被正確收縮shrinking導(dǎo)致元數(shù)據(jù)持續(xù)累積。修復(fù)方式通過正確收縮 GTID 集合解決對(duì)應(yīng) PR #16504作者 TCeason。適用前提該修復(fù)針對(duì)的是多主/并行復(fù)制parallel replication環(huán)境下的增量同步單線程復(fù)制的 GTID 集合天然緊湊不易觸發(fā)此問題。使用 MaterializeMySQL 引擎的用戶若監(jiān)控到系統(tǒng)元數(shù)據(jù)目錄體積異常增長(zhǎng)可對(duì)照本條目排查。缺陷修復(fù)6/9Avro 輸入解析時(shí)移除 LowCardinality 包裝解析 Avro 輸入數(shù)據(jù)時(shí)目標(biāo)列類型中的LowCardinality包裝會(huì)被去掉后再做類型匹配。此前該行為會(huì)導(dǎo)致 Avro 數(shù)據(jù)導(dǎo)入目標(biāo)LowCardinality(...)列時(shí)出現(xiàn)類型不匹配問題。對(duì)應(yīng) PR #16521作者 Mike Kot。當(dāng)前倉(cāng)庫(kù)的 Avro 輸入格式實(shí)現(xiàn)位于src/Formats/目錄AvroRowInputFormat 相關(guān)文件該修復(fù)屬于輸入層類型歸一化邏輯對(duì)通過INSERT INTO ... FORMAT Avro或file()表函數(shù)導(dǎo)入 Avro 數(shù)據(jù)的用戶是兼容性修正。缺陷修復(fù)7/9修復(fù) #16081 關(guān)聯(lián)問題該條目為對(duì) issue #16081 的修復(fù)對(duì)應(yīng) PR #16613作者 Nikita Mikhaylov發(fā)布說明未附詳細(xì)描述屬于常規(guī)缺陷修復(fù)的 backport。若你的工作流涉及相關(guān) issue 場(chǎng)景可在升級(jí)后針對(duì)性回歸驗(yàn)證。缺陷修復(fù)8/9ORDER BY 含表達(dá)式時(shí)按序讀優(yōu)化失效問題optimize_read_in_order/optimize_aggregation_in_order兩個(gè)優(yōu)化在max_threads 0且ORDER BY中是表達(dá)式而非裸列時(shí)會(huì)失效。對(duì)應(yīng) PR #16637作者 Azat Khuzhin。源碼佐證當(dāng)前倉(cāng)庫(kù)中該設(shè)置項(xiàng)定義于 Settings.cpp默認(rèn)值為true用于讓SELECT ... ORDER BY按排序鍵順序讀取數(shù)據(jù)以避免全局排序。修復(fù)之后形如ORDER BY toDate(timestamp_col) DESC這類表達(dá)式排序也能正確走按序讀取優(yōu)化路徑對(duì)大結(jié)果集查詢的內(nèi)存占用與延遲有直接改善。缺陷修復(fù)9/9atransform_null_in 開啟后 IN 多列/元組比較出錯(cuò)問題當(dāng)設(shè)置transform_null_in開啟時(shí)IN運(yùn)算符作用于多列/元組tuple的比較結(jié)果不正確。對(duì)應(yīng) PR #16722作者 Anton Popov。源碼佐證transform_null_in同樣定義于 Settings.cpp作用是在IN右操作數(shù)為子查詢時(shí)把 NULL 值從結(jié)果中剔除因?yàn)?SQL 語(yǔ)義下x IN (NULL, ...)結(jié)果應(yīng)為 NULL 而非匹配。該修復(fù)覆蓋了IN 右側(cè)是多個(gè)列或 tuple 子查詢這一分支屬于 NULL 語(yǔ)義正確性問題對(duì)開啟該設(shè)置的精確去重/半連接查詢場(chǎng)景有實(shí)際影響。缺陷修復(fù)9/9b查詢分析器開啟時(shí)在特定 glibc 下罕見靜默崩潰問題開啟查詢分析器query profiler時(shí)在部分 glibc 版本的操作系統(tǒng)上會(huì)出現(xiàn)罕見的靜默崩潰silent crash。根因是指定 glibc 版本中某些函數(shù)的**異步展開表asynchronous unwind tables**存在缺陷導(dǎo)致棧回溯時(shí)讀取了損壞的展開信息。對(duì)應(yīng) PR #16846作者 Alexey Milovidov。排查與規(guī)避建議典型癥狀是開啟enable_analyzer相關(guān)功能或查詢剖析后偶發(fā)崩潰、且沒有常規(guī)異常日志若你的發(fā)行版 glibc 屬于受影響版本升級(jí)到包含本修復(fù)的補(bǔ)丁版本即可ClickHouse 側(cè)對(duì)損壞的展開表做了防御性處理。升級(jí)建議與小結(jié)v20.10.4.1-stable是一個(gè)典型的穩(wěn)定性補(bǔ)丁版本按影響面可歸納為三條主線外部系統(tǒng)集成S3 經(jīng) Nginx 代理的 URL 兼容性Improvement、MySQL / MaterializeMySQL 引擎的可用性修復(fù)數(shù)據(jù)正確性過濾集合缺失導(dǎo)致數(shù)據(jù)丟失、transform_null_in下 IN 元組比較、Avro 解析 LowCardinality 類型匹配并發(fā)與魯棒性Distributed 表 DROP/INSERT 競(jìng)態(tài)、復(fù)制隊(duì)列超大條目、按序讀優(yōu)化在表達(dá)式排序下失效、特定 glibc 下的剖析器崩潰。如果你在 v20.10.3.30-stable 上遇到上述任一癥狀尤其是 S3 代理部署、超大寬表副本同步、MySQL 鏈路元數(shù)據(jù)膨脹升級(jí)到v20.10.4.1-stable是對(duì)應(yīng)的修復(fù)版本由于本版本不引入新功能升級(jí)回歸成本較低。本文所有修復(fù)條目均以官方發(fā)布說明為準(zhǔn)實(shí)現(xiàn)位置佐證來自當(dāng)前倉(cāng)庫(kù)對(duì)應(yīng)模塊的源碼結(jié)構(gòu)供進(jìn)一步深入閱讀參考?！久赓M(fèi)下載鏈接】ClickHouseClickHouse? is a real-time analytics database management system項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 ClickHouse v20.10.4.1-stable 發(fā)布說明詳解：S3 代理兼容性與 9 項(xiàng)穩(wěn)定性修復(fù)
ClickHouse v20.10.4.1-stable 發(fā)布說明詳解S3 代理兼容性與 9 項(xiàng)穩(wěn)定性修復(fù)【免費(fèi)下載鏈接】ClickHouseClickHouse? is a real-time analytics database management system項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse本篇技術(shù)文章基于 ClickHouse 官方版本說明v20.10.4.1-stable相對(duì)上一穩(wěn)定版 v20.10.3.30-stable逐條解讀該版本的 1 項(xiàng)改進(jìn)與 9 項(xiàng)缺陷修復(fù)。讀完后你將了解該版本在 S3 訪問路徑兼容、MySQL/MaterializeMySQL 引擎、Distributed 表、Avro 輸入解析與查詢執(zhí)行層等方面修復(fù)了哪些具體問題并結(jié)合當(dāng)前倉(cāng)庫(kù)源碼定位每一類修復(fù)對(duì)應(yīng)的實(shí)現(xiàn)位置幫助你判斷生產(chǎn)環(huán)境是否需要升級(jí)到該補(bǔ)丁版本。版本概覽本版本是 v20.10.3.30-stable 之后的穩(wěn)定性補(bǔ)丁版本stable 分支維護(hù)發(fā)布說明中未包含新功能或 breaking change全部為Improvement改進(jìn)與Bug Fix缺陷修復(fù)兩類條目。對(duì)于使用 v20.10 系列穩(wěn)定版的用戶這類版本通常只包含向后兼容的缺陷修復(fù)是生產(chǎn)環(huán)境中風(fēng)險(xiǎn)較低的升級(jí)目標(biāo)。改進(jìn)S3 經(jīng) Nginx 反向代理訪問的 URL 兼容性本版本唯一的改進(jìn)項(xiàng)是一個(gè)workaround變通修復(fù)解決 ClickHouse 通過 Nginx 反向代理訪問 S3 兼容對(duì)象存儲(chǔ)時(shí)的 URL 格式問題問題背景當(dāng)前版本的 Nginx 不接受空 path 的 URL例如http://domain.com?delete而原版 aws-sdk-cpp 在構(gòu)造刪除對(duì)象等請(qǐng)求時(shí)恰好會(huì)生成這種空 path URL。修復(fù)方式該版本使用了打過補(bǔ)丁的 aws-sdk-cpp在此類場(chǎng)景下將 path 補(bǔ)為/例如生成http://domain.com/?delete從而讓 Nginx 能正確轉(zhuǎn)發(fā)刪除請(qǐng)求。來源發(fā)布說明標(biāo)注對(duì)應(yīng)提交為 PR #16813作者 ianton-ru。適用前提與限制該 workaround 僅影響通過 Nginx 代理訪問 S3這一部署形態(tài)。直連 S3 或 S3 兼容存儲(chǔ)的用戶不受影響如果你的對(duì)象存儲(chǔ)網(wǎng)關(guān)對(duì)?delete這類 URL 有其它要求需要另行驗(yàn)證。當(dāng)前倉(cāng)庫(kù)中第三方依賴由contrib/aws-cmake/下的 CMake 集成腳本管理S3 讀寫路徑的頂層實(shí)現(xiàn)在src/Disks/目錄DiskObjectStorage、S3 相關(guān) Disk 類該改進(jìn)通過替換/修補(bǔ) aws-sdk-cpp 依賴而非修改 ClickHouse 自身 Disk 層代碼來實(shí)現(xiàn)這也是此類第三方 SDK 兼容性問題通常的處理方式。缺陷修復(fù)1/9MySQL 引擎在下游服務(wù)器宕機(jī)時(shí)不應(yīng)被牽連問題當(dāng) ClickHouse 使用 MySQL 作為數(shù)據(jù)庫(kù)引擎MySQLengine且遠(yuǎn)端 MySQL 服務(wù)器宕機(jī)時(shí)一些本不該訪問 MySQL 的查詢也會(huì)拋出異?！?yàn)樗鼈內(nèi)詴?huì)嘗試從已失效的服務(wù)器獲取表列表。發(fā)布說明給出的典型例子是SELECT ... FROM system.parts這類只應(yīng)作用于 MergeTree 表的查詢根本不應(yīng)觸碰 MySQL 數(shù)據(jù)庫(kù)。源碼佐證當(dāng)前倉(cāng)庫(kù)中該數(shù)據(jù)庫(kù)引擎的實(shí)現(xiàn)位于 DatabaseMySQL.h其中DatabaseMySQL類約 L41繼承自DatabaseWithAltersOnDiskBase。該修復(fù)屬于按需獲取表元數(shù)據(jù)的行為修正只有真正需要讀取該庫(kù)表結(jié)構(gòu)的查詢路徑才觸發(fā)遠(yuǎn)端元數(shù)據(jù)請(qǐng)求避免了單點(diǎn)故障對(duì)無關(guān)查詢的傳染。缺陷修復(fù)2/9過濾集合未創(chuàng)建導(dǎo)致返回?cái)?shù)據(jù)部分丟失修復(fù)了返回?cái)?shù)據(jù)的一部分可能被意外丟棄的不一致行為原因是用于數(shù)據(jù)過濾的集合set尚未創(chuàng)建。對(duì)應(yīng) PR #16308作者 Nikita Mikhaylov。這類問題通常表現(xiàn)為同一查詢重復(fù)執(zhí)行結(jié)果行數(shù)不一致排查困難該修復(fù)屬于查詢執(zhí)行層的狀態(tài)初始化順序修正。缺陷修復(fù)3/9復(fù)制隊(duì)列中超大條目的處理超大表結(jié)構(gòu) ALTER問題復(fù)制隊(duì)列replication queue中出現(xiàn)超大條目時(shí)處理失敗。此類條目可能出現(xiàn)在 ALTER 查詢中——當(dāng)表結(jié)構(gòu)極大接近 1 MB時(shí)ZooKeeper 中記錄的操作元數(shù)據(jù)會(huì)超出常規(guī)假設(shè)。源碼佐證當(dāng)前倉(cāng)庫(kù)中復(fù)制隊(duì)列與副本同步的核心實(shí)現(xiàn)位于src/Storages/MergeTree/目錄例如 ReplicatedMergeTree 相關(guān)部分 所在的 Compaction 子目錄以及數(shù)據(jù)塊交換邏輯 DataPartsExchange。從源碼結(jié)構(gòu)看該修復(fù)擴(kuò)大了復(fù)制隊(duì)列條目序列化/反序列化對(duì)大 payload 的容忍度避免大 ALTER 語(yǔ)句在副本間同步時(shí)失敗。適用提示如果你的 MergeTree 表列數(shù)極多例如數(shù)千篇列的寬表副本節(jié)點(diǎn)同步此類 ALTER 時(shí)曾出現(xiàn)異常升級(jí)到包含本修復(fù)的版本是直接的解決途徑。缺陷修復(fù)4/9DROP TABLE 作用于 Distributed 表時(shí)與 INSERT 的競(jìng)態(tài)問題對(duì) Distributed 表執(zhí)行 DROP TABLE 時(shí)如果同時(shí)有 INSERT 正在進(jìn)行兩者存在競(jìng)態(tài)racy可能導(dǎo)致未定義行為或異常。對(duì)應(yīng) PR #16409作者 Azat Khuzhin。Distributed 表的寫入路徑會(huì)經(jīng)過本地臨時(shí)存儲(chǔ)再異步/同步分發(fā)到遠(yuǎn)端分片drop 與 write 并發(fā)時(shí)的資源回收順序是該類競(jìng)態(tài)的典型來源。該修復(fù)屬于并發(fā)正確性問題對(duì)高頻建刪表的場(chǎng)景如按 TTL 批量滾動(dòng)表、測(cè)試環(huán)境反復(fù)初始化有實(shí)際價(jià)值。缺陷修復(fù)5/9MaterializeMySQL 鏈路中 GTID 集合膨脹問題在MySQL Master - MySQL Slave - ClickHouse的 MaterializeMySQL 同步鏈路中如果 MySQL Slave 上開啟了slave_parallel_workerClickHouse 側(cè)元數(shù)據(jù)會(huì)快速膨脹。原因是并行復(fù)制產(chǎn)生的 GTID 集合沒有被正確收縮shrinking導(dǎo)致元數(shù)據(jù)持續(xù)累積。修復(fù)方式通過正確收縮 GTID 集合解決對(duì)應(yīng) PR #16504作者 TCeason。適用前提該修復(fù)針對(duì)的是多主/并行復(fù)制parallel replication環(huán)境下的增量同步單線程復(fù)制的 GTID 集合天然緊湊不易觸發(fā)此問題。使用 MaterializeMySQL 引擎的用戶若監(jiān)控到系統(tǒng)元數(shù)據(jù)目錄體積異常增長(zhǎng)可對(duì)照本條目排查。缺陷修復(fù)6/9Avro 輸入解析時(shí)移除 LowCardinality 包裝解析 Avro 輸入數(shù)據(jù)時(shí)目標(biāo)列類型中的LowCardinality包裝會(huì)被去掉后再做類型匹配。此前該行為會(huì)導(dǎo)致 Avro 數(shù)據(jù)導(dǎo)入目標(biāo)LowCardinality(...)列時(shí)出現(xiàn)類型不匹配問題。對(duì)應(yīng) PR #16521作者 Mike Kot。當(dāng)前倉(cāng)庫(kù)的 Avro 輸入格式實(shí)現(xiàn)位于src/Formats/目錄AvroRowInputFormat 相關(guān)文件該修復(fù)屬于輸入層類型歸一化邏輯對(duì)通過INSERT INTO ... FORMAT Avro或file()表函數(shù)導(dǎo)入 Avro 數(shù)據(jù)的用戶是兼容性修正。缺陷修復(fù)7/9修復(fù) #16081 關(guān)聯(lián)問題該條目為對(duì) issue #16081 的修復(fù)對(duì)應(yīng) PR #16613作者 Nikita Mikhaylov發(fā)布說明未附詳細(xì)描述屬于常規(guī)缺陷修復(fù)的 backport。若你的工作流涉及相關(guān) issue 場(chǎng)景可在升級(jí)后針對(duì)性回歸驗(yàn)證。缺陷修復(fù)8/9ORDER BY 含表達(dá)式時(shí)按序讀優(yōu)化失效問題optimize_read_in_order/optimize_aggregation_in_order兩個(gè)優(yōu)化在max_threads 0且ORDER BY中是表達(dá)式而非裸列時(shí)會(huì)失效。對(duì)應(yīng) PR #16637作者 Azat Khuzhin。源碼佐證當(dāng)前倉(cāng)庫(kù)中該設(shè)置項(xiàng)定義于 Settings.cpp默認(rèn)值為true用于讓SELECT ... ORDER BY按排序鍵順序讀取數(shù)據(jù)以避免全局排序。修復(fù)之后形如ORDER BY toDate(timestamp_col) DESC這類表達(dá)式排序也能正確走按序讀取優(yōu)化路徑對(duì)大結(jié)果集查詢的內(nèi)存占用與延遲有直接改善。缺陷修復(fù)9/9atransform_null_in 開啟后 IN 多列/元組比較出錯(cuò)問題當(dāng)設(shè)置transform_null_in開啟時(shí)IN運(yùn)算符作用于多列/元組tuple的比較結(jié)果不正確。對(duì)應(yīng) PR #16722作者 Anton Popov。源碼佐證transform_null_in同樣定義于 Settings.cpp作用是在IN右操作數(shù)為子查詢時(shí)把 NULL 值從結(jié)果中剔除因?yàn)?SQL 語(yǔ)義下x IN (NULL, ...)結(jié)果應(yīng)為 NULL 而非匹配。該修復(fù)覆蓋了IN 右側(cè)是多個(gè)列或 tuple 子查詢這一分支屬于 NULL 語(yǔ)義正確性問題對(duì)開啟該設(shè)置的精確去重/半連接查詢場(chǎng)景有實(shí)際影響。缺陷修復(fù)9/9b查詢分析器開啟時(shí)在特定 glibc 下罕見靜默崩潰問題開啟查詢分析器query profiler時(shí)在部分 glibc 版本的操作系統(tǒng)上會(huì)出現(xiàn)罕見的靜默崩潰silent crash。根因是指定 glibc 版本中某些函數(shù)的**異步展開表asynchronous unwind tables**存在缺陷導(dǎo)致棧回溯時(shí)讀取了損壞的展開信息。對(duì)應(yīng) PR #16846作者 Alexey Milovidov。排查與規(guī)避建議典型癥狀是開啟enable_analyzer相關(guān)功能或查詢剖析后偶發(fā)崩潰、且沒有常規(guī)異常日志若你的發(fā)行版 glibc 屬于受影響版本升級(jí)到包含本修復(fù)的補(bǔ)丁版本即可ClickHouse 側(cè)對(duì)損壞的展開表做了防御性處理。升級(jí)建議與小結(jié)v20.10.4.1-stable是一個(gè)典型的穩(wěn)定性補(bǔ)丁版本按影響面可歸納為三條主線外部系統(tǒng)集成S3 經(jīng) Nginx 代理的 URL 兼容性Improvement、MySQL / MaterializeMySQL 引擎的可用性修復(fù)數(shù)據(jù)正確性過濾集合缺失導(dǎo)致數(shù)據(jù)丟失、transform_null_in下 IN 元組比較、Avro 解析 LowCardinality 類型匹配并發(fā)與魯棒性Distributed 表 DROP/INSERT 競(jìng)態(tài)、復(fù)制隊(duì)列超大條目、按序讀優(yōu)化在表達(dá)式排序下失效、特定 glibc 下的剖析器崩潰。如果你在 v20.10.3.30-stable 上遇到上述任一癥狀尤其是 S3 代理部署、超大寬表副本同步、MySQL 鏈路元數(shù)據(jù)膨脹升級(jí)到v20.10.4.1-stable是對(duì)應(yīng)的修復(fù)版本由于本版本不引入新功能升級(jí)回歸成本較低。本文所有修復(fù)條目均以官方發(fā)布說明為準(zhǔn)實(shí)現(xiàn)位置佐證來自當(dāng)前倉(cāng)庫(kù)對(duì)應(yīng)模塊的源碼結(jié)構(gòu)供進(jìn)一步深入閱讀參考?！久赓M(fèi)下載鏈接】ClickHouseClickHouse? is a real-time analytics database management system項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cli/ClickHouse創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考