Question

MySQL恢复中的几个问题解决方法

Answer 1

一、Can’t connect to MySQL server on ‘localhost’ (10061)
翻译：不能连接到 localhost 上的mysql
分析：这说明“localhost”计算机是存在的，但在这台机器上却没提供MySQL服务。
需要启动这台机器上的MySQL服务,如果机子负载太高没空相应请求也会产生这个错误。
解决:既然没有启动那就去启动这台机子的mysql。如果启动不成功，多数是因为你的my.ini配置的有问题。重新配置其即可。
如果觉得mysql负载异常，可以到mysql/bin 的目录下执行mysqladmin -uroot -p123 processlist来查看mysql当前的进程。
二、Unknown MySQL Server Host ‘localhosadst’ (11001)
翻译：未知的MySQL服务器 localhosadst
分析：服务器 localhosasdst 不存在。或者根本无法连接
解决：仔细检查自己论坛下面的 ./config.inc.php 找到$dbhost重新设置为正确的mysql 服务器地址。
三、Access denied for user: ‘roota@localhost’ (Using password: YES)
翻译：用户 roota 访问 localhost 被拒绝（没有允许通过）
分析：造成这个错误一般数据库用户名和密码相对mysql服务器不正确
解决：仔细检查自己论坛下面的 ./config.inc.php 找到$dbuser、$dbpw核实后重新设置保存即可。
四、Access denied for user: ‘red@localhost’ to database ‘newbbs’
翻译：用户 red 在localhost 服务器上没有权限操作数据库newbbs
分析：这个提示和问题三是不同的。那个是在连接数据库的时候就被阻止了，而这个错误是在对数据库进行操作时引起的。比如在select update等等。这个是因为该用户没有操作数据库相应的权力。比如select 这个操作在mysql.user.Select_priv里记录 Y 可以操作N 不可以操作。
解决：如果是自己的独立主机那么更新mysql.user 的相应用户记录，比如这里要更新的用户为red 。或者直接修改 ./config.inc.php 为其配置一个具有对数据库操作权限的用户
或者通过如下的命令来更新授权grant all privileges on dbname.* to ‘user’@’localhost’ identified by ‘password’
提示：更新了mysql库中的记录一定要重启mysql服务器才能使更新生效
FLUSH PRIVILEGES;
五、No Database Selected
翻译：没有数据库被选择上
分析：产生的原因有两种
config.inc.php 里面$dbname设置的不对。致使数据库根本不存在，所以在 $db->select_db($dbname); 时返回了false
和上面问题四是一样的，数据库用户没有select权限，同样会导致这样的错误。当你发现config.inc.php的设置没有任何问题，但还是提示这个错误，那一定就是这种情况了。
解决：对症下药
打开config.inc.php 找到$dbname核实重新配置并保存
同问题四的解决方法
六、Can’t open file: ‘xxx_forums.MYI’. (errno: 145)
翻译：不能打开xxx_forums.MYI
问题分析：
这种情况是不能打开 cdb_forums.MYI 造成的，引起这种情况可能的原因有：
1、服务器非正常关机，数据库所在空间已满，或一些其它未知的原因，对数据库表造成了损坏。
2、类 unix 操作系统下直接将数据库文件拷贝移动会因为文件的属组问题而产生这个错误。
解决方法：
1、修复数据表
可以使用下面的两种方式修复数据表：（第一种方法仅适合独立主机用户）
1）使用 myisamchk ，MySQL 自带了专门用户数据表检查和修复的工具 —— myisamchk 。更改当前目录到 MySQL/bin 下面，一般情况下只有在这个下面才能运行 myisamchk 命令。常用的修复命令为：myisamchk -r 数据文件目录/数据表名.MYI；
2）通过 phpMyAdmin 修复， phpMyAdmin 带有修复数据表的功能，进入到某一个表中后，点击“操作”，在下方的“表维护”中点击“修复表”即可。
注意：以上两种修复方式在执行前一定要备份数据库。

Answer 2

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。
临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。