innodb异常处理方案-mysql (innodb与myisam的区别)

教程大全 2025-07-12 06:43:25 浏览次

一套测试用的mysql库，之前用的centos6默认源里的mysql 5.1.71的版本。后来想试用下Percona server 5.7，由于这套库里没有什么重要数据。所以操作前也未进行备份，配置好源后，直接就进行了安装。数据文件也存放在默认位置，安装完成后，直接启动mysql，发现启动失败，发现无法启动正常启动。

为避免再从其他地方导入这个数据的麻烦，先对当前库的数据库文件做了个备份（/var/lib/mysql/位置）。接下来将Percona server 5.7包进行了卸载，重新安装原先老的5.1.71的包，启动mysql服务，提示Unknown/unsupported table type: innodb，无法正常启动。

11050912:04:27InnoDB:Initializingbufferpool,size=384.0M11050912:04:27InnoDB:CompletedinitializationofbufferpoolInnoDB:Error:file./ib_logfile0isofdifferentsize05242880bytesInnoDB:thanspecifiedthe.cnffile0157286400bytes!11050912:04:27[ERROR]Plugininitreturnederror.11050912:04:27[ERROR]PluginregistrationasaSTORAGEENGINEfailed.11050912:04:27[ERROR]Unknown/unsupportedtable:innodb11050912:04:27[ERROR]Aborting11050912:04:27[Note]/usr/sbin/mysqld:Shutdowncomplete

/var/lib/mysql目录内容的结构如下：

-rw-rw----1mysqlmysql104857602月2618:10ibdata1-rw-rw----1mysqlmysql52428802月2618:10ib_logfile0-rw-rw----1mysqlmysql52428802月2617:20ib_logfile1drwx------2mysqlmysql40962月2617:20mysqldrwx------2mysqlmysql40962月2617:24wiki

wiki目录是测试数据的库，ibdata1文件为数据文件，ib开头的两个文件为日志文件，mysql 目录下为系统库相关的东西。再次使用初始化的数据，并将wiki目录和ibdata1文件覆盖到/var/lib/mysql 目录下，可以正常启动，也可以正常登录。

不过在通过mysqldump备份时，又提示unknow table engine “Innodb” 。登录后，查看当前所有的引擎类型，发现其中果然不存在innodb类型：

通过alter命令修改其中一个表的类型为MyISAM ，发现仍然报错。

通过 find 查找发现/usr/lib64/mysql/plugin/目录下有ha_innodb_plugin.so文件。印象中mysql5以后的版本支持在线插件安装。通过下面查看确认，果然支持：

使用如下命令加载时，发现不成功：

installplugininnodbsoname;

在/etc/my.cnf中增加如下配置：

plugin-load=innodb=ha_innodb_plugin.soplugin_dir=/usr/lib64/mysql/plugin/default-storage-engine=InnoDB

发现仍启动失败。查看mysql-error.log发现有如下内容：

InnoDB:DatabasepagecorruptionondiskorafailedInnoDB:fileofpage7.InnoDB:Youmayhavetorecoverfromabackup.InnoDB:ItisalsopossiblethatyourOperatingInnoDB:systemhascorrupteditsownfilecacheInnoDB:andrebootingyourcomputerremovestheInnoDB:error.InnoDB:IfthecorruptpageisanindexpageInnoDB:youcanalsotrytofixthecorruptionInnoDB:bydumping,dropping,andreimportingInnoDB:thecorrupttable.YoucanuseCHECKInnoDB:TABLEtoscanyourtablecorruption.InnoDB:Seealso打开forcing-innodb-recovery官方页面，发现可以通过指定innodb_force_recovery参数，进行强制启动和恢复。在/etc/my.cnf中增加如下内容：

innodb_force_recovery=6
重新启动成功了。通过mysqldump备份也没有问题，将备份数据导入其他主机发现也正常可以测试。

这下就好搞了，将mysql彻底删除，重新安装Percona server 5.7，安装完后，建库，还原数据，程序重新连接，一切OK。

由于mysql innodb数据文件的特性，可以在出现问题，无法正常启动时，先将./ib_logfile0 和 ./ib_logfile1 两个日志文件先移走，再启动，如果还不成功，可以用innodb_force_recovery参数进行强制恢复。除此之外，日志也很重启，有问题先看日志。



  ERROR 1289 The 'InnoDB' feature is disabled; you need MySQL built with 'InnoDB' to have IT working
 
 
  关闭mysql数据库 在mysql的安装目录中找到文件找到skip-innodb，在前面加上#号保存，重启mysql服务
 
 
  请问mysql 中文乱码怎么解决的啊
 
 
  首先，你的数据库编码不要使用默认的ISO-8859-1形式，因为它不支持中文；你可以更改mysql安装目录下的在有中括号，如：[mysqld]，[mysql]等那行后面都加上“default-character-set=gbk”。
  
  
  如果用UTF-8的话则加“default-character-set=UTF-8”，其他类推。
  
  
  然后你的页面使用同一的编码方式就可以了。
  
  
  其他我不知道，如果你使用的是java语言的话，可以使用：getBytes（）方法来更改编码方式。
  
  
  如：String str = 好好学习，天天向上;String str2 = new String((GBK),ISO-8859-1);希望我的答案对你有所帮助。
  
  
 
 
  如何安全地关闭MySQL实例
 
 
  关闭过程：1、发起shutdown，发出SIGTERM信号2、有必要的话，新建一个关闭线程(shutdown thread)如果是客户端发起的关闭，则会新建一个专用的关闭线程如果是直接收到 SIGTERM 信号进行关闭的话，专门负责信号处理的线程就会负责关闭工作，或者新建一个独立的线程负责这个事当无法创建独立的关闭线程时（例如内存不足），MySQL Server会发出类似下面的告警信息：Error: Can’t create thread to kill server3、MySQL Server不再响应新的连接请求关闭TCP/IP网络监听，关闭Unix Socket等渠道4、逐渐关闭当前的连接、事务空闲连接，将立刻被终止；当前还有事务、SQL活动的连接，会将其标识为 killed，并定期检查其状态，以便下次检查时将其关闭；（参考 KILL 语法）当前有活跃事务的，该事物会被回滚，如果该事务中还修改了非事务表，则已经修改的数据无法回滚，可能只会完成部分变更；如果是Master/Slave复制场景里的Master，则对复制线程的处理过程和普通线程也是一样的；如果是Master/Slave复制场景里的Slave，则会依次关闭IO、SQL线程，如果这2个线程当前是活跃的，则也会加上 killed 标识，然后再关闭；Slave服务器上，SQL线程是允许直接停止当前的SQL操作的（为了避免复制问题），然后再关闭该线程；在MySQl 5.0.80及以前的版本里，如果SQL线程当时正好执行一个事务到中间，该事务会回滚；从5.0.81开始，则会等待所有的操作结束，除非用户发起KILL操作。
  
  
  当Slave的SQL线程对非事务表执行操作时被强制 KILL了，可能会导致Master、Slave数据不一致；5、MySQL Server进程关闭所有线程，关闭所有存储引擎；刷新所有表cache，关闭所有打开的表；每个存储引擎各自负责相关的关闭操作，例如MyISAM会刷新所有等待写入的操作；InnoDB会将buffer pool刷新到磁盘中（从MySQL 5.0.5开始，如果innodb_fast_shutdown不设置为 2 的话），把当前的LSN记录到表空间中，然后关闭所有的内部线程。
  
  
  6、MySQL Server进程退出