MySQL myisam引擎表crashed 修复：MySQL table is marked as crashed and last (automatic?) repair failed

某系统是一个非常老的MySQL从数据库，某天收到主从复制异常的报警，发现从节点的slave_sql_running线程断开，异常日志显示MySQL *** table is marked as crashed and last (automatic?) repair failed

错误日志中显示crashed 的表为myisam引擎表，数据库引擎应该是z自动尝试过修复但是失败，这里需要执行人工修复。
该异常发生在从库，当SQL线程回访relay log的时候，往损坏的表中写入数据的时候会失败，从而导致主从复制SQL线程断开的异常

myisam表的文件异常异常修复方式有两种：
1，通过myisamchk命令修复:myisamchk -r -v table_name
2，通过sql语句修复:repair table ***

鉴于前一种方式需要停止MySQL服务，后一种方式无须停止MySQL，不影响实例中的其他表，因此本次故障使用repair table语句的方式来修复；
由于损坏的表是一个较大的表，数据量有3亿+，物理数据文件大小超过80GB，考虑到在线修复可能会导致服务器IO资源消耗过度，因此采用如下“离线”的方式修复
1，将损坏的标文件copy出来到测试库
2，停止测试库实例，替换测试库中同名的表
3，启动测试库，尝试查询该表，依旧提示***table is marked as crashed,无法读写
4，开始执行repair table *** ，经过数小时的修复，期间观察发现，repair执行时，会把整个表的数据导出到一个相当小大的新的物理文件中,也即table_name.TMD，因此这里需要考虑磁盘空间保持充足
5，经过超大几十分钟的修复，提示repair table *** 执行完成
 
 这里不得不说，尝试修复完成后，生成的中间table_name.TMD文件并没有消失，但是表的MYD和MYI文件显示最后修改时间为修复完成的时间，当时也挺疑惑的，这个TMD文件是否还有用？事实证明这个文件是不需要了的。
 后续有尝试通过repair一些正常的表，修复过程中也会生成一个TMD文件，但是修复完成后TMD文件时自动消失。

6，测试该表可以读写，也即select和insert
7，备份修复后生成的myisam表文件（删除上一步中写入的测试数据）
8，停止MySQL服务器，备份服务器上损坏的标文件MYD,MYI文件，将测试环境中的物理文件替换服务器上的文件
9，启动服务器，通过select的方式测试表可以正常读取，因为是从实例，无法直接验证写操作
10，作为从节点，由于重启了MySQL服务，此时主从复制的SQL线程恢复正常，表示该表可以实现写操作

以上修复crashed的myisam表并恢复了主从复制

来源链接：https://www.cnblogs.com/wy123/p/18991133