服务器没有再写东西进去了,就这样停着...
mysql> show global variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin | OFF |
+---------------+-------+
1 row in set (0.04 sec)
有希望救回来吗? 在网上搜了一些文章,几乎都是依靠日志救回来的。。。
1
DoctorCat 2020-11-03 19:35:46 +08:00
跑路吧兄弟
|
2
wunonglin 2020-11-03 19:39:16 +08:00
建议出国
|
3
fengpan567 2020-11-03 19:47:44 +08:00
无了
|
4
uselessVisitor 2020-11-03 19:49:17 +08:00
你没了兄弟
|
5
PonysDad 2020-11-03 19:58:27 +08:00 via iPhone
问问是不是有无系统快照,没有就快逃,快逃,快逃。。。
|
6
pppguest3962 OP ...
|
7
jiezhi 2020-11-03 20:02:11 +08:00 via iPhone
磁盘恢复?
|
8
irytu 2020-11-03 20:03:04 +08:00 via iPhone
没开 log 基本是毁了 估计没啥 recovery 的方法😂
|
9
kiracyan 2020-11-03 20:11:30 +08:00
跑路
|
10
Kaiv2 2020-11-03 20:29:48 +08:00
好奇是怎么不小心 truncate 的
|
11
xdsty 2020-11-03 21:22:11 +08:00
binlog 没开啊,也不是啥重要的数据吧 先找找有没有全量备份的数据
|
12
AkideLiu 2020-11-03 22:13:38 +08:00 via iPhone
快点搜一下哪个国家还没签引渡,争分夺秒啊
|
13
zzzain46 2020-11-03 22:17:41 +08:00
TRUNCATE 不记录二进制日志文件,无法通过反解析二进制日志文件恢复删除的数据
|
14
ElmerZhang 2020-11-03 23:01:48 +08:00
truncate 的原理是创建一张新表,把原表直接删除掉。
如果是用的 MyISAM 引擎的话,可以看看有没有办法恢复文件。 |
15
oneoyn 2020-11-03 23:12:16 +08:00
binlog 有没有
|
16
pppguest3962 OP 谢谢各位兄弟关心,
总共 truncate 了 4 张表,其中有一张估计 400W 条左右 表说重要也重要,也不重要,功能是一个类似 index + sum 资料的索引表,请求没有查到的话,服务器会去做一些占时成本很高的运算,然后再把结果加进来而已,还好刚过了月末汇总期,这个表(包括整个服务器)请求量不大,月初停一下问题不大,有 6 月份的备份整表,还是能勉强应付的 还好这里不是数据就是金钱的地方 手贱是不应该的 老问题,新事故了:MySQL 新手操作,Navicat 12 的 F6 多窗口,反正就是眼黑,还是怎么了,把命令贴错地方(测试库和正式库没分清楚) 发帖前经过搜索已有答案,看了已经觉得救回来很困难了,只是看看有无北斗星高手的一句话来点化路子而已 7 点到现在,没喝水没吃饭,抽了一包利群 现在去麦当劳 感谢各位兄弟关心。真的很感谢!!! |
17
lscexpress 2020-11-03 23:33:16 +08:00
@pppguest3962 下次操作前,把车票先买好
|
18
iwiki 2020-11-04 00:36:16 +08:00
无解,之前我也误操作过,后来通过自己的日志表重新组合,算是恢复了
|
19
ericgui 2020-11-04 03:47:42 +08:00
为何总是直接操作生产数据库呢?
虽然我也这么做,每次都如履薄冰 |
20
xfabs 2020-11-04 07:54:19 +08:00 via iPhone 1
正式库,一个人写 SQL 另外一个人执行,这样稳点。
|
21
whywhywhy 2020-11-04 08:27:47 +08:00
还不赶紧买 NAS 备份?
重要的数据库,必须 NAS 备份,白群晖! 重要的数据库,必须订阅同步到备用数据库! 重要的数据库,必须每天的完整备份和 N 次的差异备份! 上次备份在六月份?偷懒一时爽,出事火葬场咯老哥。。。 安全措施从来都是 1 、2 、3 、4,不搞措施,不搞预案,手工做大量 /危险数据操作不先备份,不先 select,平时也不备份,,,,只能说事故绝对不是偶然,而是必然。 上面说叫你跑路真的是没错,你什么预防措施都不搞,出问题你就只能跑。 |
22
littlewing 2020-11-04 09:00:31 +08:00 via iPhone
没备份就准备跑路吧,只有 binlog 也救不回来的
|
23
dbpe 2020-11-04 09:02:20 +08:00
我的习惯..一切的都在本地写好 sql...到服务器 mysql cli 执行..
|
24
openbsd 2020-11-04 09:10:23 +08:00
|
25
avenger 2020-11-04 09:11:58 +08:00
用 RDS 的好处出来了
|
26
kiddingU 2020-11-04 09:14:17 +08:00
ide 连接的账号最好是只能读的账号,因为一不留神就点错了,其他操作还是去终端下面执行比较好
|
27
kiddingU 2020-11-04 09:14:57 +08:00
客户端居然还能连接生产环境数据库,只能说一句握草
|
28
zone10 2020-11-04 09:45:41 +08:00
我一直认为被菜鸟删库了只能是上面人的锅, 跟你无关
|
29
nocrush 2020-11-04 10:01:10 +08:00
本地连接生产的话,就直接来一个可读账号吧
|
30
zgray2580 2020-11-04 10:31:13 +08:00
可以对账号进行权限设置,也就是楼上说的 可读账号,只有 select update 这些 这样能避免误操作
|
31
mikicomo 2020-11-04 10:54:12 +08:00
生产库,当然是发邮件,让运维执行,要不就提工单
|
32
tesguest123 2020-11-04 11:41:53 +08:00 via Android
@mikicomo binlog 都不开哪有什么运维,估计就是开发=需求+前端+运维+测试。手动狗头…
|
33
zpfhbyx 2020-11-04 11:46:08 +08:00
|
34
RudyS 2020-11-04 11:52:41 +08:00
这就属于就怕万一的万一;生产库给了权限,我都会先备份再操作,扛不起。
|
35
weiwenhao 2020-11-04 14:17:13 +08:00
Navicat 正式数据我都设置 color 为红色,,防止看错, 每次操作完第一件事就是关闭连接..
|
36
imycc 2020-11-04 14:23:21 +08:00
账号权限要细化,普通业务账号就只开查询和更新的权限,truncate 这种杀器只应该 DBA 有,普通运维都不应该拿着。就怕哪天误操作。
至于 Navicat 直连生产环境,我也是不建议的。其实命令行直连也是不建议的,你这种分不清测试和生产环境的坑我们也踩过。。 保险一点的做法,应该是 SQL 在测试环境验证完,提交给 DBA 申请变更,审批之后通过系统自动执行,才能比较好地避免犯糊涂。 不过你们还用着 mysql5.1 。。我说的那些估计都没有吧。。。那就只能根据人力情况,自己规范自己了。至少定时备份得加上,最后的兜底手段了。 |
37
angryfish 2020-11-04 14:36:56 +08:00 via iPhone
跑路吧。即使有 binlog 也是恢复不了的,truncate
|
38
OldHu 2020-11-04 14:47:22 +08:00
老兄试试看这个软件 DBRECOVER for MySQL,看看有没有机会恢复数据:
https://www.parnassusdata.com/zh-hans/node/1342 @pppguest3962 |
39
zsl199512101234 2020-11-04 14:56:01 +08:00
以前待过一家公司,凌晨 1 点有人执行了 drop database,直接 gg
|
40
WytheHuang 2020-11-04 15:03:42 +08:00
像我们公司开发只有正式库的查询权限,删不了库。
|
41
chengz 2020-11-04 15:17:21 +08:00
账户权限控制太重要了
|
42
MySong 2020-11-04 15:22:34 +08:00
truncate 无法通过 binlog 回滚
|
43
mazhan465 2020-11-04 17:14:58 +08:00
有点实力
|
44
iminto 2020-11-04 18:13:03 +08:00
|
45
eamon666 2020-11-04 18:41:09 +08:00
@pppguest3962 后端 都是人下人
|
46
GaoGeYang 2020-11-04 20:10:27 +08:00 via iPhone
跑路
|
47
cs371332219 2020-11-05 08:29:43 +08:00 via Android
上云了没,上云的话,问问厂商有没有快照
|
48
Achiii 2020-11-05 10:40:09 +08:00
(测试库和正式库没分清楚) 也太真实了 ,但是 truncate 不能回滚
|
49
dany813 2020-11-05 13:19:26 +08:00
可怕。没开定时备份吗
|
50
lx0758 2020-11-05 14:32:10 +08:00
去这个网站看看吧, 可能会有点用
http://www.airchina.com.cn/ |