如何修复MySQL数据库

48次阅读

共计 3729 个字符，预计需要花费 10 分钟才能阅读完成。

这篇文章主要介绍如何修复 MySQL 数据库，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

我整理了 7 条修复 MySQL 的方法，当简单的重启对数据库不起作用，或者有表崩溃时。

简单的 MySQL 重启：

/usr/local//bin/mysqladmin -uUSERNAME -pPASSWORD shutdown
/usr/local/mysql/bin/mysqld_safe

1、MyISAM 表崩溃

MySQL 数据库允许不同的表使用不同的存储引擎。它用来存储与检索数据。较流行的存储引擎是 MyISAM 与 InnoDB。

MyISAM 表最终“将”崩溃。这是个不争的事实。

幸运的是，在多数情况下，MyISAM 表崩溃很容易修复。

修复单一表，连接你的数据库执行：

repair TABLENAME

修复所有的表，执行：

/usr/local/mysql/bin/mysqlcheck –all-databases -uUSERNAME -pPASSWORD -r

多数情况，只有当你浏览日志文件时，才知道 MyISAM 表崩溃了。
我强烈建议在你的 /etc/my.cnf 配置文件中添加此行。一旦表崩溃它将进行自动修复。

[mysqld]
myisam-recover=backup,force

如果这个也不管用，还有其他的方法可以试试。

2、多实例 MySQL

当你重启 MySQL 后，进程马上死掉，这很常见。
查看日志文件，它会告诉你，另一个 MySQL 实例可能正在运行。

停止所有 MySQL 实例：

/usr/local/mysql/bin/mysqladmin -uUSERNAME -pPASSWORD shutdown
killall mysql
killall mysqld

现在重启数据库，将只有一个实例在运行。

3、改变 InnoDB 日志设置
一旦 MySQL 数据库有在运行 InnoDB 引擎，你就一定不能修改 /etc/my.cnf 文件中如下几行：

datadir = /usr/local/mysql/data
innodb_data_home_dir = /usr/local/mysql/data
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /usr/local/mysql/data
innodb_log_files_in_group = 2
innodb_log_file_size = 5242880

InnoDB 日志文件大小一旦确定就不能修改。如果改变了，数据库将不能启动。

4、MySQL host 表丢失

有见过几次这样的情况。可能是一些异想不到的 MyISAM bug。

轻松将其修复如下：

/usr/local/bin/mysql_install_db

5、不正常的 MyISAM 自动增长 (auto_increment)

如果 MyISAM 表自增计数变得紊乱，你就不能再插入新的纪录。
通常你可以告诉自增计数器它现在工作不正常，通过将最后一条纪录的自增字段设为 -1。

解决问题 - 找到最后一条自增记录的有效值 (执行如下命令)

SELECT max(id) from tablename

然后更新此表的自增计数器，如下：

ALTER TABLE tablename AUTO_INCREMENT = id+1

6、太多连接数

数据库变得相当繁忙，因为连接数比它能处理的多。而且现在你都不能连接上你的数据库。
首先，停止数据库：

/usr/local/mysql/bin/mysqladmin -uUSERNAME -pPASSWORD shutdown

如果上条命令不管用，可以试试 killall mysql 和 killall mysqld
当数据库停止后，编辑 /etc/my.cnf 文件，增加连接数。不要痴狂的增加这个数字，否则你会把你的整台机器搞崩。

在一台专用数据库机器上，我们通常用：

max_connections = 200
wait_timeout = 100

试着重启数据库看看是否有帮助。
如果你被查询弄的措手不及，需要连接数据库进行表修改操作，那么在 /etc/my.cnf 文件中设置一个不同的端口号，开启数据库，进行修改操作。然后将端口修改回来 (master-port = 3306) 再重启。

7、InnoDB 表崩溃

InnoDB 表是我最钟爱的。事物缓存，可靠, 不像 MyISAM，InnoDB 支持对同一表的并发写。

InnoDB 的内部恢复机制也相当不错。如果数据库崩溃，InnoDB 将尝试进行修复，通过从最后一个时间戳开始运行日志文件。大多数情况都会成功，整个过程是透明的。

不过，如果 InnoDB 自行修复失败，那么“整个”数据库将不能启动。MySQL 将会发出一个错误信息并退出，你的整个库将处于离线状态。你可以不断尝试重启数据库，但是如果修复进程失败，数据库将拒绝启动。

这就是为什么需要运行 master/master 当使用 InnoDB 时 mdash; mdash; 当一个 master 宕掉时，还有一台冗余 master 做后备。

在继续操作前，先浏览下 MySQL 的日志文件，确定数据库不是因为 InnoDB 表的崩溃而崩溃。

有一种方法是更新 InnoDB 的日志文件计数器以跳过引起崩溃的查询，但是经验告诉我们这不是个好方法。这种情况下，将造成数据的不一致性而且会经常使主从复制中断。

一旦因 InnoDB 崩溃造成数据库无法启动，你就应该按如下五个步骤处理问题：

第一：添加此行到 /etc/my.cnf 文件中：

[mysqld]
innodb_force_recovery = 4

第二：重启 MySQL。你的数据库现在将启动，但是在 innodb_force_recovery 参数作用下，所有的插入与更新操作将被忽略。

第三：导出所有的表 (Dump all tables)

第四：关闭数据库，删除所有的数据文件。运行 mysql_install_db 创建默认 MySQL 表。

第五：从 /etc/my.cnf 文件中去掉 innodb_force_recovery 参数，重启数据库。(库现在应该能正常启动)

第六：从备份文件中恢复所有数据。

续：
最近遇到了个让人棘手的任务 mdash; mdash; 修复一个失败的 InnoDB 数据库。这个数据库因崩溃而无法启动。

第一步将 InnoDB 在 force-recovery 模式下开启，此时 InnoDB 虽开启了但是将忽略所有更新 (UPDATEs) 与插入 (INSERTs) 操作。

在 /etc/my.cnf 文件中添加此行：

innodb_force_recovery = 2

现在重启数据库：

/usr/local/bin/mysqld_safe

(注意：如果 MySQL 没有启动，继续增加 innodb_force_recovery 的数值直到将参数值设为 8( innodb_force_recovery =)

将所有数据保存到临时文件 alldb.sql(下个命令需要花一定时间)：

mysqldump –force –compress –triggers –routines –create-options -uUSERNAME -pPASSWORD –all-databases /usr/alldb.sql

再次关闭数据库：

mysqladmin -uUSERNAME -pPASSWORD shutdown

删除数据库目录。(注意：我的数据目录在 /usr/local/var 下。你的设置有可能不同，确保删除的是正确的文件夹。)

rm -fdr /usr/local/var

重建数据库文件夹，安装 MySQL 基础表

mkdir /usr/local/var
chown -R mysql:mysql /usr/local/var
/usr/local/bin/mysql_install_db
chown -R mysql:mysql /usr/local/var

从 /etc/my.cnf 文件中删除 innodb_force_recovery，重启数据库：

/usr/local/bin/mysqld_safe

导入所有备份文件 (下一命令需要花一段时间)：

mysql -uroot –compress /usr/alldb.sql

最后，刷新 MySQL 的权限 (因为我们也更新了 MySQL 的表)

/usr/local/bin/mysqladmin -uroot flush-privileges

注意：为了得到最好的结果，添加 port=8819(或任何其他随机端口)到 /etc/my.cnf 文件中在重启 MySQL 之前，然后将 –port=8819 添加到 mysqldump 命令中。这种方法避免了 MySQL 数据库过于系繁忙当修复进程正在进行时。