但是RESET SLAVE有个问题，它虽然删除了上述文件，但内存中的change master信息并没有删除，此时，可直接执行start slave，但因为删除了master.info和relay-log.info，它会从头开始接受主的binlog并应用。(注意：这里所说的从头是说：reset的时候，正在接受的主的binlog,从新接受这个binlog).如果SQL thread 正在复制临时表的过程中，执行了stop slave ，并且执行了reset slave，这些被复制的临时表将被删除。
题外话：reset master 做了什么？
1. reset master 将删除日志索引文件中记录的所有binlog文件，创建一个新的日志文件 起始值从000001 开始，
2. reset master 不能用于有任何slave 正在运行的主从关系的主库。因为在slave 运行时刻 reset master 命令不被支持，reset master 将master 的binlog从000001 开始记录,slave 记录的master log 则是reset master 时主库的最新的binlog,从库会报错无法找的指定的binlog文件。
继续解决问题：
主从状态正常后，查看告警日志，发现报错
告警日志报错：表crashed，需要repaire
ERROR] log.logs: 1 client is using or hasn't closed the table properly
170310 11:54:14 [ERROR] mysqld: Table './log/oprlogs' is marked as crashed and should be repaired
170310 11:54:14 [Warning] Checking table: './log/oprlogs'
170310 11:54:14 [ERROR] log.oprlogs: 1 client is using or hasn't closed the table properly
170310 11:54:14 [ERROR] log.oprlogs: Size of datafile is: 1656831165 Should be: 1656830670
170310 11:54:47 [ERROR] log.oprlogs: Found 495 deleted space. Should be 0
170310 11:54:47 [ERROR] log.oprlogs: Found 15 deleted blocks Should be: 0
170310 11:54:47 [ERROR] log.oprlogs: Found 50207005 key parts. Should be: 50206990
170310 11:54:47 [ERROR] mysqld: Table './log/history' is marked as crashed and should be repaired
170310 11:54:47 [Warning] Checking table: './log/history'
170310 11:54:47 [ERROR] log.history: 1 client is using or hasn't closed the table properly
直接repair table table_name就可以了。。。。，依次修复日志中出现的被标记为crashed的表。
MariaDB [(none)]> repair table log.logs;
下面讲下修复 table：整理自网络。。。。。
多数情况下,数据库被破坏只是指索引文件受到了破坏,真正的数据被破坏掉的情况非常少。大多数形式的数据库破坏的的修复相当简单。
和前面的校验一样,修复的方式也有三种。
下面讲的方法只对MyISAM格式的表有效。其他类型的损坏需要从备份中恢复。
1,REPAIR TABLE SQL statement(mysql服务必须处于运行状态)。
2,命令mysqlcheck(mysql服务可以处于运行状态)。
3,命令myisamchk(必须停掉mysql服务,或者所操作的表处于不活动状态)。
在修复表的时候,最好先作一下备份。所以你需要两倍于原始表大小的硬盘空间。请确保在进行修复前你的硬盘空间还没有用完。
1>用”repair table”方式修复
语法:repair table 表名 [选项]
选项如下:
QUICK 用在数据表还没被修改的情况下,速度最快
EXTENDED 试图去恢复每个数据行,会产生一些垃圾数据行,万般无奈的情况下用
USE_FRM 用在.MYI文件丢失或者头部受到破坏的情况下。利用.frm的定义来重建索引
多数情况下,简单得用”repair table tablename”不加选项就可以搞定问题。但是当.MYI文件丢失或者头部受到破坏时,这样的方式不管用,例如:
mysql> REPAIR TABLE mytable;
+————————-+——–+———-+———————————————+
| Table | Op | Msg_type | Msg_text |
+————————-+——–+———-+———————————————+
| sports_results.mytable | repair | error | Can’t find file: ‘mytable.MYI’ (errno: 2) |
+————————-+——–+———-+———————————————+
修复失败的原因时索引文件丢失或者其头部遭到了破坏,为了利用相关定义文件来修复,需要用USE_FRM选项。例如:
mysql> REPAIR TABLE mytable USE_FRM;
+————————-+——–+———-+————————————+
| Table | Op | Msg_type | Msg_text |
+————————-+——–+———-+————————————+
| sports_results.mytable | repair | warning | Number of rows changed from 0 to 2 |
| sports_results.mytable | repair | status | OK |
+————————-+——–+———-+————————————+
我们可以看到Msg_test表项的输出信息”ok”,表名已经成功修复受损表。
2>用mysql内建命令mysqlcheck来修复
当mysql服务在运行时,也可以用mysql内建命令mysqlcheck来修复。
语法:mysqlcheck -r 数据库名 表名 -uuser -ppass
%mysqlcheck -r sports_results mytable -uuser -ppass
sports_results.mytable OK