ClickHouse多分片副本架构下Schema备份失败问题排查与解决

问题背景 #

在3分片、3副本的ClickHouse环境执行仅备份结构的Schema备份时，执行以下SQL：

BACKUP DATABASE default 
TO S3( 'https://bucket-id.s3.amazonaws.com/backup_folder/snapshot_2023_10_30_schema' ) 
SETTINGS structure_only=true ASYNC

-- 检查备份状态
SELECT * FROM system.backups WHERE id = 'query-id' \G

触发错误：

Code: 49.
DB::Exception: Table {} has its shared ID to be different from one from the create query:
While collecting tables for backup in database default. (LOGICAL_ERROR)
(version 23.6.2.18 (official build))

1. 如何解决该Schema问题，恢复至稳定状态？ #

这个错误源于分片/副本间表的shared ID（分布式表一致性标识）与创建语句中的值不匹配，属于元数据不一致问题，解决步骤如下：

• 先定位到异常表（参考问题2的方法）
• 若表可丢弃：直接用集群级删除语句清理，避免分片副本残留：DROP TABLE <table_name> ON CLUSTER <cluster_name>
• 若需保留表：
  1. 导出表结构：SHOW CREATE TABLE <table_name>
  2. 删除原表：DROP TABLE <table_name> ON CLUSTER <cluster_name>
  3. 用导出的DDL重新创建表，确保通过ON CLUSTER语句在集群同步执行，保证所有分片副本的shared ID一致
  4. 如有需要，重新导入数据（仅备份Schema可忽略此步骤）

2. 如何定位未指明的异常表？ #

可以通过两种方式定位：

• 查看ClickHouse服务日志（默认路径/var/log/clickhouse-server/clickhouse-server.log），搜索关键词shared ID to be different，日志中会打印具体的异常表名
• 执行查询遍历库内所有表，对比元数据一致性：

  SELECT 
    database, 
    name, 
    uuid, 
    create_table_query 
  FROM system.tables 
  WHERE database = 'default'
  

  同一分布式表在不同分片上的uuid（即shared ID）不一致的即为异常表；也可检查create_table_query中的UUID是否与表实际uuid匹配

3. 能否跳过异常表继续备份其他表？ #

可以通过两种方式实现：

• 显式指定需要备份的表列表，排除异常表：

  BACKUP TABLE default.table1, default.table2, ... 
  TO S3( 'https://bucket-id.s3.amazonaws.com/backup_folder/snapshot_2023_10_30_schema' ) 
  SETTINGS structure_only=true ASYNC
  

• 使用exclude_tables参数（ClickHouse 22.8及以上版本支持），备份数据库时直接排除异常表：

  BACKUP DATABASE default 
  TO S3( 'https://bucket-id.s3.amazonaws.com/backup_folder/snapshot_2023_10_30_schema' ) 
  SETTINGS 
    structure_only=true, 
    exclude_tables='default.bad_table1,default.bad_table2',
    ASYNC
  

内容的提问来源于stack exchange，提问作者Sairam Krish