InnoDB存储引擎 - 常见问题修复

错误1：InnoDB: Error: page 19 log sequence number 2363194248
InnoDB: is in the future! Current system log sequence number 78250719.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files.

# 解决方法: 在server没有任何备份的情况下，只能强迫innodb自己恢复
vim /etc/my.cnf  # 添加如下内容
[mysqld]
port = 8999 # 建议恢复的时候，不要用3306
innodb_force_recovery = 1 # recovery级别根据情况从1增加至6 
innodb_purge_threads = 0 
保存退出，启动mysql服务。recovery模式的database是只读的。

# 上面配置项innodb_force_recovery 有 0-6 六个值，不同的值有不同的功能。
# 详情见mysql官网： http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
# 据说mysql第三方Percona有更效率的恢复工具。

# mysqlcheck检查数据库表是否损坏
mysqlcheck -uroot -ppasswd database1 -c # 检查database1哪些表损坏
mysqlcheck -uroot -ppasswd database1 nova -c # 检查nova表是否损坏
mysqlcheck -uroot -ppasswd database1 -r  # 修复整个数据库，innodb引擎不支持修复
mysqlcheck -uroot -ppasswd database1 table -r # 修复数据表

# 找出corrupted的数据库表，通过mysqldump备份它们
 mysqldump -uroot -ppasswd database > database.sql  # 备份整个库
 mysqldump -uroot -ppasswd -databases database1 database2 > database.table.sql # 备份多个库
 mysqldump -uroot -ppasswd database table1 table2 > database.table.sql # 备份一个库的某些表
 mysqldump -uroot -ppasswd -all-databases > alldatabase.sql # 备份所有库
 mysqldump -no-data -uroot -ppasswd -databases database1 database2 > alldatabase.sql # 仅仅备份数据库结构 
 mysql -uuser -ppasswd database < backup.sql # 还原数据库
 mysqldump -uroot -ppasswd database | gzip > database.sql.gz # 压缩备份库
 gunzip < database.sql.gz | mysqldump -uroot -ppasswd database # 解压还原库

# 备份完corrupted的表后，删除corrupted的表
 drop table database.table
 vim /etc/my.cnf # 移除下面两个配置项,正常模式重启mysql
 innodb_force_recovery = 1
 innodb_purge_threads = 0 

# 还原刚才corrupted的表
 mysql -uroot -ppass database < database.table.sql
 
# 修改mysql为原来的3306，重启mysql服务
 vim /etc/my.cnf  # 修改为3306
 [mysqld]
  port = 3306
 
# 以上操作都只是备份数据，日志的错误还没解决，还需如下操作
mysqldump 备份所有库
rm /var/lib/mysql/ibdata1 # ibdata1是存放mysql的数据和索引
rm /var/lib/mysql/ib_logfile* # ib_logfileN是redo log事务日志文件
最后还原备份的所有库，ok，就是这样！

galera做mysql高可用的时候，如果出现数据不一致，删除数据比较旧的那个节点的数据
类似这样操作：rm animbus/ cinder/ galera.cache glance/ heat/ keystone/ neutron/ nova/ ib_logfile* ibdata1 -rf,然后重启服务即可。

 

参考链接

http://colderboy.blog.51cto.com/485582/469925

http://blackbird.si/mysql-corrupted-innodb-tables-recovery-step-by-step-guide/

http://www.21andy.com/new/20071102/655.html

错误2: How to safely change MySQL innodb variable 'innodb_log_file_size'?
 vim /etc/my.cnf # 添加内容如下
 innodb_buffer_pool_size=2G
 innodb_log_file_size=100M

# 然后重启mysql，错误如下：
110216 9:48:41 InnoDB: Initializing buffer pool, size = 128.0M110216 9:48:41 InnoDB: Completed initialization of buffer poolInnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytesInnoDB: than specified in the .cnf file 0 33554432 bytes!110216 9:48:41 [ERROR] Plugin 'InnoDB' init function returned error.110216 9:48:41 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

解决方法：          
mysql -uroot -p... -e"SET GLOBAL innodb_fast_shutdown = 0"
service mysql stop
rm -f /var/lib/mysql/ib_logfile[01]
service mysql start

看到网上一些文章，说最好把这个选项也加上
SET GLOBAL innodb_max_dirty_pages_pct = 0; （dirty page听我同事解释说是内存数据）
By default, innodb_max_dirty_pages_pct is 75 (MySQL 5.5+) or 90 (prior to MySQL 5.5). Setting this to zero keeps the number of dirty pages under 1% of the InnoDB Buffer Pool. Performing service mysql stop, does this anyway. In addition, a shutdown will finish up any remaining items in the redo log. 
我在用google搜索，发现下面这个链接，有很多mysql问题的汇总 http://dba.stackexchange.com/search?q=ib_logfile0