Mysql 5.7.20 mysql innodb 系统表损坏带来的问题

早上上班后,mysql服务器遇到点小问题,在排查故障过程查看mysql错误日志过程中发现有几个innodb 表无法打开,使用desc查看有关表的表结构提示表不存在,show tables 可以查到一下五个表,以下是具体的报错信息:

2018-01-12 09:17:41 17235 [Warning] InnoDB: Cannot open table mysql/innodb_index_stats from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

2018-01-12 09:17:41 17235 [Warning] InnoDB: Cannot open table mysql/innodb_table_stats from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

2018-01-12 09:17:41 17235 [Warning] InnoDB: Cannot open table mysql/slave_master_info from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

2018-01-12 09:17:41 17235 [Warning] InnoDB: Cannot open table mysql/slave_relay_log_info from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

2018-01-12 09:17:41 17235 [Warning] InnoDB: Cannot open table mysql/slave_worker_info from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

网上查了下资料,问题的问题产生原因:数据库打开这几张表的默认引擎为MyISAM,但是这几张表在建表时的引擎为INNODB;从而引起mysql报错

msyql在5.6版本引入了以下五个表

innodb_index_stats,

innodb_tables_stats,

slave_master_info,

slave_relay_log_info,

slave_worker_info

定位了问题原因后,那我们就开始着手准备解决以上存在的问题,解决的思路是,删除有问题的表和数据文件,使用安装msyql的官方自带建表脚本,重新创建有问题的5个表。

操作步骤如下

1,登录数据库执行以下操作,sql语句加if 判断,如果表存在,则删除

mysql> use mysql;

mysql> drop table if exists innodb_index_stats;

mysql> drop table if exists innodb_table_stats;

mysql> drop table if exists slave_master_info;

mysql> drop table if exists slave_relay_log_info;

mysql> drop table if exists slave_worker_info;

mysql> show tables; 验证执行结果,以上表是否已删除

2,停止mysql数据库服务,并进入到数据库数据文件所在目录,删除上面5个表所对应的idb文件,linux系统环境,我的msyql的basedir目录是 /usr/local/mysql/

datadir目录是/data/mysql/var/mysql/

[[email protected] ]# systemctl restart stop

[[email protected] root]# cd /data/mysql/var/mysql/

[[email protected] mysql]# ls -l *.ibd

-rw-rw---- 1 mysql mysql 98304 3月   7 2017 innodb_index_stats.ibd

-rw-rw---- 1 mysql mysql 98304 3月   7 2017 innodb_table_stats.ibd

-rw-rw---- 1 mysql mysql 98304 3月   7 2017 slave_master_info.ibd

-rw-rw---- 1 mysql mysql 98304 3月   7 2017 slave_relay_log_info.ibd

-rw-rw---- 1 mysql mysql 98304 3月   7 2017 slave_worker_info.ibd

[[email protected] mysql]#rm -rf *.ibd

3,重启mysql服务,并重建被删除的五个表的表结构,建表脚本在mysql软件的安装目录的share目录下或者mysql的安装包的script目录下

[[email protected] mysql]# cd /usr/local/mysql/share/

[[email protected] share]# ls -l *.sql  //查看所有的建表脚本

-rw-r--r--. 1 root root 932622 9月  13 23:56 fill_help_tables.sql

-rw-r--r--. 1 root root   3999 9月  13 23:48 innodb_memcached_config.sql

-rw-r--r--. 1 root root   1812 11月  7 11:42 install_rewriter.sql

-rw-r--r--. 1 root root   1760 9月  13 23:48 mysql_security_commands.sql

-rw-r--r--. 1 root root 287110 9月  13 23:48 mysql_sys_schema.sql

-rw-r--r--. 1 root root    811 9月  13 23:48 mysql_system_tables_data.sql

-rw-r--r--. 1 root root 154624 9月  13 23:48 mysql_system_tables.sql

-rw-r--r--. 1 root root  10410 9月  13 23:48 mysql_test_data_timezone.sql

-rw-r--r--. 1 root root    834 11月  7 11:42 uninstall_rewriter.sql

[[email protected] share]# systemctl restart mysqld

mysql> USE MYSQL;

mysql> source /usr/local/mysql/share/innodb_memcached_config.sql

mysql> show tables; 删除的5个表已恢复

mysql> DESC innodb_table_stats ;

其余四个表结构的查看过程略,

在查看mysql的错误日志,报错信息没有了

[[email protected] share]# tail /data/mysql/var/mysqld.err

原文地址:http://blog.51cto.com/lvjuntao/2060141

时间: 2024-10-30 20:41:19

Mysql 5.7.20 mysql innodb 系统表损坏带来的问题的相关文章

sql 2008R2系统表损坏

某客户单位,一台运行服务器突然出现故障不能进入系统,里面有运行的用友数据库,出现故障后自己公司DBA以及运维折腾了将近一星期后来能够进入系统了发现数据库已经无法正常使用,且所有之前6月份备份都损坏了,最近的备份也只有4月30号的,询问那边做过什么操作时,客户已经描述不清,无奈只能让客户发库过来看,客户是用友U8数据库运行平台为2008r2. 对数据MDF文件进行损坏发现很多物理页面损坏,先直接重建日志DBCC检测一下看看,在2008R2平台下重建日志之后发现DBCC语句根本无法查询跟运行,直接报

MySQL数据库表损坏后的修复方法

步骤:1.sql语句:check table tabTest; 如果出现的结果说Status是OK,则不用修复,如果有Error2.Linux执行: myisamchk -r -q /var/lib/mysql/db/test.MYI 3.sql语句:repair table tabTest; 4.sql语句:check table tabTest; Status是OK就修复好了 非Linux上:直接 参考:有两种方法,一种方法使用mysql的check table和repair table 的

FAQ系列 | ibdata1系统表空间文件都包含什么内容

InnoDB系统表空间文件ibdata1中存储了以下几部分信息: Data dictionary Double write buffer Insert buffer Rollback segments UNDO space Foreign key constraint system tables 因此,我们在初始化ibdata1时,最好设置大一些,比如至少1GB以上. 此外,从MySQL 5.6版本开始,支持将UNDO Space放在独立的undo表空间里,强烈建议使用. 这样就可以避免因为在高

InnoDB 数据表压缩原理与限制

http://liuxin1982.blog.chinaunix.net/uid-24485075-id-3523032.html 压缩理念 通过提高CPU利用率和节约成本,降低数据库容量及I/O负载,从而使数据吞吐率得到显著提高. 压缩原理 压缩表减少了磁盘上数据库的大小,使得用户不必频繁地操作写入和读取便可以访问数据.对于 InnoDB的工作量以及传统的用户表而言(特别是在某些读取密集型的应用中,内存有足够的空间存储常用数据),数据压缩不仅大大减少了数据库所需的存储空间,而且还减少了 I/O

MySQL InnoDB 共享表空间和独立表空间

共享表空间 某一个数据库的所有的表数据,索引文件全部放在一个文件中,默认这个共享表空间的文件路径在data目录下. 默认的文件名为ibdata1, 初始化为10M. 由于是默认的方式,就暂且理解为Mysql官方推荐的方式.相对而言所有的数据都在一个(或几个)文件中,比较利于管理,而且在操作的时候只需要open这一个(或几个)文件即可,相对来说代价很低.但问题是在数据达到以G为单位来计算的时候优劣逆转.一个过大的文件很不利于管理,而且对于一个如此巨大的文件来说,读写它需要耗费的资源一样巨大.更加令

Innodb中mysql如何快速删除2T的大表

小漫画 来,先来看小漫画陶冶一下情操OK,这里就说了.假设,你有一个表erp,如果你直接进行下面的命令这个时候所有的mysql的相关进程都会停止,直到drop结束,mysql才会恢复执行.出现这个情况的原因就是因为,在drop table的时候,innodb维护了一个全局锁,drop完毕锁就释放了. 这意味着,如果在白天,访问量非常大的时候,如果你在不做任何处理措施的情况下,执行了删大表的命令,整个mysql就挂在那了,在删表期间,QPS会严重下滑,然后产品经理就来找你喝茶了.所以才有了漫画中的

MySQL常用系统表汇总

在这篇文章中: MySQL5.7 默认模式 Information_schema performance_schema mysql sys MYSQL SHOW 命令 致谢 概述 本篇文章虽大部分内容为参考原文作者的相关内容,但对原文对于文章的逻辑与排版上进行了大范围修改,方便阅读与理解.原文链接在底部 MySQL5.7 默认模式 库名 表数量 视图数量 information_schema 61 0 mysql 32 0 performance_schema 87 0 sys 1 100 In

MySQL InnoDb数据表 自动提交总结

官方文档说明: http://dev.mysql.com/doc/refman/5.5/en/commit.html 1.autocommit仅适用于InnoDb数据表; 2.默认是自动提交,可通过语句查询: select @@autocommit; 3.SET autocommit 禁用或启用默认为当前会话自动提交模式(注意:只是当前会话生效); 4.语法:SET autocommit = {0 | 1}  0为当前会话禁用自动提交,1为当前会话启用自动提交 5.可通过启动服务加命令方式进行修

【转】利用optimize、存储过程和系统表对mysql数据库表进行批量碎片清理释放表空间

本文收集于本人的笔记本,由于找不到原文出处.在此省略,如哪位知道可以联系我加上. 核心是利用mysql系统表和“optimize table 表名”命令,对mysql数据表进行空间的释放.由于delete和drop table都不会释放表空间(truncate 命令会释放表空间[将所有的数据都删除]),所以需要利用optimize 命令进行释放. 这个存储过程目的是给一个库的所有表来整理碎片的.一个表随着插入很频繁,或者一直更新不停的,就会积累好多碎片.如果及时整理一下,查询效率会高出好多. D