欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

Linux平台MySQL 5 InnoDB系统错误代码0

程序员文章站 2022-05-19 18:32:59
...

6 (SRV_FORCE_NO_LOG_REDO) 不要在恢复连接中做日志前滚。 数据库不能另外地带着这些选项中被允许的选项来使用。作为一个

mysql5.1.37在复制环境中出错了,错误如下:出错的是一台slave数据库,这台slave是用来做日常备份的。

Version: '5.1.37max-debug' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution
InnoDB: Error: tried to read 524288 bytes at offset 0 212992.
InnoDB: Was only able to read 69632.
100903 0:10:18 InnoDB: Operating system error number 0 in a file operation.
InnoDB: Error number 0 means 'Success'.
InnoDB: Some operating system error numbers are described at
InnoDB:
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
100903 00:10:19 mysqld_safe Number of processes running now: 0
100903 00:10:19 mysqld_safe mysqld restarted
100903 0:10:20 [Note] Plugin 'FEDERATED' is disabled.
100903 0:10:20 [Note] Plugin 'ndbcluster' is disabled.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
100903 0:10:21 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Error: tried to read 557056 bytes at offset 0 212992.
InnoDB: Was only able to read 69632.
100903 0:10:37 InnoDB: Operating system error number 0 in a file operation.
InnoDB: Error number 0 means 'Success'.
InnoDB: Some operating system error numbers are described at
InnoDB:
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
100903 00:10:41 mysqld_safe mysqld from pid file /dbdata/mysql/mysql.pid ended


这是在晚上发生的,显示数据库在00:10分的时候关闭了,上面给的错误代码0没有任何解释。

仔细回想,每天数据库的全备也是在00:10分的时候,而上面提示的顺序是,首先是InnoDB读取失败,但是操作系统返回0值,不能继续读文件。

然后自动重启,重启过后校验日志,从.idb文件读取表空间信息还原数据恢复现场,但是又出现同样的读取错误,但是操作系统却正常的完成了一次读取,就是读取不到那个位置的数据。

数据库那么大,市场部的人又要立马使用,幸好不是线上直接提供服务的,我可以用其他节点备份,先做下面的操作


#innodb_force_recovery = 4
#skip-slave-start

innodb_force_recovery=4然后启动服务器,这下问题又来了,有一条insert语句过不去,不停的进行重启,当然了这个级别是不允许更新的,那么我只能关闭mysql,然复制也停下来,然后启动mysql,进行check,check也会跳过不可用的数据,check完了,我知道可以用了,注释掉这两行,然后重启,慢慢的等同步完。我知道我丢数据了,但是不知道具体丢了多少。

为了解决问题,采用的方法并不好,其实后来一想,如果要马上起来是可以的,级别改为3就可以了,用不着停掉复制,原因出在恢复的时候无法恢复,无法恢复现场,而回复现场是为了重做或者回滚没有做完的事情。所以并不是log buffer越大越好的,越大恢复的时间就越长。运行速度确实快了不少,但是如果出问题后恢复随之延长。


下面是MySQL手册给出的InnoDB崩溃恢复处理方案,这是没有备份的情况下,如果有其他节点的话,用不着如此做,即使按他的方法做,数据也丢失了,从其他节点恢复过来比较好。

如果数据库页被破坏,你可能想要用SELECT INTO OUTFILE从从数据库转储你的表,通常以这种方法获取的大多数数据是完好的。即使这样,损坏可能导致SELECT * FROM tbl_name或者InnoDB后台操作崩溃或断言,或者甚至使得InnoDB前滚恢复崩溃。 尽管如此,你可以用它来强制InnoDB存储引擎启动同时阻止后台操作运行,以便你能转储你的表。例如:你可以在重启服务器之前,在选项文件的[mysqld]节添加如下的行:
[mysqld]innodb_force_recovery = 4innodb_force_recovery被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4的选项值来转储你的表,,那么你是比较安全的,只有一些在损坏的单独页面上的数据会丢失。一个为6的值更夸张,因为数据库页被留在一个陈旧的状态,这个状态反过来可以引发对B树和其它数据库结构的更多破坏。
1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页,也让服务器运行着;试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页,这样有助于转储表。
2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行,如果崩溃可能在净化操作过程中发生,这将阻止它。
3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并操作。如果你可能会导致一个崩溃。最好不要做这些操作,不要计算表统计表。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志:InnoDB把未完成的事务视为已提交的。
6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施,当innodb_force_recovery被设置为大于0的值时,InnoDB阻止用户执行INSERT, UPDATE或DELETE操作.
即使强制恢复被使用,你也可以DROP或CREATE表。如果你知道一个给定的表正在导致回滚崩溃,你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE导致的失控回滚。你可以杀掉mysqld进程,然后设置innodb_force_recovery为3,使得数据库被挂起而不需要回滚,然后舍弃导致失控回滚的表。

Linux平台MySQL 5 InnoDB系统错误代码0