MySQL 5.5 Community Server MySQL 5.6 Community Server Percona Configuration Wizard XtraBackup 搭建主从复制 Great Sites on MySQL Percona MySQL Performance Blog Severalnines 推荐管理工具 Sequel Pro phpMyAdmin 推荐书目 MySQL Cookbook
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 
Mysql 5.1.73，不小心 truncate 一张表，也没有开日志，还能恢复么？
pppguest3962 2020-11-03 19:22:25 +08:00 9274 次点击这是一个创建于 1825 天前的主题，其中的信息可能已经有所发展或是发生改变。
服务器没有再写东西进去了，就这样停着...
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 shakaraka PRO 建议出国 |
 | 3 fengpan567 2020-11-03 19:47:44 +08:00 无了 |
 | 4 zm8m93Q1e5otOC69 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  9 谢谢各位兄弟关心， 总共 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 justseemore 2020-11-04 11:46:08 +08:00 生产库有 truncate 权限？ niu beeeeeeeeeeeeeeee 爆破音 |
 | 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 GBdG6clg2Jy17ua5 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/ |
Select Language