Replies: 1 comment 2 replies
-
This is not typical use case we partially implemented this approach but, currently it will DROP + CREATE + DETACH TABLE + ATTACH TABLE ... and have race condition if run it paralllel in multiple replicas let's convert discussion to issue and move it to backlog |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey,
We have a use case where we store data in ReplicatedMergeTree table which keeps it in different disks according to the TTL.
We noticed that in scenario where:
DISK_A stores table metadata and data, DISK_B stores just data and by accident DISK_A is lost
we can just manually move sql file with the attach table statement to
DISK_A/clickhouse/metadata
directory (if we have it backed up). After db restart, the table will be attached to the ClickHouse with all the parts fromDISK_B
present without manually moving them to detach folder and reattaching. This saves time making replica healthy because then ZK only have to restore data fromDISK_A
from the another replica.I noticed that in backup metadata folder, table creation query have UUID in it so in theory backup tool could recreate the same scenario by running
ATTACH TABLE
instead ofCREATE TABLE
? Would it make sense to provide additional flag torestore
command which would define whetherATTACH
orCREATE
statement should be ran for schema restoration? I seen that something similar is happening whenrestore_as_attach
is set to true, but its only relevant when on data restoration flow.If this make sense I would gladly contribute on this feature.
Beta Was this translation helpful? Give feedback.
All reactions