问题现象:
开发人员18:00发现从库环境从早上9:00后,从库的数据与主库中的不一致。
是打开从库,检查环境,发现slave_thread线程挂了,检查时发现由于对一张39GB的大表添加字段没成功,并不当回事,于是start slave直接拉起线程,并用show slave status\G检查状态,发现正常,也就没太留意。
直到第二天上班时,发现主从数据依然未同步,所以感觉问题不像表现那么简单,于是打开日志查看,发现日志如下内容:
2016-05-23 23:48:53 80681 [ERROR] Slave SQL: Error 'Incorrect key file for table 'portal_app_action_data'; try to repair it' on query. Default datab
ase: 'portal'. Query: 'alter table portal_app_xxxx_xxx add devno varchar(64) NOT NULL DEFAULT '' COMMENT '设备机编',add serialno varchar(64) NOTNULL DEFAULT '' COMMENT '绑定流程流水号',add devinfo varchar(128) NOT NULL DEFAULT '' COMMENT '设备附加信息'', Error_code: 1034
2016-05-23 23:48:53 80681 [Warning] Slave: Incorrect key file for table 'portal_app_action_data'; try to repair it Error_code: 1034
2016-05-23 23:48:53 80681 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START
". We stopped at log 'mysql-bin.000287' position 269730951;
查找解决方法:
在网上查找了一下,发现大多的解决办法都是repair,然后再进行myisam进行检查及恢复;
但是发现这个方法只适用于存储引擎为MyISAM的表,于是继续猜测着查找方法。
使用repair table时,直接报Innodb表不支持repair方法。
猜测解决方法:
由于是对39GB大表进行alter操作,猜想一定会耗用不用临时表,于是检查从库的临时空间为/tmp,仅为总内存的一半,16GB,所以导致了临时表空间不够用,再alter过程中失败了,所以导致修改表结构失败,最终导致主从复制失败。
此次的解决方法:
(1) 增加/tmp目录空间;
(2) 修改mysql数据库的tmp目录,把tmp对应的目录迁移到空间更大的地方,然后重启动数据库。
此次的解决方法选择(2)。