MySQL系统表故障探究
最近在巡检的时候,发现MySQL错误日志中,报如下错误:
1779986 2015-10-06 00:06:37 7f5215214700 InnoDB: Error: Table "mysql"."innodb_table_stats" not found. 1779987 2015-10-06 00:06:37 7f5215214700 InnoDB: Recalculation of persistent statistics requested for table "xxxx"."xxxxxx" but the required persistent statistics storage is not present or is corrupted. Using transient stats instead.
经过排查,发现是mysql 的几张系统表不见了,到底是那几张呢?
MySQL 5.6的ibdata1表空间包含了5个InnoDB基础表,如下:
mysql> select table_name from information_schema.tables where table_schema='mysql' and engine='InnoDB'; +----------------------+ | table_name | +----------------------+ | innodb_index_stats | | innodb_table_stats | | slave_master_info | | slave_relay_log_info | | slave_worker_info | +----------------------+ 5 rows in set (0.00 sec)
在MySQL 5.6之前,如果关闭MySQL后删除ibdata1,再重新启动MySQL的时候ibdata1会被重新创建, 但从MySQL 5.6开始,这5个表不会被重建,究其缘由是因为这几张表的存储引擎是innodb,而且在MySQL5.5 中并没有这几张表。大致来看看5.6与5.5系统表的区别:
在错误日志中追溯原因,发现是在一次故障迁移中,删除过ibdata1文件,在重启之后,自动创建的ibdata1文件,但这几张innodb系统表并没加载到表空间中。这些错误虽然并不影响业务,但很影响备份,在错误日志中大量出现,也是很烦的。
MySQL 5.5 系统表 +---------------------------+ | columns_priv | | db | | event | | func | | help_category | | help_keyword | | help_relation | | help_topic | | host | | ndb_binlog_index | | plugin | | proc | | procs_priv | | proxies_priv | | servers | | tables_priv | | time_zone | | time_zone_leap_second | | time_zone_name | | time_zone_transition | | time_zone_transition_type | | user | +---------------------------+ 22 rows in set (0.00 sec)
MySQL 5.6 系统表 +---------------------------+ | Tables_in_mysql | +---------------------------+ | columns_priv | | db | | event | | func | | general_log | | help_category | | help_keyword | | help_relation | | help_topic | | innodb_index_stats | | innodb_table_stats | | ndb_binlog_index | | plugin | | proc | | procs_priv | | proxies_priv | | servers | | slave_master_info | | slave_relay_log_info | | slave_worker_info | | slow_log | | tables_priv | | time_zone | | time_zone_leap_second | | time_zone_name | | time_zone_transition | | time_zone_transition_type | | user | +---------------------------+ 28 rows in set (0.00 sec)由上述统计可以看到,在mysql5.6 中,除了增加了上述5张表,还添加了general_log 、slow_log 表,并且将5.5中的host表合到了5.6中的user表中。
在错误日志中追溯原因,发现是在一次故障迁移中,删除过ibdata1文件,在重启之后,自动创建的ibdata1文件,但这几张innodb系统表并没加载到表空间中。这些错误虽然并不影响业务,但很影响备份,在错误日志中大量出现,也是很烦的。
那么对于这样的错误,我们该如何处理?
1、如果是slave备机,停止复制,记录pos等信息(对于不复制mysql库来说,也没有必要做这一步)
mysql>stop slave ;
2、删除上述系统表
drop table mysql.innodb_index_stats;
drop table mysql.innodb_table_stats;
drop table mysql.slave_master_info;
drop table mysql.slave_relay_log_info;
drop table mysql.slave_worker_info ;
drop table mysql.slave_master_info;
drop table mysql.slave_relay_log_info;
drop table mysql.slave_worker_info ;
3、删除相关的.frm与 .ibd 文件
rm -rf innodb_*_stats*
rm -rf slave_*
4、重新创建上述系统表
-
从其他机器上,使用mysqldump将这几张表的表结构备份出来,放到该机器上重新执行,备份脚本如下:
#!/bin/sh TABLELIST="innodb_index_stats" TABLELIST="${TABLELIST} innodb_table_stats" TABLELIST="${TABLELIST} slave_master_info" TABLELIST="${TABLELIST} slave_relay_log_info" TABLELIST="${TABLELIST} slave_worker_info" mysqldump -uroot -p mysql ${TABLELIST} > mysql_innodb_tables.sql
-
将 mysql_innodb_tables.sql拷贝到出现坏表错误的那台数据库机器,并将其导入到系统库mysql库中.
# mysql -uroot -p mysql < mysql_innodb_tables.sql
- 运行FLUSH TABLES(可选)
5、重启数据库
6、启动slave,如果报错,重新change master
7、重新确定错误日志中有无类似报错
注意:不要轻易删除ibdata1文件,在不同的版本、不同的分支,系统表都有可能不太一样,如mysql 5.6 与 MariaDB 10.0的系统表,mysql5.5 与mysql 5.6 的 系统表等等,在做迁移或升级时,很容易忽略掉这些细节,所以在做之前,一定要备份,不要任性而为。
参考文章:http://bugs.mysql.com/bug.php?id=67179
文章名称:MySQL系统表故障探究
文章来源:http://azwzsj.com/article/geeejj.html