You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes, due to crashes, zookeeper unavailability, slowness, or other reasons, some of the tables can be in Read-Only mode. This allows SELECTS but not INSERTS. So we need to do DROP / RESTORE replica procedure.
99
99
100
100
Just to be clear, this procedure **will not delete any data**, it will just re-create the metadata in zookeeper with the current state of the [ClickHouse replica](/altinity-kb-setup-and-maintenance/altinity-kb-data-migration/add_remove_replica/).
101
+
102
+
How it works:
101
103
102
104
```sql
103
105
ALTERTABLE table_name DROP DETACHED PARTITION ALL -- clean detached folder before operation. PARTITION ALL works only for the fresh clickhouse versions
104
106
DETACH TABLE table_name; -- Required for DROP REPLICA
105
-
-- Use the zookeeper_path and replica_name from the above query.
107
+
-- Use the zookeeper_path and replica_name from system.replicas.
106
108
SYSTEM DROP REPLICA 'replica_name'FROM ZKPATH '/table_path_in_zk'; -- It will remove everything from the /table_path_in_zk/replicas/replica_name
107
109
ATTACH TABLE table_name; -- Table will be in readonly mode, because there is no metadata in ZK and after that execute
108
110
SYSTEM RESTORE REPLICA table_name; -- It will detach all partitions, re-create metadata in ZK (like it's new empty table), and then attach all partitions back
109
-
SYSTEM SYNC REPLICA table_name; -- Wait for replicas to synchronize parts. Also it's recommended to check `system.detached_parts` on all replicas after recovery is finished.
110
-
SELECT name FROMsystem.detached_partsWHERE table ='table_name'; -- check for leftovers. See the potential problem here - https://gist.github.com/den-crane/702e4c8a1162dae7c2edf48a7c2dd00d
111
+
SYSTEM SYNC REPLICA table_name; --Not mandatory. It will Wait for replicas to synchronize parts. Also it's recommended to check `system.detached_parts` on all replicas after recovery is finished.
112
+
SELECT name FROMsystem.detached_partsWHERE table ='table_name'; -- check for leftovers. See the potential problems here https://altinity.com/blog/understanding-detached-parts-in-clickhouse
111
113
```
112
114
113
-
114
115
Starting from version 23, it's possible to use syntax [SYSTEM DROP REPLICA \'replica_name\' FROM TABLE db.table](https://clickhouse.com/docs/en/sql-reference/statements/system#drop-replica) instead of the `ZKPATH` variant, but you need to execute the above command from a different replica than the one you want to drop, which is not convenient sometimes. We recommend using the above method because it works with any version and is more reliable.
115
116
116
-
## Procedure for many replicas generating DDL
117
-
118
-
```sql
119
-
SELECT DISTINCT'DETACH TABLE '|| database ||'.'|| table ||' ON CLUSTER \'data\';'FROM clusterAllReplicas('data',system.replicas) WHERE active_replicas < total_replicas FORMAT TSVRaw;
120
-
121
-
SELECT DISTINCT'SYSTEM DROP REPLICA \''|| replica_name ||'\' FROM ZKPATH \''|| zookeeper_path ||'\';'FROM clusterAllReplicas('data',system.replicas) WHERE active_replicas < total_replicas FORMAT TSVRaw;
122
-
123
-
SELECT DISTINCT'ATTACH TABLE '|| database ||'.'|| table ||' ON CLUSTER \'data\';'FROM clusterAllReplicas('data',system.replicas) WHERE active_replicas < total_replicas FORMAT TSVRaw;
117
+
## Procedure to restore multiple tables in Read-Only mode per replica
124
118
125
-
SELECT DISTINCT'SYSTEM RESTORE REPLICA '|| database ||'.'|| table ||' ON CLUSTER \'data\';'FROM clusterAllReplicas('data',system.replicas) WHERE active_replicas < total_replicas FORMAT TSVRaw;
119
+
It is better to make an approach per replica, because restoring a replica using ON CLUSTER could lead to race conditions that would cause errors and a big stress in zookeeper/keeper
-- register table in clickhouse again - it will be in readonly mode.
137
-
ATTACH TABLE db.tableON CLUSTER '...';
149
+
This will generate the DDL statements to be executed per replica and generate an ouput that can be saved as an SQL file . It is important to execute the commands per replica in the sequence generated by the above DDL:
138
150
139
-
-- recreate the zookeeper data from the
140
-
SYSTEM RESTORE REPLICA db.nameON CLUSTER '...';
151
+
- DETACH the table
152
+
- DROP REPLICA
153
+
- ATTACH the table
154
+
- RESTORE REPLICA
141
155
142
-
--- do restart replica
156
+
If we do this in parallel a table could still be attaching while another query is dropping/restoring the replica in zookeeper, causing errors.
Here a bash script that will do the same as above but tailored to a single replica, you can call it like `bash restore_replica.sh chi-clickhouse-cluster-main-cluster-1-3`:
158
+
The following bash script will read the generated SQL file and execute the commands sequentially, asking for user input in case of errors. Simply save the generated SQL to a file (e.g. `recovery_commands.sql`) and run the script below (that you can name as `clickhouse_replica_recovery.sh`):
0 commit comments