问题:
从“chmod -R 777 /”恢复 mysql(或最坏情况:迁移)的最佳方法是什么,并且数据库完好无损?
系统:
Ubuntu 12.04 LTS
MySQL 5.5.24
64 位 Amazon EC2 云服务器。
背景: 尝试恢复(或至少恢复数据)已完成此操作的系统:
chmod -R 777 /
没有必要担心原因。这是因为经理权限太大但经验太少,喜欢在深水中游泳。这纯粹是他的意外,他当时并不是故意按回车键的。
我已经恢复了系统的大部分功能,但仍然无法让 mysql 再次运行。我已经尝试过以下页面:
- 如何在“sudo chmod / 777”之后修复/恢复 ubuntu 10.04
- chmod -R 777 / 在 ubuntu 上 - 存在许多问题
- chmod / 775 -R 现在我们的 mysql 数据库已关闭...!
- 为什么“chmod -R 777 /”具有破坏性?
已经这样做了:
sudo chmod 644 my.cnf
chown mysql:mysql my.cnf
此时尝试启动 mysql:
sudo service mysql start
在系统日志中生成此输出:
Apr 12 20:51:42 ip-10-10-25-143 kernel: [18632541.774742] type=1400 audit(1365799902.306:41): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18210 comm="apparmor_parser"
Apr 12 20:51:42 ip-10-10-25-143 kernel: [18632541.964496] init: mysql main process (18214) terminated with status 1
Apr 12 20:51:42 ip-10-10-25-143 kernel: [18632541.964542] init: mysql main process ended, respawning
Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632542.959796] init: mysql post-start process (18215) terminated with status 1
Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.002041] type=1400 audit(1365799903.534:42): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18238 comm="apparmor_parser"
Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.098490] init: mysql main process (18242) terminated with status 1
Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.098536] init: mysql main process ended, respawning
Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.140706] init: mysql post-start process (18244) terminated with status 1
Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.158681] type=1400 audit(1365799903.690:43): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18258 comm="apparmor_parser"
Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.285087] init: mysql main process (18262) terminated with status 1
Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.285133] init: mysql respawning too fast, stopped
我从中读到的是 mysql 以状态 1 终止,并且它循环几次尝试启动,并且在尝试太多次后停止执行。我研究了状态 1,但没有找到似乎适用的解决方案。
答案1
- 创建具有相同操作系统版本和 MySQL 版本的新 VM 实例。
- 在新 VM 上启动 MySQL - 它应该创建没有数据库但具有正确权限的 MySQL 数据目录 - 在
/var/lib/mysql
。 - 在新 VM 上停止 MySQL。
/var/lib/mysql
在新的 VM 上复制到/var/lib/mysql.empty
。/var/lib/mysql
从旧虚拟机复制到/var/lib/mysql
新虚拟机。/var/lib/mysql
根据 的权限手动设置中的所有文件和目录的权限/var/lib/mysql.empty
。- 现在向所选的神灵进行简短的祈祷不会有什么坏处。
- 在新 VM 上启动 MySQL。
- 我建议使用转储所有数据
mysqldump -A
,重新创建一个新的、空的 mysql 数据目录并重新导入这些数据以防万一。 - 当您确信它能正常工作并且所有数据都完好无损时,请关闭旧 VM 并将其磁盘映像存档到某处。设置新服务器比尝试从中恢复工作要少得多,也安全得多。
答案2
重新安装系统并从备份中恢复。