本文匯總了雲資料庫ClickHouse的常見問題及解決方案。
選型與購買
擴容與縮容
串連
遷移與同步
資料寫入與查詢
資料存放區
監控、升級、系統參數
雲資料庫ClickHouse和官方版本對比多了哪些功能和特性?
雲資料庫ClickHouse主要對社區版本進行穩定性Bug修複,同時提供資源隊列進行使用者角色層級的資源使用優先順序配置。
購買雲資料庫ClickHouse執行個體時,推薦選擇哪一個版本?
雲資料庫ClickHouse根據開源社區公開的LTS核心穩定版提供服務,通常在版本推出3個月相對穩定後啟動雲端服務售賣。當前建議購買21.8及以上版本。更多版本功能對比,請參見版本功能對比。
單雙副本執行個體各有什麼特點?
單副本執行個體每一個Shard節點無副本節點,無高可用服務保障。資料安全性雲端式盤多副本儲存,性價比高。
雙副本執行個體每一個Shard節點對應一個副本服務節點,在主節點故障不能提供服務時副本節點可提供容災服務支援。
購買鏈路資源時顯示“目前範圍資源不足”,應該如何處理?
解決方案:您可以選擇同地區的其他地區購買。VPC網路支援相同地區不同可用性區域之間打通,同地區網路延遲無感知。
水平擴縮容耗時受什麼影響?
水平擴縮容過程涉及資料搬遷,執行個體裡面資料越多搬得越多,耗時時間越長。
擴縮容期間對執行個體有什麼影響?
為保證擴縮容中資料搬遷後的資料一致性,擴縮容期間執行個體處於可讀不可寫狀態。
水平擴縮容升級有什麼建議?
水平擴縮容耗時較長,當叢集效能不滿足時,請優先選擇垂直升配。如何進行垂直升配,請參見社區相容版叢集垂直變更配置和水平擴縮容。
每個連接埠的含義是什嗎?
協議 | 連接埠號碼 | 適用情境 |
TCP | 3306 | 使用clickhouse-client工具串連雲資料庫ClickHouse時配置,詳細操作請參見通過命令列工具串連ClickHouse。 |
HTTP | 8123 | 使用JDBC方式串連雲資料庫ClickHouse時配置進行應用開發,詳細操作請參見通過JDBC方式串連ClickHouse。 |
HTTPS | 8443 | 使用HTTPS協議訪問雲資料庫ClickHouse時配置,詳細操作請參見通過HTTPS協議串連ClickHouse。 |
每種開發語言通過SDK串連雲資料庫ClickHouse對應的連接埠是什嗎?
開發語言 | HTTP協議 | TCP協議 |
Java | 8123 | 3306 |
Python | ||
Go |
Go、Python語言對應推薦什麼SDK?
詳情請參見第三方開發庫。
如何處理用戶端工具串連叢集時報錯:connect timed out?
為什麼MySQL、HDFS、Kafka等外表無法連通?
目前20.3和20.8版本在建立相關外表時程式內會自動進行驗證,如果建立表成功,那說明網路是通的。如果無法建立成功,常見原因如下。
目標端和ClickHouse不在同一個VPC內,網路無法連通。
MySQL端存在白名單相關設定,需要在MySQL端添加ClickHouse的白名單。
對於Kafka外表,表建立成功,但查詢沒有結果。常見原因是Kafka中資料通過表結構給出的欄位和格式解析失敗,報錯資訊會給出解析失敗的具體位置。
為什麼程式無法串連ClickHouse?
常見原因及解決方案如下。
常見原因1:VPC網路、公網網路環境不對。同一VPC內可用內網串連,不在同一VPC內需開設公網後串連。
解決方案:開通公網詳情請參見申請和釋放外網地址。
常見原因2:白名單未配置。
解決方案:設定白名單詳情請參見設定白名單。
常見原因3:ECS安全性群組未放開。
解決方案:開放安全性群組詳情請參見安全性群組操作指引。
常見原因4:公司設定了網路防火牆。
解決方案:修改防火牆規則。
常見原因5:串連串中的帳號密碼包含特殊字元
!@#$%^&*()_+=
,這些特殊字元在串連時無法被識別,導致執行個體串連失敗。解決辦法:您需要在串連串中對特殊字元進行轉義處理,轉義規則如下。
! : %21 @ : %40 # : %23 $ : %24 % : %25 ^ : %5e & : %26 * : %2a ( : %28 ) : %29 _ : %5f + : %2b = : %3d
樣本:密碼為
ab@#c
時,在串連串中對特殊字元進行轉義處理,密碼對應為ab%40%23c
。常見原因6:雲資料庫ClickHouse會預設為您掛載CLB。CLB為隨用隨付,如果您的帳號欠費可能會導致您的雲資料庫ClickHouse無法訪問。
解決辦法:查詢阿里雲帳號是否欠費。如果欠費請及時進行繳費。
如何處理ClickHouse逾時問題?
雲資料庫ClickHouse核心中有很多逾時相關的參數設定,並且提供了多種協議進行互動,例如您可以設定HTTP協議和TCP協議的相關參數處理雲資料庫ClickHouse逾時問題。
HTTP協議
HTTP協議是雲資料庫ClickHouse在生產環境中最常使用的互動方式,包括官方提供的jdbc driver、阿里雲DMS、DataGrip,後台使用的都是HTTP協議。HTTP協議常用的連接埠號碼為8123。
如何處理distributed_ddl_task_timeout逾時問題
分布式DDL查詢(帶有 on cluster)的執行等待時間,系統預設是180s。您可以在DMS上執行以下命令來設定全域參數,設定後需要重啟叢集。
set global on cluster default distributed_ddl_task_timeout = 1800;
由於分布式DDL是基於ZooKeeper構建任務隊列非同步執行,執行等待逾時並不代表查詢失敗,只表示之前發送還在排隊等待執行,使用者不需要重複發送任務。
如何處理max_execution_time逾時問題
一般查詢的執行逾時時間,DMS平台上預設設定是7200s,jdbc driver、DataGrip上預設是30s。逾時限制觸發之後查詢會自動取消。使用者可以進行查詢層級更改,例如
select * from system.numbers settings max_execution_time = 3600
,也可以在DMS上執行以下命令來設定全域參數。set global on cluster default max_execution_time = 3600;
如何處理socket_timeout逾時問題
HTTP協議在監聽socket返回結果時的等待時間,DMS平台上預設設定是7200s,jdbc driver、DataGrip上預設是30s。該參數不是Clickhouse系統內的參數,它屬於jdbc在HTTP協議上的參數,但它是會影響到前面的max_execution_time參數設定效果,因為它決定了用戶端在等待結果返回上的時間限制。所以一般使用者在調整max_execution_time參數的時候也需要配套調整socket_timeout參數,略微高於max_execution_time即可。使用者佈建參數時需要在jdbc連結串上添加socket_timeout這個property,單位是毫秒,例如:'jdbc:clickhouse://127.0.0.1:8123/default?socket_timeout=3600000'。
如何處理使用SLB連結時的異常斷鏈
阿里雲上的SLB連結在長時間內沒有資料報文發送時會自動取消連結,用戶端收到”read timeout“錯誤,查詢無法追蹤。對於這種情況您可以在DMS上執行以下命令來設定全域參數,設定後需要重啟叢集。
set global on cluster default send_progress_in_http_headers = 1; set global on cluster default http_headers_progress_interval_ms = 60000;
對於20.8最新版本您需要使用如下命令,設定失敗時可以先申請小版本升版。
set global on cluster default http_server_enable_tcp_keep_alive = 1; set global on cluster default tcp_keep_alive_timeout = 60;
開啟send_progress_in_http_headers後,ClickHouse服務端會不斷髮送包含查詢進度的HTTP-Header報文給用戶端,這樣就會一直有資料報文流通,避免連結斷開。
因為各種原因用戶端失聯後,HTTP協議發送的查詢仍然會繼續執行。使用者可以在系統資料表追蹤到查詢是否成功執行。
查詢叢集中所有執行個體當前正在running的查詢:
SELECT * FROM remote(default, system, processes) WHERE query LIKE 'XXX'
查詢當天的歷史查詢結果,包括是否成功、已經失敗的錯誤資訊:
SELECT * FROM remote(default, system, query_log) WHERE event_date = toDate(now()) AND query LIKE 'XXX'
使用ClickHouse服務端IP直接連結時的Client異常hang住
阿里雲上的ECS在跨安全性群組連結時,有可能陷入靜默連結錯誤。具體原因是jdbc用戶端所在ECS機器的安全性群組白名單並沒有開放給ClickHouse服務端機器。當用戶端的請求經過超長時間才得到查詢結果時,返回的報文可能因為路由表不通無法發送到用戶端。此時用戶端就陷入了異常hang住狀態。
該問題的處理辦法和SLB連結異常斷鏈問題一樣,開啟send_progress_in_http_headers可以解決大部分問題。在極少數情況下,開啟send_progress_in_http_headers仍不能解決問題的,您可以嘗試配置jdbc用戶端所在ECS機器的安全性群組白名單,把ClickHouse服務端地址加入到白名單中。
TCP協議
TCP協議最常使用的情境是ClickHouse內建的命令列工具進行互動分析時,社區相容版叢集常見連接埠號碼為3306。因為TCP協議裡有連結定時探活報文,所以它不會出現socket層面的逾時問題。您只需關注distributed_ddl_task_timeout和max_execution_time參數的逾時,設定方法和HTTP協議一致。
為什麼OSS外表匯入ORC、PARQUET等格式的資料,出現記憶體報錯或OOM掛掉?
常見原因:記憶體使用量率比較高。
您可以採取如下解決方案。
把OSS上的檔案拆分為一個一個的小檔案,然後再進行匯入。
進行記憶體的升配。如何升配,請參見社區相容版叢集垂直變更配置和水平擴縮容。
如何處理匯入資料報錯:too many parts?
ClickHouse每次寫入都會產生一個data part,如果每次寫入一條或者少量的資料,那會造成ClickHouse內部有大量的data part(會給merge和查詢造成很大的負擔)。為了防止出現大量的data part,ClickHouse內部做了很多限制,這就是too many parts報錯的內在原因。出現該錯誤,請增加寫入的批量大小。如果無法調整批量大小,可以在控制台修改參數:merge_tree.parts_to_throw_insert
,將參數的取值設定的大一些。
為什麼DataX匯入速度慢?
常見原因及解決方案如下。
常見原因1:參數設定不合理。ClickHouse適合使用大batch、少數幾個並發進行寫入。多數情況下batch可以高達幾萬甚至幾十萬(取決於您的單行RowSize大小,一般按照每行100Byte進行評估,您需要根據實際資料特徵進行估算)。
解決方案:並發數建議不超過10個。您可以調整不同參數進行嘗試。
常見原因2:DataWorks獨享資源群組的ECS規格太小。比如獨享資源的CPU、Memory太小,導致並發數、網路出口頻寬受限;或者是batch設定太大而Memory太小,引起DataWorks進程Java GC等。
解決方案:您可以通過DataWorks的輸出日誌對ECS規格大小進行確認。
常見原因3:從資料來源中讀取慢。
解決方案:您可以在DataWorks輸出日誌中搜尋totalWaitReaderTime、totalWaitWriterTime,如果發現totalWaitReaderTime明顯大於totalWaitWriterTime,則表明主要耗時在讀取端,而不是寫入端。
常見原因4:使用了公網Endpoint。公網Endpoint的頻寬非常有限,無法承載高效能的資料匯入匯出。
解決方案:您需要替換為VPC網路的Endpoint。
常見原因5:有髒資料。在沒有髒資料的情況下,資料以batch方式寫入。但是遇到了髒資料,正在寫入的batch就會失敗,並回退到逐行寫入,產生大量的data part,大幅度降低了寫入速度。
您可以參考如下兩種方式判斷是否有髒資料。
查看報錯資訊,如果返回資訊包含
Cannot parse
,則存在髒資料。代碼如下。
SELECT written_rows, written_bytes, query_duration_ms, event_time, exception FROM system.query_log WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart' and exception_code != 0 ORDER BY event_time DESC LIMIT 30;
查看batch行數,如果batch行數變為1,則存在髒資料。
代碼如下。
SELECT written_rows, written_bytes, query_duration_ms, event_time FROM system.query_log WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart' ORDER BY event_time DESC LIMIT 30;
解決方案:您需要在資料來源刪除或修改髒資料。
為什麼Hive匯入後其資料行數跟ClickHouse對不上?
您可以通過以下手段進行排查。
首先通過系統資料表query_log來查看匯入的過程中是否有報錯,如果有報錯,那很有可能出現資料丟失的情況。
確定使用的表引擎是否可以去重,比如使用ReplacingMergeTree,那很可能出現ClickHouse中的Count小於Hive中的情況。
重新確認Hive中資料行數的正確性,很有可能出現源頭的行數確定錯誤的情況。
為什麼Kafka匯入後其資料行數跟ClickHouse對不上?
您可以通過以下手段進行排查。
首先通過系統資料表query_log來查看匯入的過程中是否有報錯,如果有報錯,那很有可能出現資料丟失的情況。
確定使用的表引擎是否可以去重,比如使用ReplacingMergeTree,那很可能出現ClickHouse中的Count小於Kafka中的情況。
查看Kafka外表的配置是否有kafka_skip_broken_messages參數的配置,如果有該參數,那可能會跳過解析失敗的Kafka訊息,導致ClickHouse總的行數是小於Kafka中的。
如何使用Spark、Flink匯入資料?
如何使用Spark匯入資料請參見從Spark匯入。
如何使用Flink匯入資料請參見從Flink SQL匯入。
如何從現有ClickHouse匯入資料到雲資料庫ClickHouse?
您可以採取如下方案。
通過ClickHouse Client以匯出檔案的形式進行資料移轉,詳情請參見將自建ClickHouse資料移轉到雲ClickHouse中。
通過Remote函數進行資料的遷移。
INSERT INTO <目的表> SELECT * FROM remote('<串連串>', '<庫>', '<表>', '<username>', '<password>');
使用MaterializeMySQL引擎同步MySQL資料時,為什麼出現如下報錯:The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires
?
常見原因:MaterializeMySQL引擎停止同步的時間太久,導致MySQL Binlog日誌到期被清理掉。
解決方案:刪除報錯的資料庫,重新在雲資料庫ClickHouse中建立同步的資料庫。
使用MaterializeMySQL引擎同步MySQL資料時,為什麼出現錶停止同步?為什麼系統資料表system.materialize_mysql中sync_failed_tables
欄位不為空白?
常見原因:同步過程中使用了雲資料庫ClickHouse不支援的MySQL DDL語句。
解決方案:重新同步MySQL資料,具體步驟如下。
刪除停止同步的表。
DROP TABLE <table_name> ON cluster default;
說明table_name
為停止同步的表名。如果停止同步的表有分布式表,那麼本地表和分布式表都需要刪除。重啟同步進程。
ALTER database <database_name> ON cluster default MODIFY SETTING skip_unsupported_tables = 1;
說明<database_name>
為雲資料庫ClickHouse中同步的資料庫。
如何處理報錯:“Too many partitions for single INSERT block (more than 100)”?
常見原因:單個INSERT操作中超過了max_partitions_per_insert_block(最大分區插入塊,預設值為100)。ClickHouse每次寫入都會產生一個data part(資料部分),一個分區可能包含一個或多個data part,如果單個INSERT操作中插入了太多分區的資料,那會造成ClickHouse內部有大量的data part(會給合并和查詢造成很大的負擔)。為了防止出現大量的data part,ClickHouse內部做了限制。
解決方案:請執行以下操作,調整分區數或者max_partitions_per_insert_block參數。
調整表結構,調整分區方式,或避免單次插入的不同分區數超過限制。
避免單次插入的不同分區數超過限制,可根據資料量適當修改max_partitions_per_insert_block參數,放大單個插入的不同分區數限制,修改文法如下:
單節點執行個體
SET GLOBAL max_partitions_per_insert_block = XXX;
多節點執行個體
SET GLOBAL ON cluster DEFAULT max_partitions_per_insert_block = XXX;
說明ClickHouse社區推薦預設值為100,分區數不要設定得過大,否則可能對效能產生影響。在大量匯入資料後可修改值為預設值。
如何處理insert into select XXX記憶體超限報錯?
常見原因及解決方案如下。
常見原因1:記憶體使用量率比較高。
解決方案:調整參數max_insert_threads,減少可能的記憶體使用量量。
常見原因2:當前是通過
insert into select
把資料從一個ClickHouse叢集匯入到另外一個叢集。解決方案:通過匯入檔案的方式來遷移資料,更多資訊請參見將自建ClickHouse資料移轉到雲ClickHouse中。
如何查詢CPU使用量和記憶體使用量量?
您可以在system.query_log系統資料表裡自助查看CPU和MEM在查詢時的使用日誌,裡面有每個查詢的CPU使用量和記憶體使用量量統計。更多資訊請參見system.query_log。
如何處理查詢時記憶體超出限制?
ClickHouse服務端對所有查詢線程都配有memory tracker,同一個查詢下的所有線程tracker會彙報給一個memory tracker for query,再上層還是memory tracker for total。您可以根據情況採取如下解決方案。
遇到
Memory limit (for query)
超限報錯說明是查詢記憶體佔用過多(執行個體總記憶體的70%)導致失敗,這種情況下您需要垂直升配提高執行個體記憶體規模。遇到
Memory limit (for total)
超限報錯說明是執行個體總記憶體使用量超限(執行個體總記憶體的90%),這種情況下您可以嘗試降低查詢並發,如果仍然不行則可能是後台非同步任務佔用了比較大的記憶體(常常是寫入後主鍵合并任務),您需要垂直升配提高執行個體記憶體規模。
如何處理查詢報並發超限?
預設Server查詢最大並發數為100,您可以在控制台上進行修改。修改運行參數值具體操作步驟如下。
在叢集列表頁面,選擇社區版執行個體列表,單擊目的地組群ID。
單擊左側導覽列的參數配置。
在參數配置頁面,單擊max_concurrent_queries參數的運行參數值後面的編輯按鈕。
在懸浮框中填寫目標值,單擊確定。
單擊提交參數。
單擊確定。
在資料停止寫入時,同一個查詢語句每次查詢的結果不一致,應該如何處理?
問題詳細描述:通過select count(*)
查詢資料時只有整體資料的大概一半,或者資料一直在跳變。
為什麼有時看不到已經建立好的表並且查詢結果一直抖動時多時少?
常見原因及解決方案如下。
常見原因1:建表流程存在問題。ClickHouse的分布式叢集搭建並沒有原生的分布式DDL語義。如果您在自建ClickHouse叢集時使用
create table
建立表,查詢雖然返回了成功,但實際這個表只在當前串連的Server上建立了。下次串連重設換一個Server,您就看不到這個表了。解決方案:
建表時,請使用
create table <table_name> on cluster default
語句,on cluster default
聲明會把這條語句廣播給default叢集的所有節點進行執行。範例程式碼如下。CREATE TABLE test ON cluster default (a UInt64) Engine = MergeTree() ORDER BY tuple();
在test表上再建立一個分布式表引擎,建表語句如下。
CREATE TABLE test_dis ON cluster default AS test Engine = Distributed(default, default, test, cityHash64(a));
常見原因2:ReplicatedMergeTree儲存表配置有問題。ReplicatedMergeTree表引擎是對應MergeTree表引擎的主備同步增強版,在單副本執行個體上限定只能建立MergeTree表引擎,在雙副本執行個體上只能建立ReplicatedMergeTree表引擎。
解決方案:在雙副本執行個體上建表時,請使用
ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}')
或ReplicatedMergeTree()
配置ReplicatedMergeTree表引擎。其中,ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}')
為固定配置,無需修改。
如何處理往表裡寫入時間戳記資料後查詢出來的結果與實際資料不同?
用SELECT timezone()
語句,查看時區是否為當地時區,如果不是修改timezone配置項的值為當地時區。如何修改請參見修改配置項運行參數值。
如何處理建表後查詢表不存在?
常見原因:DDL語句只在一個節點上執行。
解決方案:檢查DDL語句是否有on cluster
關鍵字。更多資訊,請參見建表文法。
為什麼Kafka外表建表後資料不增加?
您可以先對Kafka外表進行select * from
的查詢,如果查詢報錯,那可以根據報錯資訊確定原因(一般是資料解析失敗)。如果查詢正常返回結果,那需要進一步查看目的表(Kafka外表的具體儲存表)和Kafka源表(Kafka外表)的欄位是否匹配。如果資料寫入失敗,那說明欄位是匹配不上的。樣本語句如下。
insert into <目的表> as select * from <kafka外表>;
為什麼用戶端看到的時間結果和時區顯示的不一樣?
用戶端設定了use_client_time_zone
,並設定在了錯誤時區上。
為什麼資料寫入後不可見?
一般原因是分布式表和本地表的表結構不一致造成的。您可以通過查詢系統資料表system.distribution_queue
來查看寫入分布式表的時候是否發生錯誤。
為什麼optimize任務很慢?
optimize任務非常佔用CPU和磁碟吞吐,查詢和optimize任務都會相互影響,在機器節點負載壓力較大的時候就會表現出optimize很慢問題,目前沒有特殊最佳化方法。
為什麼optimize後資料仍未主鍵合并?
首先為了讓資料有正確的主鍵合并邏輯,需要保證以下兩個前提條件。
儲存表裡的partition by定義欄位必須是包含在
order by
裡的,不同分區的資料不會主鍵合并。分布式表裡定義的Hash演算法欄位必須是包含在
order by
裡的,不同節點的資料不會主鍵合并。
optimize常用命令及相關說明如下。
命令 | 說明 |
| 嘗試選取MergeTree的data parts進行合并,有可能沒有執行任務就返回。執行了也並不保證全表的記錄都完成了主鍵合并,一般不會使用。 |
| 指定某個分區,選取分區中所有的data parts進行合并,有可能沒有執行任務就返回。任務執行後代表某個分區下的資料都合并到了同一個data part,單分區下已經完成主鍵合并。但是在任務執行期間寫入的資料不會參與合并,若是分區下只有一個data part也不會重複執行任務。 說明 對於沒有分區鍵的表,其預設分區就是partition tuple()。 |
| 對全表所有分區強制進行合并,即使分區下只有一個data part也會進行重新合并,可以用於強制移除TTL到期的記錄。任務執行代價最高,但也有可能沒有執行合并任務就返回。 |
對於上面三種命令,您可以設定參數optimize_throw_if_noop
通過異常報錯感知是否執行任務。
為什麼optimize後資料TTL仍未生效?
常見原因及解決方案如下。
常見原因1:資料的TTL淘汰是在主鍵合并階段執行的,如果data part遲遲沒有進行主鍵合并,那到期的資料就無法淘汰。
解決方案:
您可以通過手動
optimize final
或者optimize 指定分區
的方式觸發合并任務。您可以在建表時設定merge_with_ttl_timeout、ttl_only_drop_parts等參數,提高含有到期資料data parts的合并頻率。
常見原因2:表的TTL經過修改或者添加,存量的data part裡缺少TTL資訊或者不正確,這樣也可能導致到期資料淘汰不掉。
解決方案:
您可以通過
alter table materialize ttl
命令重建TTL資訊。您可以通過
optimize 分區
更新TTL資訊。
為什麼optimize後更新刪除操作沒有生效?
雲資料庫ClickHouse中的更新刪除都是非同步執行的,目前沒有機制可以幹預其進度。您可以通過system.mutations系統資料表查看進度。
如何進行DDL增加列、刪除列、修改列操作?
本地表的修改直接執行即可。如果要對分布式表進行修改,需分如下情況進行。
如果沒有資料寫入,您可以先修改本地表,然後修改分布式表。
如果資料正在寫入,您需要區分不同的類型進行操作。
類型
操作步驟
增加Nullable的列
修改本地表。
修改分布式表。
修改列的資料類型(類型可以相互轉換)
刪除Nullable列
修改分布式表。
修改本地表。
增加非Nullable的列
停止資料的寫入。
執行SYSTEM FLUSH DISTRIBUTED分布式表。
修改本地表。
修改分布式表。
重新進行資料的寫入。
刪除非Nullable的列
修改列的名稱
為什麼DDL執行慢,經常卡住?
常見原因:DDL全域的執行是串列執行,複雜查詢會導致死結。
您可以採取如下解決方案。
等待運行結束。
在控制台嘗試終止查詢。
如何處理分布式DDL報錯:longer than distributed_ddl_task_timeout (=xxx) seconds?
您可以通過使用set global on cluster default distributed_ddl_task_timeout=xxx
命令修改預設逾時時間,xxx為自訂逾時時間,單位為秒。全域參數修改請參見叢集參數修改。
如何處理文法報錯:set global on cluster default?
常見原因及解決方案如下。
常見原因1:ClickHouse用戶端會進行文法解析,而
set global on cluster default
是服務端增加的文法。在用戶端尚未更新到與服務端對齊的版本時,該文法會被用戶端攔截。解決方案:
使用JDBC Driver等不會在用戶端解析文法的工具,比如DataGrip、DBeaver。
編寫JDBC程式來執行該語句。
常見原因2:
set global on cluster default key = value;
中value是字串,但是漏寫了引號。解決方案:在字串類型的value兩側加上引號。
有什麼BI工具推薦?
Quick BI。
有什麼資料查詢IDE工具推薦?
DataGrip、DBEaver。
雲資料庫ClickHouse支援向量檢索嗎?
雲資料庫ClickHouse支援向量檢索。更多詳情,參見以下文檔:
如何查看每張表所佔的磁碟空間?
您可以通過如下代碼查看每張表所佔的磁碟空間。
SELECT table, formatReadableSize(sum(bytes)) as size, min(min_date) as min_date, max(max_date) as max_date FROM system.parts WHERE active GROUP BY table;
如何查看冷資料大小?
範例程式碼如下。
SELECT * FROM system.disks;
如何查詢哪些資料在冷存上?
範例程式碼如下。
SELECT * FROM system.parts WHERE disk_name = 'cold_disk';
如何移動分區資料到冷存?
範例程式碼如下。
ALTER TABLE table_name MOVE PARTITION partition_expr TO DISK 'cold_disk';
為什麼監控中存在資料中斷情況?
常見原因如下。
查詢觸發OOM。
修改配置觸發重啟。
升降配後的執行個體重啟。
20.8後的版本是否支援平滑升級,不需要遷移資料?
ClickHouse的叢集是否支援平滑升級,主要取決於叢集的建立時間。對於2021年12月01日之後購買的叢集,支援原地平滑升級核心大版本,無需遷移資料。而對於2021年12月01日之前購買的叢集,則需要通過資料移轉的方式進行核心大版本升級。如何升級版本,請參見升級核心大版本。
常用系統資料表有哪些?
常用系統資料表及作用如下。
名稱 | 作用 |
system.processes | 查詢正在執行的SQL。 |
system.query_log | 查詢歷史執行過的SQL。 |
system.merges | 查詢叢集上的merge資訊。 |
system.mutations | 查詢叢集上的mutation資訊。 |
如何修改系統層級的參數?是否要重啟,有什麼影響?
系統層級的參數對應config.xml內的部分配置項,具體修改步驟如下。
在叢集列表頁面,選擇社區版執行個體列表,單擊目的地組群ID。
單擊左側導覽列的參數配置。
在參數配置頁面,單擊max_concurrent_queries參數的運行參數值後面的編輯按鈕。
在懸浮框中填寫目標值,單擊確定。
單擊提交參數。
單擊確定。
單擊確定後,自動重啟clickhouse-server,重啟會造成約1min閃斷。
如何修改使用者層級的參數?
使用者層級的參數對應users.xml內的部分配置項,你需要執行如下樣本語句。
SET global ON cluster default ${key}=${value};
無特殊說明的參數執行成功後即可生效。
如何修改Quota?
您可以在執行語句的settings裡增加,範例程式碼如下。
settings max_memory_usage = XXX;
如何解決目的地組群與資料來源網路互連問題?
如果目的地組群與資料來源使用相同的VPC並位於同一地區。您需檢查二者是否將IP地址添加到了對方的白名單中。如果沒有,請添加白名單。
ClickHouse中如何添加白名單,請參見設定白名單。
其他資料來源如何添加白名單,請參見自身產品文檔。
如果目的地組群與資料來源不屬於上述情況,選擇合適的網路解決方案,解決網路問題後再將彼此IP地址添加到對方的白名單中。
情境 | 解決方案 |
雲上雲下互連 | |
跨地區跨帳號VPC互連 | |
同地區不通VPC互連 | |
跨地區跨帳號VPC互連 |