1 概述

??在對ClickHouse進行分布表+復(fù)制表+zookeeper保證高可用的情況下進行性能測試時遇到如下坑，進行整理

2 分布表join問題Unknown identifier: LO_CUSTKEY, context:…

1.1 問題描述

??SQL如下：

SELECT count(1) FROM performance.line_all AS c LEFT JOIN performance.customer_all AS l ON l.C_CUSTKEY = c.LO_CUSTKEY

??執(zhí)行該SQL報錯如下：

Received exception from server (version 19.4.0): Code: 47. DB::Exception: Received from 10.0.0.50:9000. DB::Exception: Received from ambari04:9000, 10.0.0.54. DB::Exception: Unknown identifier: LO_CUSTKEY, context: query: 'LO_CUSTKEY' required_names: 'LO_CUSTKEY' source_tables: table_aliases: complex_aliases: masked_columns: array_join_columns: source_columns: .

??根據(jù)報錯信息可以不知道LO_CUSTKEY,這個連接字段

1.2 解決

??分布表join，在on后的連接條件中，from后面跟的表的連接字段放在前面。修改SQL如下：

SELECT count(1) FROM performance.customer_all AS c LEFT JOIN performance.line_all AS l ON l.C_CUSTKEY = c.LO_CUSTKEY

2 與Zookeeper連接丟失,Unknown status, Cannot allocate block number in ZooKeeper: , ZooKeeper session has been expired…

2.1 問題描述

??在執(zhí)行SQL中如在遇到如下報錯：

↑ Progress: 157.94 million rows, 6.91 GB (92.63 thousand rows/s., 4.05 MB/s.) Received exception from server (version 19.4.0): Code: 319. DB::Exception: Received from 10.0.0.50:9000. DB::Exception: Unknown status, client must retry. Reason: Connection loss. ↖ Progress: 94.47 million rows, 4.18 GB (95.07 thousand rows/s., 4.20 MB/s.) Received exception from server (version 19.4.0): Code: 999. DB::Exception: Received from 10.0.0.50:9000. DB::Exception: Cannot allocate block number in ZooKeeper: Coordination::Exception: Connection loss. lineorder_flat_all.Distributed.DirectoryMonitor: Code: 225, e.displayText() = DB::Exception: Received from ambari02:9000, 10.0.0.52. DB::Exception: ZooKeeper session has been expired.. Stack trace:

??根據(jù)報錯信息可知，是因為與Zookeeper的連接丟失導(dǎo)致不能分配塊號等問題。因為clickhouse對zookeeper的依賴非常的重，表的元數(shù)據(jù)信息，每個數(shù)據(jù)塊的信息，每次插入的時候，數(shù)據(jù)同步的時候，都需要和zookeeper進行交互。zookeerper 服務(wù)在同步日志過程中，會導(dǎo)致ZK無法響應(yīng)外部請求，進而引發(fā)session過期等問題

2.2 解決

??（1）加大zookeeper會話最大超時時間，在zoo.cfg 中修改MaxSessionTimeout=120000，修改后重啟zookeeper。
注意：zookeeper的超時時間不要設(shè)置太大，在服務(wù)掛掉的情況下，會反映很慢
??（2）zookeeper的snapshot文件存儲盤不低于1T，注意清理策略
??（3）在zookeeper中將dataLogDir存放目錄應(yīng)該與dataDir分開，可單獨采用一套存儲設(shè)備來存放ZK日志。
??（4）在ZOO.CFG中增加：forceSync=no。默認是開啟的，為避免同步延遲問題，ZK接收到數(shù)據(jù)后會立刻去將當(dāng)前狀態(tài)信息同步到磁盤日志文件中，同步完成后才會應(yīng)答。將此項關(guān)閉后，客戶端連接可以得到快速響應(yīng)。關(guān)閉forceSync選項后，會存在潛在風(fēng)險，雖然依舊會刷磁盤（log.flush()首先被執(zhí)行），但因為操作系統(tǒng)為提高寫磁盤效率，會先寫緩存，當(dāng)機器異常后，可能導(dǎo)致一些zk狀態(tài)信息沒有同步到磁盤，從而帶來ZK前后信息不一樣問題。
??（5）clickhouse建表的時候添加use_minimalistic_part_header_in_zookeeper參數(shù)，對元數(shù)據(jù)進行壓縮存儲，但是修改完了以后無法再回滾的。

3 分布表只讀Table is in readonly mode

3.1 問題描述

??如SQL在執(zhí)行插入數(shù)據(jù)時遇到如下錯誤：

2020.05.28 10:59:11.048910 [ 47 ] {} <Error> lineorder_flat_all.Distributed.DirectoryMonitor: Code: 242, e.displayText() = DB::Exception: Received from ambari04:9000, 10.0.0.54. DB::Exception: Table is in readonly mode. Stack trace:

??是因為zookeeper壓力太大，表處于“read only mode”模式，導(dǎo)致插入失敗

3.2 解決

??（1）在zookeeper中將dataLogDir存放目錄應(yīng)該與dataDir分開，可單獨采用一套存儲設(shè)備來存放ZK日志。
??（2）做好zookeeper集群和clickhouse集群的規(guī)劃，可以多套zookeeper集群服務(wù)一套clickhouse集群。

4 Clickhouse 集群zookeeper數(shù)據(jù)丟失,Can’t get data for node /clickhouse/tables/…

4.1 問題描述

??如在日志中發(fā)現(xiàn)如下報錯

Cannot create table from metadata file /var/lib/clickhouse/metadata/xx/xxx.sql, error: Coordination::Exception: Can’t get data for node /clickhouse/tables/xx/cluster_xxx-01/xxxx/metadata: node doesn’t exist (No node), stack trace:

??是因為zookeeper數(shù)據(jù)丟失，從而使clickhouse數(shù)據(jù)庫無法啟動

4.2 解決

??（1）將/var/lib/clickhouse/metadata/ 下的SQL與/var/lib/clickhouse/data/ 下的數(shù)據(jù)備份之后刪除
??（2）啟動數(shù)據(jù)庫
??（3）創(chuàng)建與原來表數(shù)據(jù)結(jié)構(gòu)的MergeTree表
??（4）將之前分布式表的數(shù)據(jù)文件夾復(fù)制到新表的數(shù)據(jù)目錄中。
??（5）重啟數(shù)據(jù)庫
??（6）重新創(chuàng)建原結(jié)構(gòu)本地表
??（7）重新創(chuàng)建原結(jié)構(gòu)分布式表
??（8）insert into [分布式表] select * from [MergeTree表]

總結(jié)

以上是生活随笔為你收集整理的ClickHouse常见问题及其解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。