Mysql 5.1.73，不小心 truncate 一张表，也没有开日志，还能恢复么？

mysql> show global variables like 'log_bin';  
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | OFF   |
+---------------+-------+
1 row in set (0.04 sec)

有希望救回来吗？在网上搜了一些文章，几乎都是依靠日志救回来的。。。

MySQL

日志

Variables

log_bin'

50 条回复 • 2020-11-05 14:32:10 +08:00

DoctorCat

2020-11-03 19:35:46 +08:00

跑路吧兄弟

wunonglin

2020-11-03 19:39:16 +08:00

建议出国

fengpan567

2020-11-03 19:47:44 +08:00

无了

uselessVisitor

2020-11-03 19:49:17 +08:00

你没了兄弟

PonysDad

2020-11-03 19:58:27 +08:00 via iPhone

问问是不是有无系统快照，没有就快逃，快逃，快逃。。。

pppguest3962

2020-11-03 20:00:54 +08:00

...

jiezhi

2020-11-03 20:02:11 +08:00 via iPhone

磁盘恢复？

irytu

2020-11-03 20:03:04 +08:00 via iPhone

没开 log 基本是毁了估计没啥 recovery 的方法😂

kiracyan

2020-11-03 20:11:30 +08:00

跑路

Kaiv2

2020-11-03 20:29:48 +08:00

好奇是怎么不小心 truncate 的

xdsty

2020-11-03 21:22:11 +08:00

binlog 没开啊，也不是啥重要的数据吧先找找有没有全量备份的数据

AkideLiu

2020-11-03 22:13:38 +08:00 via iPhone

快点搜一下哪个国家还没签引渡，争分夺秒啊

zzzain46

2020-11-03 22:17:41 +08:00

TRUNCATE 不记录二进制日志文件，无法通过反解析二进制日志文件恢复删除的数据

ElmerZhang

2020-11-03 23:01:48 +08:00

truncate 的原理是创建一张新表，把原表直接删除掉。
如果是用的 MyISAM 引擎的话，可以看看有没有办法恢复文件。

oneoyn

2020-11-03 23:12:16 +08:00

binlog 有没有

pppguest3962

2020-11-03 23:28:26 +08:00

谢谢各位兄弟关心，
总共 truncate 了 4 张表，其中有一张估计 400W 条左右
表说重要也重要，也不重要，功能是一个类似 index + sum 资料的索引表，请求没有查到的话，服务器会去做一些占时成本很高的运算，然后再把结果加进来而已，还好刚过了月末汇总期，这个表（包括整个服务器）请求量不大，月初停一下问题不大，有 6 月份的备份整表，还是能勉强应付的
还好这里不是数据就是金钱的地方
手贱是不应该的
老问题，新事故了：MySQL 新手操作，Navicat 12 的 F6 多窗口，反正就是眼黑，还是怎么了，把命令贴错地方(测试库和正式库没分清楚）
发帖前经过搜索已有答案，看了已经觉得救回来很困难了，只是看看有无北斗星高手的一句话来点化路子而已
7 点到现在，没喝水没吃饭，抽了一包利群
现在去麦当劳
感谢各位兄弟关心。真的很感谢！！！

lscexpress

2020-11-03 23:33:16 +08:00

@pppguest3962 下次操作前，把车票先买好

iwiki

2020-11-04 00:36:16 +08:00

无解，之前我也误操作过，后来通过自己的日志表重新组合，算是恢复了

ericgui

2020-11-04 03:47:42 +08:00

为何总是直接操作生产数据库呢？

虽然我也这么做，每次都如履薄冰

xfabs

2020-11-04 07:54:19 +08:00 via iPhone

正式库，一个人写 SQL 另外一个人执行，这样稳点。

whywhywhy

2020-11-04 08:27:47 +08:00

还不赶紧买 NAS 备份？

重要的数据库，必须 NAS 备份，白群晖！
重要的数据库，必须订阅同步到备用数据库！
重要的数据库，必须每天的完整备份和 N 次的差异备份！

上次备份在六月份？偷懒一时爽，出事火葬场咯老哥。。。

安全措施从来都是 1 、2 、3 、4，不搞措施，不搞预案，手工做大量 /危险数据操作不先备份，不先 select，平时也不备份，，，，只能说事故绝对不是偶然，而是必然。

上面说叫你跑路真的是没错，你什么预防措施都不搞，出问题你就只能跑。

littlewing

2020-11-04 09:00:31 +08:00 via iPhone

没备份就准备跑路吧，只有 binlog 也救不回来的

dbpe

2020-11-04 09:02:20 +08:00

我的习惯..一切的都在本地写好 sql...到服务器 mysql cli 执行..

openbsd

2020-11-04 09:10:23 +08:00

还真有生产系统不做备份的大神？

avenger

2020-11-04 09:11:58 +08:00

用 RDS 的好处出来了

kiddingU

2020-11-04 09:14:17 +08:00

ide 连接的账号最好是只能读的账号，因为一不留神就点错了，其他操作还是去终端下面执行比较好

kiddingU

2020-11-04 09:14:57 +08:00

客户端居然还能连接生产环境数据库，只能说一句握草

zone10

2020-11-04 09:45:41 +08:00

我一直认为被菜鸟删库了只能是上面人的锅, 跟你无关

nocrush

2020-11-04 10:01:10 +08:00

本地连接生产的话，就直接来一个可读账号吧

zgray2580

2020-11-04 10:31:13 +08:00

可以对账号进行权限设置，也就是楼上说的可读账号，只有 select update 这些这样能避免误操作

mikicomo

2020-11-04 10:54:12 +08:00

生产库，当然是发邮件，让运维执行，要不就提工单

tesguest123

2020-11-04 11:41:53 +08:00 via Android

@mikicomo binlog 都不开哪有什么运维，估计就是开发=需求+前端+运维+测试。手动狗头…

zpfhbyx

2020-11-04 11:46:08 +08:00

生产库有 truncate 权限？ niu beeeeeeeeeeeeeeee 爆破音

RudyS

2020-11-04 11:52:41 +08:00

这就属于就怕万一的万一；生产库给了权限，我都会先备份再操作，扛不起。

weiwenhao

2020-11-04 14:17:13 +08:00

Navicat 正式数据我都设置 color 为红色,,防止看错, 每次操作完第一件事就是关闭连接..

imycc

2020-11-04 14:23:21 +08:00

账号权限要细化，普通业务账号就只开查询和更新的权限，truncate 这种杀器只应该 DBA 有，普通运维都不应该拿着。就怕哪天误操作。
至于 Navicat 直连生产环境，我也是不建议的。其实命令行直连也是不建议的，你这种分不清测试和生产环境的坑我们也踩过。。

保险一点的做法，应该是 SQL 在测试环境验证完，提交给 DBA 申请变更，审批之后通过系统自动执行，才能比较好地避免犯糊涂。

不过你们还用着 mysql5.1 。。我说的那些估计都没有吧。。。那就只能根据人力情况，自己规范自己了。至少定时备份得加上，最后的兜底手段了。