clickhouse-backup

clickhouse-backup copied to clipboard

Hi @Slach, When i restored a table on a clickhouse cluster, I used --restore-database-mapping after that I saw clickhouse-backup create a different uuid for the same table on ZK, so that the table could not sync. Did it relate to this issue?

Apr 19 '24 10:04 supnobita

no this is a different issue, but could be related

usign {uuid} in replication path always bad idea from my perspective

do you mean restoring ReplicatedMergeTree on the different replicas with --restore-database-mapping replace {uuid} with different values on different replicas?

as a workaround you could change manually /var/lib/clickhouse/backup/backup_name/metadata/db/table.json and replace ReplicatedMergeTree('/path/{uuid}','{replica}') to ReplicatedMergeTree('/path/{shard}/{database}/{table}','{replica}')

Apr 19 '24 10:04 Slach

do you mean restoring ReplicatedMergeTree on the different replicas with --restore-database-mapping replace {uuid} with different values on different replicas? Yes ! And the new uuid(s) are different with the uuid in table.json in the backup metadata. That mean Clickhouse-backup create a new uuid, it didn't use the uuid of the backup.

I will try the workaround tmr. Thanks

Apr 19 '24 11:04 supnobita

you also could try to use

general:
 restore_metadata_on_cluster: "{cluster}"

after that ReplicatedMergeTree will create on cluster with the same UUID

it didn't use the uuid of the backup.

uuid is not related to backup this is clickhouse-server behavior when you created engine=ReplicatedMergeTree() without parameter the table will create with default_replica_path (which contains {uuid} and default_replica_path values

Apr 19 '24 11:04 Slach

if you will use restore_metadata_on_cluster in this case you just need execute restore --schema only in one replica in whole cluster

and use restore --data only in first replica in each shard

Apr 19 '24 11:04 Slach

It worked !

Thank you.

Apr 22 '24 04:04 supnobita