From e4c8a0d7f46f8860b6dc694269db31ab0f5cfa90 Mon Sep 17 00:00:00 2001 From: Doug Tidwell Date: Tue, 11 Feb 2025 20:57:43 -0500 Subject: [PATCH] Minor updates to detached parts article --- .../recovery-after-complete-data-loss.md | 8 ++++---- .../detached-parts.md | 20 +++++++++++-------- 2 files changed, 16 insertions(+), 12 deletions(-) diff --git a/content/en/altinity-kb-setup-and-maintenance/recovery-after-complete-data-loss.md b/content/en/altinity-kb-setup-and-maintenance/recovery-after-complete-data-loss.md index 66436275f0..be281b6a42 100644 --- a/content/en/altinity-kb-setup-and-maintenance/recovery-after-complete-data-loss.md +++ b/content/en/altinity-kb-setup-and-maintenance/recovery-after-complete-data-loss.md @@ -1,12 +1,12 @@ --- -title: "recovery-after-complete-data-loss" -linkTitle: "recovery-after-complete-data-loss" +title: "Recovery after complete data loss" +linkTitle: "Recovery after complete data loss" weight: 100 description: >- - Recovery after complete data loss + When disaster strikes --- -# Atomic & Ordinary databases. +## Atomic & Ordinary databases. srv1 -- good replica diff --git a/content/en/altinity-kb-useful-queries/detached-parts.md b/content/en/altinity-kb-useful-queries/detached-parts.md index 42258205d3..4e75192cbe 100644 --- a/content/en/altinity-kb-useful-queries/detached-parts.md +++ b/content/en/altinity-kb-useful-queries/detached-parts.md @@ -1,20 +1,24 @@ --- -title: "Can detached parts be dropped?" +title: "Can detached parts in ClickHouse® be dropped?" linkTitle: "Can detached parts be dropped?" description: > - Can detached parts be dropped? + Cleaning up detached parts without data loss +keywords: + - clickhouse detached parts + - clickhouse detach + - clickhouse drop partition --- -Here is what different statuses mean: +ClickHouse® users should monitor for detached parts and act quickly when they appear. Here is what the different statuses of detached parts mean: -1. Parts are renamed to 'ignored' if they were found during ATTACH together with other, bigger parts that cover the same blocks of data, i.e. they were already merged into something else. -2. Parts are renamed to 'broken' if ClickHouse® was not able to load data from the parts. There could be different reasons: some files are lost, checksums are not correct, etc. -3. Parts are renamed to 'unexpected' if they are present locally, but are not found in ZooKeeper, in case when an insert was not completed properly. The part is detached only if it's old enough (5 minutes), otherwise CH registers this part in ZooKeeper as a new part. -4. Parts are renamed to 'cloned' if ClickHouse have had some parts on local disk while repairing lost replica so already existed parts being renamed and put in detached directory. Controlled by setting `detach_old_local_parts_when_cloning_replica`. +1. Parts are renamed to **ignored** if they were found during ATTACH together with other, bigger parts that cover the same blocks of data, i.e. they were already merged into something else. +2. Parts are renamed to **broken** if ClickHouse was not able to load data from the parts. There could be different reasons: some files are lost, checksums are not correct, etc. +3. Parts are renamed to **unexpected** if they are present locally, but are not found in ZooKeeper, in case when an insert was not completed properly. The part is detached only if it's old enough (5 minutes), otherwise CH registers this part in ZooKeeper as a new part. +4. Parts are renamed to **cloned** if ClickHouse has had some parts on local disk while repairing lost replica so already existed parts being renamed and put in detached directory. Controlled by setting `detach_old_local_parts_when_cloning_replica`. 'Ignored' parts are safe to delete. 'Unexpected' and 'broken' should be investigated, but it might not be an easy thing to do, especially for older parts. If the `system.part_log table` is enabled you can find some information there. Otherwise you will need to look in `clickhouse-server.log` for what happened when the parts were detached. If there is another way you could confirm that there is no data loss in the affected tables, you could simply delete all detached parts. -It is important to monitor for detached parts and act quickly when they appear. If `clickhouse-server.log` is lost it might be impossible to figure out what happened and why the parts were detached. +Again, it is important to monitor for detached parts and act quickly when they appear. If `clickhouse-server.log` is lost it might be impossible to figure out what happened and why the parts were detached. You can use `system.asynchronous_metrics` or `system.detached_parts` for monitoring. ```sql select metric from system.asynchronous_metrics where metric ilike '%detach%'