博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
MySQL 主从同步失败,数据表修复
阅读量:6535 次
发布时间:2019-06-24

本文共 2209 字,大约阅读时间需要 7 分钟。

问题描述:

接到报警称一台 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 -pmysql> 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 status\G

# 发现,主从同步恢复正常,只是延迟很大,需要慢慢同步,等待即可。

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

转载于:https://www.cnblogs.com/wangxiaoqiangs/p/5992823.html

你可能感兴趣的文章
linux下的 python开发环境
查看>>
edx 汉化 lms 主讲教师->分析
查看>>
Windows8手机有截图功能?
查看>>
从ORACLE转战虚拟化 与VMware展开肉搏战来看
查看>>
新建文章 1
查看>>
CISCO无线AP胖瘦升级
查看>>
TensorFlow教程03:针对机器学习初学者的MNIST实验——回归的实现、训练和模型评估...
查看>>
ruby安装mysql2,pg模块
查看>>
java 同一个类中 多个synchronized 方法会造成死锁
查看>>
遍历map集合的三种方式
查看>>
20181124ACL的高级特性mask
查看>>
我的友情链接
查看>>
C语言变长数组之剖析
查看>>
CSS3窗帘式4格焦点图代码
查看>>
接口测试实践
查看>>
看《代码大全》后,变量命名规则心得总结
查看>>
linux关闭ssh连接
查看>>
PowerShell Studio 创建可视化工具- 扫描软件1.0
查看>>
fopen 模拟 post 提交
查看>>
Linux sed命令实例详解
查看>>