Skip to content

Commit 9cb7737

Browse files
authored
add Recovery from Operational Errors (#1841)
1 parent 6899ae2 commit 9cb7737

File tree

3 files changed

+200
-1
lines changed

3 files changed

+200
-1
lines changed
Lines changed: 196 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,196 @@
1+
---
2+
title: Recovery from Operational Errors
3+
---
4+
import IndexOverviewList from '@site/src/components/IndexOverviewList';
5+
6+
# Recovery from Operational Errors
7+
8+
This guide provides step-by-step instructions for recovering from common operational errors in Databend.
9+
10+
## Introduction
11+
12+
Databend can help you recover from these common operational errors:
13+
- **Accidentally dropped databases**
14+
- **Accidentally dropped tables**
15+
- **Incorrect data modifications (UPDATE/DELETE operations)**
16+
- **Accidentally truncated tables**
17+
- **Data loading mistakes**
18+
- **Schema evolution rollbacks** (reverting table structure changes)
19+
- **Dropped columns or constraints**
20+
21+
These recovery capabilities are powered by Databend's FUSE engine with its Git-like storage design, which maintains snapshots of your data at different points in time.
22+
23+
## Recovery Scenarios and Solutions
24+
25+
### Scenario: Accidentally Dropped Database
26+
27+
If you've accidentally dropped a database, you can restore it using the `UNDROP DATABASE` command:
28+
29+
1. Identify the dropped database:
30+
31+
```sql
32+
SHOW DROP DATABASES LIKE '%sales_data%';
33+
```
34+
35+
2. Restore the dropped database:
36+
37+
```sql
38+
UNDROP DATABASE sales_data;
39+
```
40+
41+
3. Verify the database has been restored:
42+
43+
```sql
44+
SHOW DATABASES;
45+
```
46+
47+
4. Restore ownership (if needed):
48+
49+
```sql
50+
GRANT OWNERSHIP on sales_data.* to ROLE <role_name>;
51+
```
52+
53+
**Important**: A dropped database can only be restored within the retention period (default is 24 hours).
54+
55+
For more details, see [UNDROP DATABASE](/sql/sql-commands/ddl/database/undrop-database) and [SHOW DROP DATABASES](/sql/sql-commands/ddl/database/show-drop-databases).
56+
57+
### Scenario: Accidentally Dropped Table
58+
59+
If you've accidentally dropped a table, you can restore it using the `UNDROP TABLE` command:
60+
61+
1. Identify the dropped table:
62+
63+
```sql
64+
SHOW DROP TABLES LIKE '%order%';
65+
```
66+
67+
2. Restore the dropped table:
68+
69+
```sql
70+
UNDROP TABLE sales_data.orders;
71+
```
72+
73+
3. Verify the table has been restored:
74+
75+
```sql
76+
SHOW TABLES FROM sales_data;
77+
```
78+
79+
4. Restore ownership (if needed):
80+
81+
```sql
82+
GRANT OWNERSHIP on sales_data.orders to ROLE <role_name>;
83+
```
84+
85+
**Important**: A dropped table can only be restored within the retention period (default is 24 hours).
86+
87+
For more details, see [UNDROP TABLE](/sql/sql-commands/ddl/table/ddl-undrop-table) and [SHOW DROP TABLES](/sql/sql-commands/ddl/table/show-drop-tables).
88+
89+
### Scenario: Incorrect Data Updates or Deletions
90+
91+
If you've accidentally modified or deleted data in a table, you can restore it to a previous state using the `FLASHBACK TABLE` command:
92+
93+
1. Identify the snapshot ID or timestamp before the incorrect operation:
94+
95+
```sql
96+
SELECT * FROM fuse_snapshot('sales_data', 'orders');
97+
```
98+
99+
```text
100+
snapshot_id: c5c538d6b8bc42f483eefbddd000af7d
101+
snapshot_location: 29356/44446/_ss/c5c538d6b8bc42f483eefbddd000af7d_v2.json
102+
format_version: 2
103+
previous_snapshot_id: NULL
104+
[... ...]
105+
timestamp: 2023-04-19 04:20:25.062854
106+
```
107+
108+
2. Restore the table to the previous state:
109+
110+
```sql
111+
-- Using snapshot ID
112+
ALTER TABLE sales_data.orders FLASHBACK TO (SNAPSHOT => 'c5c538d6b8bc42f483eefbddd000af7d');
113+
114+
-- Or using timestamp
115+
ALTER TABLE sales_data.orders FLASHBACK TO (TIMESTAMP => '2023-04-19 04:20:25.062854'::TIMESTAMP);
116+
```
117+
118+
3. Verify the data has been restored:
119+
120+
```sql
121+
SELECT * FROM sales_data.orders LIMIT 3;
122+
```
123+
124+
**Important**: Flashback operations are only possible for existing tables and within the retention period.
125+
126+
For more details, see [FLASHBACK TABLE](/sql/sql-commands/ddl/table/flashback-table).
127+
128+
### Scenario: Schema Evolution Rollbacks
129+
If you've made unwanted changes to a table's structure, you can revert to the previous schema:
130+
131+
1. Create a table and add some data:
132+
133+
```sql
134+
CREATE OR REPLACE TABLE customers (id INT, name VARCHAR, email VARCHAR);
135+
INSERT INTO customers VALUES (1, 'John', '[email protected]');
136+
```
137+
138+
2. Make schema changes:
139+
```sql
140+
ALTER TABLE customers ADD COLUMN phone VARCHAR;
141+
DESC customers;
142+
```
143+
144+
Output:
145+
```text
146+
┌─────────┬─────────┬──────┬─────────┬─────────┐
147+
│ Field │ Type │ Null │ Default │ Extra │
148+
├─────────┼─────────┼──────┼─────────┼─────────┤
149+
│ id │ INT │ YES │ NULL │ │
150+
│ name │ VARCHAR │ YES │ NULL │ │
151+
│ email │ VARCHAR │ YES │ NULL │ │
152+
│ phone │ VARCHAR │ YES │ NULL │ │
153+
└─────────┴─────────┴──────┴─────────┴─────────┘
154+
```
155+
156+
3. Find the snapshot ID from before the schema change:
157+
```sql
158+
SELECT * FROM fuse_snapshot('default', 'customers');
159+
```
160+
161+
Output:
162+
```text
163+
snapshot_id: 01963cefafbb785ea393501d2e84a425 timestamp: 2025-04-16 04:51:03.227000 previous_snapshot_id: 01963ce9cc29735b87886a08d3ca7e2f
164+
snapshot_id: 01963ce9cc29735b87886a08d3ca7e2f timestamp: 2025-04-16 04:44:37.289000 previous_snapshot_id: NULL
165+
```
166+
167+
4. Revert to the previous schema (using the earlier snapshot):
168+
```sql
169+
ALTER TABLE customers FLASHBACK TO (SNAPSHOT => '01963ce9cc29735b87886a08d3ca7e2f');
170+
```
171+
172+
5. Verify the schema has been restored:
173+
```sql
174+
DESC customers;
175+
```
176+
Output:
177+
```text
178+
┌─────────┬─────────┬──────┬─────────┬─────────┐
179+
│ Field │ Type │ Null │ Default │ Extra │
180+
├─────────┼─────────┼──────┼─────────┼─────────┤
181+
│ id │ INT │ YES │ NULL │ │
182+
│ name │ VARCHAR │ YES │ NULL │ │
183+
│ email │ VARCHAR │ YES │ NULL │ │
184+
└─────────┴─────────┴──────┴─────────┴─────────┘
185+
```
186+
187+
188+
## Important Considerations and Limitations
189+
190+
- **Time Constraints**: Recovery only works within the retention period (default: 24 hours).
191+
- **Name Conflicts**: Cannot undrop if an object with the same name exists — [rename database](/sql/sql-commands/ddl/database/ddl-alter-database) or [rename table](/sql/sql-commands/ddl/table/ddl-rename-table) first.
192+
- **Ownership**: Ownership isn't automatically restored—manually grant it after recovery.
193+
- **Transient Tables**: Flashback doesn't work for transient tables (no snapshots stored).
194+
195+
**For Emergency Situations**: Facing critical data loss? Contact Databend Support immediately for help.
196+
[Contact Databend Support](https://www.databend.com/contact-us/)

docs/en/sql-reference/10-sql-commands/00-ddl/00-database/undrop-database.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,9 @@ title: UNDROP DATABASE
44

55
Restores the most recent version of a dropped database. This leverages the Databend Time Travel feature; a dropped object can be restored only within a retention period (defaults to 24 hours).
66

7-
See also: [DROP DATABASE](ddl-drop-database.md)
7+
**See also:**
8+
[DROP DATABASE](ddl-drop-database.md)
9+
[SHOW DROP DATABASES](show-drop-databases.md)
810

911
## Syntax
1012

docs/en/sql-reference/10-sql-commands/00-ddl/01-table/21-ddl-undrop-table.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@ Restores the recent version of a dropped table. This leverages the Databend Time
99
- [CREATE TABLE](./10-ddl-create-table.md)
1010
- [DROP TABLE](./20-ddl-drop-table.md)
1111
- [SHOW TABLES](show-tables.md)
12+
- [SHOW DROP TABLES](show-drop-tables.md)
1213

1314
## Syntax
1415

0 commit comments

Comments
 (0)