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 replies • 2020-11-05 14:32:10 +08:00

DoctorCat

Nov 3, 2020

跑路吧兄弟

shakaraka

PRO

Nov 3, 2020

建议出国

fengpan567

Nov 3, 2020

无了

zm8m93Q1e5otOC69

Nov 3, 2020

你没了兄弟

PonysDad

Nov 3, 2020 via iPhone

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

pppguest3962

Nov 3, 2020

...

jiezhi

Nov 3, 2020 via iPhone

磁盘恢复？

irytu

Nov 3, 2020 via iPhone

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

kiracyan

Nov 3, 2020

跑路

Kaiv2

Nov 3, 2020

好奇是怎么不小心 truncate 的

xdsty

Nov 3, 2020

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

AkideLiu

Nov 3, 2020 via iPhone

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

zzzain46

Nov 3, 2020

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

ElmerZhang

Nov 3, 2020

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

oneoyn

Nov 3, 2020

binlog 有没有

pppguest3962

Nov 3, 2020

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

lscexpress

Nov 3, 2020

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

iwiki

Nov 4, 2020

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

ericgui

Nov 4, 2020

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

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

xfabs

Nov 4, 2020 via iPhone

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

whywhywhy

Nov 4, 2020

还不赶紧买 NAS 备份？

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

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

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

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

littlewing

Nov 4, 2020 via iPhone

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

dbpe

Nov 4, 2020

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

openbsd

Nov 4, 2020

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

avenger

Nov 4, 2020

用 RDS 的好处出来了

kiddingU

Nov 4, 2020

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

kiddingU

Nov 4, 2020

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

zone10

Nov 4, 2020

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

nocrush

Nov 4, 2020

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

zgray2580

Nov 4, 2020

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

mikicomo

Nov 4, 2020

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

tesguest123

Nov 4, 2020 via Android

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

justseemore

Nov 4, 2020

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

randomuuid

Nov 4, 2020

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

weiwenhao

Nov 4, 2020

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

imycc

Nov 4, 2020

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

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

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