CLICKHOUSE几个常见问题处理(持续更新)

CLICKHOUSE几个常见问题处理-持续更新

• • 删除旧集群表后重建，5分钟左右出现zk中该表的配置文件消失的情况
  • 如何处理socket_timeout超时问题
  • 重建分片01后，利用脚本创建分区表与本地表后报错如下
  • 分布式DDL某数据节点的副本不执行
  • 数据副本表和数据不一致
  • 数据副本启动缺少zk表
  • ZK table replicas数据未删除，导致重建表报错
  • Clickhouse节点意外关闭

删除旧集群表后重建，5分钟左右出现zk中该表的配置文件消失的情况

网上的解决方案测试后无效
网上案例

1. 确认metadata和data下无该表数据。
2. 确认zk中无该表数据。
3. 重建表后5分钟左右配置文件消失，但metadata和data下有该表（日志中会出现 No node, path）。此时该表形同虚设，无法正常使用。
4. 标记该问题为bug，可能部分数据存在于缓存中导致无法重建

解决方案：
更换表名后，zk中该表的配置文件不会消失。通过此方式解决该问题。需谨慎使用。

如何处理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’。

重建分片01后，利用脚本创建分区表与本地表后报错如下

2021.10.13 17:43:30.543624 [ 56 ] {} ck_cdtp.point_data_local (fd45ddc2-c829-41a6-8dd5-b943838aa715): void DB::StorageReplicatedMergeTree::queueUpdatingTask(): Code: 999, e.displayText() = Coordination::Exception: Can’t get data for node /ck_cdtp/tables/01/point_data_local/replicas/manyun-ch.1/log_pointer: node doesn’t exist (No node), Stack trace (when copying this message, always include the lines below):

解决方案：
登录zk查看/ck_cdtp/tables/01/point_data_local/replicas/查看01分片节点是否存在，如果不存在，则删除本地表单独重新创建

分布式DDL某数据节点的副本不执行

问题：使用分布式ddl执行命令create table on cluster xxxx 某个节点上没有创建表，但是client返回正常，查看日志有如下报错。

nebula_dc.dc_test1: Retrying createReplica(), because some other replicas were created at the same time

解决方案：
重启该不执行的节点。

数据副本表和数据不一致

问题：由于某个数据节点副本异常，导致两数据副本表不一致，某个数据副本缺少表，需要将两个数据副本调整一致。
解决方案：

1. 在缺少表的数据副本节点上创建缺少的表，创建为本地表，表结构可以在其他数据副本通过show crete table xxxx获取。
2. 表结构创建会clickhouse会自动从其他副本同步该表数据，验证数据量是否一致即可。

副本节点全量恢复
问题：某个数据副本异常无法启动，需要重新搭建副本。
解决方案：

1. 清空异常副本节点的metadata和data目录。
2. 从另一个正常副本将metadata目录拷贝过来（这一步之后可以启动数据库，但是只有表结构没有数据）。
3. 执行sudo -u clickhouse touch /data/clickhouse/flags/force_restore_data
4. 启动数据库。

数据副本启动缺少zk表

问题：某个数据副本表在zk上丢失数据，或者不存在，但是metadata元数据里存在，导致启动异常

报错：>Can’t get data for node /clickhouse/tables/01-02/xxxxx/xxxxxxx/replicas/cluster01-02-2/metadata: node doesn’t exist (No node): Cannot attach table xxxxxxx

解决方案：

1. metadata中移除该表的结构文件，如果多个表报错都移除
   mv metadata/xxxxxx/xxxxxxxx.sql /tmp/
2. 启动数据库
3. 手工创建缺少的表，表结构从其他节点show create table获取。
4. 创建后会自动同步数据，验证数据是否一致。

ZK table replicas数据未删除，导致重建表报错

问题：重建表过程中，先使用drop table xxx on cluster xxx ,各节点在clickhouse上table已物理删除，但是zk里面针对某个clickhouse节点的table meta信息未被删除（低概率事件），因zk里仍存在该表的meta信息，导致再次创建该表create table xxx on cluster, 该节点无法创建表(其他节点创建表成功)

报错：Replica /clickhouse/tables/01-03/xxxxxx/xxx/replicas/cluster01-03-2 already exists…

解决方案：

1. 从其他数据副本cp该table的metadata sql过来.
2. 重启节点。

Clickhouse节点意外关闭

问题：模拟其中一个节点意外宕机，在大量insert数据的情况下，关闭某个节点。
现象：数据写入不受影响、数据查询不受影响、建表DDL执行到异常节点会卡住

报错：Code: 159. >DB::Exception: Received from localhost:9000. DB::Exception: Watching task /clickhouse/task_queue/ddl/query-0000565925 is executing longer than distributed_ddl_task_timeout (=180) seconds. There are 1 unfinished hosts (0 of them are currently active), they are going to execute the query in background.

解决方案：
启动异常节点，期间其他副本写入数据会自动同步过来，其他副本的建表DDL也会同步。