1 levywang 2017-01-23 19:51:21 +08:00 加一句,挺急的 |
2 paranoiagu OP 补充, ibdata1 文件在 1.4 g |
![]() | 3 jarlyyn 2017-01-23 19:53:24 +08:00 ![]() |
4 paranoiagu OP 昨晚的备份文件不完整,刚才已经尝试导入昨天的备份。(导后才发现不完整) 彻底废了。。。。。。 |
5 paranoiagu OP 只有上月的数据了。 |
![]() | 6 jarlyyn 2017-01-23 20:22:14 +08:00 ![]() |
7 paranoiagu OP @jarlyyn 没有开。。。。 |
![]() | 8 shiny 2017-01-23 21:38:27 +08:00 从这个帖子可以学习到,没有经过验证的备份等于没备份。 |
![]() | 9 wdlth 2017-01-23 21:41:20 +08:00 ![]() 不开 binlog 也敢跑…… |
![]() | 11 dangyuluo 2017-01-23 23:19:56 +08:00 完全没办法想象,为什么会把这种端口暴露在公网。 |
![]() | 12 cxbig 2017-01-23 23:35:04 +08:00 ![]() 数据库应该每天都有一个有效备份 数据库只能让所在的 subnet 其他机器访问 登录内网必须先 SSH 堡垒机,只允许非 root 的 key-pair 方式 办公室以外的远程登录要先挂上堡垒机的 VPN ,至少是 L2TP via IPsec 级别 |
![]() | 13 likuku 2017-01-23 23:58:17 +08:00 没有有效的备份?节哀顺变。 |
14 kaneg 2017-01-24 00:07:36 +08:00 很多时候,失去了才知道珍惜。很多人意识不到备份的重要性,觉得是浪费时间和空间,根本不知道关键时候备份能救命。 |
![]() | 15 msg7086 2017-01-24 07:46:10 +08:00 ![]() Let me google it for you: https://twindb.com/recover-after-drop-table-innodb_file_per_table-is-off/ 如果你当场断电保护好现场的话,数据是可以救回来的。 |
16 paranoiagu OP 感谢各位,当时最大的错误就是没保护现场,应该用另一个机器恢复数据库。 |
17 paranoiagu OP @nfroot mysqldump 到一半就失败了。可能那个表放了附件,比较大,导致 dump 失败。备份文件又是每天变大的,所以以为都是完整备份。 |
18 paranoiagu OP @msg7086 那工具 twindb 闭源了,有存货么?共享一个。 |
![]() | 19 evlos 2017-01-24 10:23:02 +08:00 卧槽,附件放表里了?! 66666666 |
20 paranoiagu OP @evlos 是啊。一直这么干的,以前是 oracle 为主,现在开始用 mysql 了。 |
21 julyclyde 2017-01-24 12:29:47 +08:00 |
![]() | 22 spice630 2017-01-24 18:06:09 +08:00 收藏学习~~ |
23 ibegyourpardon 2017-01-24 21:21:38 +08:00 @julyclyde 很多年前有个论坛程序叫 vBulletion ,在国内有不少盗版和魔改版,魔改版里还有多种分支(参照无极版绿色版纯净版最终版终极版等 QQ ),其中有一个分支就是这样的,因为那位魔改的程序员觉得搬迁网站的时候拷贝那么多附件太麻烦了,直接转二进制塞数据库吧…… 当年的我视若珍宝保留着这个版本…… 现在想想蠢死了。 |
![]() | 24 sivacohan PRO @julyclyde 小文件放数据库里这个玩法的确存在。 印象中产生的场景: 1 ,海量小文件吃 inode 2 ,减少额外的网络连接 3 ,便于迁移和备份 但是最近看到的这么玩的少了。有 kv 存储和分布式存储。上面的问题都不是大问题了。 |
![]() | 25 wayslog 2017-01-25 13:17:38 +08:00 冗余不做,十恶不赦。备份不做,日子甭过。 做不好也一样。。。。 |
![]() | 26 sopato 2017-01-25 13:38:07 +08:00 平时不做备份。。。。 |