DBA 之伤 -truncate/drop
作者: Jamin 原文来源:https://tidb.net/blog/6322043f
【是否原创】是
【首发渠道】TiDB 社区
【首发渠道链接】其他平台首发请附上对应链接
【正文】
引言
DBA 职业是一种高危职业,承担着公司数据库健壮稳定高效运行工作,在日常工作很容易就触碰到DML
或者TRUNCATE
或者 DROP
操作。没有删过库,没有TRUNCATE表
的 DBA 不是一个好厨师。
介绍
日常工作中出现业务误操作或者 DBA 误操作执行了 DML 操作,可以使用FLUSHBACK
功能。但是 DDL 闪回却很难实现。当有一个任务SQL工单
需求是需要TRUNCATE或者DROP表
时候,那么如何对业务RPO
影响到最小呢?😱,可以使用FLUSHBAKC 、 RECOVER TABLE
,在GC lifetime
时间失效了。怎么办?
有的大佬说执行TRUNCATE
或者DROP
语句之前先备份。这个操作是正确的。在表数据库非常小的时候,不管备份或者恢复都会非常快。那么……如果表数据量是非常多, 恰好又必须要执行操作的工单,那么我们如何考虑备份与恢复的快速呢?
实现思路
MySQL 的DML语句 FLUSHBACK
功能实现:解析 BINLOG,``功能实现: 增加一个回收站库,不管是 MySQL 还是其他数据库都可以使用这样方式进行操作
实现
需求:
支持所有数据库类型
支持参数列表
TRUNCATE
DROP
集群名称
ip and port
执行人
全库 or 单标 or 多表
执行 SQL 记录数据库中以及回滚 SQL 生成
代码片段
表结构
程序代码代码入口
执行操作
收益
1、通过查询数据库就能发现是什么时候执行的操作
2、可以快读定位到执行语句以及回滚SQL
3、安全执行TRUNCATE
、DROP
截图
版权声明: 本文为 InfoQ 作者【TiDB 社区干货传送门】的原创文章。
原文链接:【http://xie.infoq.cn/article/19bccc053d12f08668c48ed97】。文章转载请联系作者。
评论