资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/微信店奖Mysql表损坏问题复盘

微信店奖Mysql表损坏问题复盘

IT那活儿 / 2344人阅读
微信店奖Mysql表损坏问题复盘

点击上方“IT那活儿”，关注后了解更多内容，不管IT什么活儿，干就完了！！！



问题发生时间

目前无法确定，猜想原因为历史某次Mysql升级数据字典导致。


问题发现时间

2022年1月3日9：00

问题解决时间

2022年1月5日10：40至2022年1月6日1：30


问题复盘时间

2022年1月6日10：00


问题发生背景

因需要对微信店奖系统创建用户，但在创建用户时收到Mysql.user表损坏问题报错。

当晚在尝试进行修复时操作出现若干未预期报错，导致总体修复过程较长。故在此对整个修复过程进行复盘，并试图重新梳理问题逻辑。


问题发生负面影响

除无法创建用户外，业务数据库DDL、DML操作不受影响，应用运行正常。






问题解决过程



1. 发现无法创建用户

白天首次创建用户时，收到Mysql.user表损坏问题报错。
图一 
创建用户时收到Mysql.user表损坏问题报错
于是白天对数据库中其他业务操作进行测试，发现本次问题仅影响用户创建，不影响用户登录，表查询/修改/删除等。因此在测试环境对Mysql.user表进行重建，确定重建过程不影响业务时，决定申请停应用对表进行重建。

2. 重建表后仍然报错

当晚为重建Mysql.user表准备了三套方案。第一套为「查询表结构-创建备份表-删除表后导入备份表」，第二套为「mysqldump出单表-删表表后导入dump出的.sql文件」，第三套为「从同Mysql版本的其他库mysqldump出单表-在本库删表表后导入dump出的.sql文件」。
实际操作中，使用过前两种方法后，直接再次创建用户时仍会收到Mysql.user表损坏问题报错（期间尝试重启数据库，同样不影响报错内容）。尝试第三种方法后，获得了新的报错：Mysql.db表损坏。
图二
创建用户时收到Mysql.db表损坏问题报错

3. 尝试修复表

收到表损坏报错后，尝试修复表（使用repair table语句）。
图三 
修复后查看Mysql.user表状态
图四 
修复后查看Mysql.db表状态
但运行创建用户语句仍会收到报错。
图五 
创建用户时仍收到Mysql.db表损坏问题报错

4. 尝试重建Mysql.db表

于是仿照重建Mysql.user表的步骤，尝试重建Mysql.db表。
图六 
重建Mysql.db表后创建用户时仍收到Mysql.db表损坏问题报错

5. 尝试赋权

尝试为查询Mysql.db表赋予权限，但收到了新的报错：Mysql.tables_priv表损坏。使用修复表之后同样失败。
图七 
为查询Mysql.db表赋予权限收到了新的报错：Mysql.tables_priv表损坏

6. 主从同步断开

在尝试修复期间，主从同步断开，核查后原因为从库到主库3306端口不通，开放端口后问题恢复。

7. 尝试升级(mysql_upgrade)

第一次运行mysql_upgrade报错，但可以正常执行上一步的赋权语句。
图八 
第一次运行mysql_upgrade报错，但执行赋权语句成功
第二次加入--force选项，再次运行，可以进行用户创建。
图九 
第二次运行mysql_upgrade（--force）成功，同时创建用户成功

8. 主从同步错误

在主库完成upgrade操作的同时，从库再次报错。
图十 
主从同步报错
尝试模仿主库操作，在从库进行mysql_upgrade，但收到了另一个报错。
图十一 
mysql_upgrade失败报错
尝试停止slave进程之后，继续升级，仍然报错。
图十二 
停止slave之后mysql_upgrade仍然失败报错
查看错误日志后发现，升级错误没有写入到日志中。
图十三 
日志中没有报错信息
尝试在数据库参数中增加skip-grant-tables，重启起库后再次升级，仍然失败。
图十四 
在数据库参数中增加skip-grant-tables，重启起库后再次升级，仍然失败

9. 从库重建Mysql.user表

尝试在从库重建Mysql.user表，表信息来自主库dump结果。
图十五 
在从库重建Mysql.user表
但仍然无法正常运行slave进程。

10. 从库手动跳过该错误

分析后确定，这套主从都是全同步的，按道理升级数据字典，跑一边就好，现在可以直接跳过当前这个错误日志。
stop slave ;
set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
start slave ;
图十六 
期间出现的报错
连续执行上述语句三次之后，跳过所有报错，主从同步恢复正常。
图十七 
主从同步恢复正常
检查业务表同步情况后，结果正常。（数据表大小相同，测试表创建删除正常同步）
图十八 
业务测试主从同步恢复正常

11. 系统表主从同步错误

目前只有业务数据库同步正常，系统表主从同步仍然有问题。
图十九 
在主库建用户，会导致从库slave挂掉

12. Mysql默认环境变量问题

次日核查后，最终确定为Mysql默认环境变量问题。使用which mysql得到的并不是当前mysql实例的位置。
图二十 
使用which mysql得到的并不是当前mysql实例的位置
于是到Mysql软件目录运行mysql_upgrade成功，创建测试用户成功。
图二十一 
到Mysql软件目录运行mysql_upgrade成功，创建测试用户成功






事后分析



1. Mysql.user表引擎问题

5.7.x版本下，Mysql的user表默认使用MYISAM引擎，该引擎存在这种表容易损坏的故障。以后升级可以考虑选择升级8.0。

2. Mysql主从同步设置

Mysql主从同步可以考虑只同步业务数据库，即排除系统表。

3. Mysql表损坏问题修理思路

  • 首先，尝试使用repair table xxx进行修复。
  • 如果第一步失败，尝试导出重建表。
  • 如果第二步失败，尝试手动运行mysql_upgrade进行升级。
    如果第三步失败，尝试重新初始化（仅针对从库）。



本文作者：叶顺龙

本文来源：IT那活儿（上海新炬王翦团队）

云服务器 GPU云服务器 表损坏 mysql数据表损坏 顺序表求集合问题 复盘

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129635.html

相关文章

  • MySQL 复制 - 性能与扩展性的基石 3：常见问题及解决方案

    摘要：问题原因非正常关机导致没有把数据及时的写入硬盘。丢失的临时表临时表和基于语句的复制方式不相容。如果备库崩溃或者正常关闭，任何复制线程拥有的临时表都会丢失。临时表的特性只对创建临时表的连接可见。 主备复制过程中有很大可能会出现各种问题，接下来我们就讨论一些比较普遍的问题，以及当遇到这些问题时，如何解决或者预防问题发生。 1 数据损坏或丢失 问题描述：服务器崩溃、断电、磁盘损坏、内存或网络...

    canopus4u 评论0 收藏0

  • MySQL 复制 - 性能与扩展性的基石 3：常见问题及解决方案

    摘要：问题原因非正常关机导致没有把数据及时的写入硬盘。丢失的临时表临时表和基于语句的复制方式不相容。如果备库崩溃或者正常关闭，任何复制线程拥有的临时表都会丢失。临时表的特性只对创建临时表的连接可见。 主备复制过程中有很大可能会出现各种问题，接下来我们就讨论一些比较普遍的问题，以及当遇到这些问题时，如何解决或者预防问题发生。 1 数据损坏或丢失 问题描述：服务器崩溃、断电、磁盘损坏、内存或网络...

    haobowd 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<