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