Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update recover-statements.md #876

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions session3/chapter5/recover-statements.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
## 5.2 利用 Recover/Flashback 命令秒恢复误删表
## 5.2 利用 Recover/Flashback 命令快速恢复误删表

对于 DBA 来说,删库跑路永远是被调侃的哏,近在眼前的某微商平台的大面积宕机事件给企业管理人员及数据库运维团队带来的启示仍在被不断讨论。当然为了应对大面积的恶意删库跑路行为,可能真的是防不胜防,不过这种情况也非常罕见。但是大家尤其是线上运维 DBA 在维护数据库的过程中,出现删错表/库的情况却是很容易出现的,下面来看一下 TiDB 提供的快速恢复误删表的功能。
对于 DBA 来说,删库跑路永远是被调侃的梗,近在眼前的某微商平台的大面积宕机事件给企业管理人员及数据库运维团队带来的启示仍在被不断讨论。当然为了应对大面积的恶意删库跑路行为,可能真的是防不胜防,不过这种情况也非常罕见。但是大家尤其是 DBA 在维护数据库的过程中,出现误删表/库的情况却是很容易出现的,下面来看一下 TiDB 提供的快速恢复误删表的功能。
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
对于 DBA 来说,删库跑路永远是被调侃的梗,近在眼前的某微商平台的大面积宕机事件给企业管理人员及数据库运维团队带来的启示仍在被不断讨论。当然为了应对大面积的恶意删库跑路行为,可能真的是防不胜防,不过这种情况也非常罕见。但是大家尤其是 DBA 在维护数据库的过程中,出现误删表/库的情况却是很容易出现的,下面来看一下 TiDB 提供的快速恢复误删表的功能。
对于 DBA 来说,删库跑路永远是被调侃的梗,近在眼前的某微商平台的大面积宕机事件给企业管理人员及数据库运维团队带来的启示仍在被不断讨论。当然为了应对大面积的恶意删库跑路行为,可能真的是防不胜防,不过这种情况也非常罕见。但是大家,尤其是 DBA 在维护数据库的过程中,出现误删表/库的情况却是很容易出现的,下面来看一下 TiDB 提供的快速恢复误删表的功能。


### 5.2.1 Recover 实现原理

TiDB 在删除表时,实际上只删除了表的元信息,并将需要删除的表数据(行数据和索引数据)写一条数据到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。
TiDB 在删除表时,实际上只删除了表的元信息,并将需要删除的表数据(行数据和索引数据)的 Key 范围写一条记录到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。

所以,RECOVER TABLE 只需要在 GC Worker 还没删除表数据前,恢复表的元信息并删除 mysql.gc_delete_range 表中相应的行记录就可以了。恢复表的元信息可以用 TiDB 的快照读实现,TiDB 中表的恢复是通过快照读获取表的元信息后,再走一次类似于 CREATE TABLE 的建表流程,所以 RECOVER TABLE 实际上也是一种 DDL。

Expand Down Expand Up @@ -120,7 +120,7 @@ MySQL [test]> ADMIN SHOW DDL JOBS;
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
```

从 DDL 记录可以看到,我们一共执行了 2 次 drop table t2 的操作,如果只执行 recover table t2 恢复的是最近一次删除的表。如果我希望恢复前面一次删除的动作,就需要用到下面的命令
从 DDL 记录可以看到,我们一共执行了 2 次 drop table t2 的操作,如果只执行 recover table t2恢复的是最近一次删除的表。如果我希望恢复前面一次删除的动作,就需要用到下面的命令
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

上面这个执行结果,如果在纸质版本或者 PDF 上肯能是个灾难。。要不然改成截图,或者 ADMIN SHOW DDL JOBS\G;?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

不会,pdf 可以兼容 markdown 的格式

```

MySQL [test]> recover table by job 70;
Expand Down