1 概述

??在對ClickHouse進行分布表+復制表+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

??執行該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: .

??根據報錯信息可以不知道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 問題描述

??在執行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:

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

2.2 解決

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

3 分布表只讀Table is in readonly mode

3.1 問題描述

??如SQL在執行插入數據時遇到如下錯誤：

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”模式，導致插入失敗

3.2 解決

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

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

4.1 問題描述

??如在日志中發現如下報錯

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數據丟失，從而使clickhouse數據庫無法啟動

4.2 解決

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。