MySQL 主从同步失败，数据表修复

问题描述：

接到报警称一台 MySQL 从库同步失败。登录服务器查看错误日志信息如下：

Last_Error: Error 'Incorrect key file for table './bfcc/std_user_history.MYI'; 

            try to repair it' on query. Default database: 'bfcc'. 
            
            Query: 'INSERT INTO std_user_history SET vid='685689',vtype='1',utime=1477183694,uid='135601920104863213',num=1,point=0,source='qiyi',tid='1630514',category='9',platform=3'

# 这台服务器只负责同步数据，不对外提供服务。提示建议尝试修复该表。

解决方法：

shell > mysql -uroot -p

mysql> use bfcc;
mysql> check table std_user_history;
+-----------------------------+-------+----------+-----------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------------------+-------+----------+-----------------------------------------------------------+
| bfcc.std_user_history | check | warning | Table is marked as crashed |
| bfcc.std_user_history | check | warning | 21 clients are using or haven't closed the table properly |
| bfcc.std_user_history | check | warning | Size of datafile is: 243026508 Should be: 243026460 |
| bfcc.std_user_history | check | error | Found 5064119 keys of 5064118 |
| bfcc.std_user_history | check | error | Corrupt |
+-----------------------------+-------+----------+-----------------------------------------------------------+
5 rows in set (0.65 sec)

# 看到该表被打上了一些标记，需要修复。

mysql> repair table std_album;

+-----------------------------+--------+----------+------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------------------------+--------+----------+------------------------------------------------+
| bfcc.std_user_history | repair | warning | Number of rows changed from 5064118 to 5064119 |
| bfcc.std_user_history | repair | status | OK |
+-----------------------------+--------+----------+------------------------------------------------+
2 rows in set (58.03 sec)

# 提示修复成功。

mysql > stop slave;

mysql > start slave;

mysql > show slave statusG

# 发现，主从同步恢复正常，只是延迟很大，需要慢慢同步，等待即可。
# 至于产生原因，有可能是频繁操作该表、服务器异常关机等原因造成的。
# 之前有一张主库的表，也出现过这样的情况，我觉得应该是操作频繁导致的。
# 这次的这张表，我感觉是服务器问题。这台服务器不知为何 IO 等待时常 10% 左右，上面跑了一个安卓虚拟机，一个从库。
# 这台服务器我已经不对外提供服务了。iotop 显示占用 IO 资源的进程却是 jdb2 这个东西，也查过一些资料，但目前还没搞定。