Mysql主从同步失败,the slave's relay log is corrupted

空间不足先腾出空间,如果是binlog太大先去数据库执行命令关闭binglog再删除binglog文件

查看slave的状态

Master_Log_File: binlog.000339
Read_Master_Log_Pos: 782368851
Relay_Log_File: mysqld_game-relay-bin.001048
Relay_Log_Pos: 846524285
Relay_Master_Log_File: binlog.000338
Slave_IO_Running: No
Slave_SQL_Running: No
Exec_Master_Log_Pos: 846524125
Relay_Log_Space: 1856112071

几个pos值直接懵了Read_Master_Log_Pos居然比Exec_Master_Log_Pos还要小,写的比读的多？


我们重新回顾下mysql从库同步过程
通常网上列出的从库同步的过程为
io thread 写入Relay_Log
sql thread 从Relay_Log读取出来并写入数据库
但这里都遗漏了个步骤
因为磁盘性能远低于内存,所以同步的时候不可能等你写完Relay_Log_File再读取下一条同步信息
所以io thread在写入前会将同步过来的内容缓存到内存
----------------------------------------------------------
Master_Log_File: binlog.000339
Read_Master_Log_Pos: 782368851        这部分是就是io thread在内存中更新的
----------------------------------------------------------
Relay_Log_File: mysqld_game-relay-bin.001048
Relay_Log_Pos: 846524285
Relay_Master_Log_File: binlog.000338        这部分是io thread写完Relay_Log_File后更新的 
----------------------------------------------------------
Slave_IO_Running: No
Slave_SQL_Running: No
Exec_Master_Log_Pos: 846524125
Relay_Log_Space: 1856112071
----------------------------------------------------------
为什么Read_Master_Log_Pos会小于Relay_Log_Pos和Exec_Master_Log_Pos就明确了
内存中已经读到binlog.000339的782368851
硬盘中只写入到binlog.000338的846524125
内存中已经超出硬盘中一个binlog文件了
所以,恢复语句是
change master to Master_Log_File='binlog.000338', Master_Log_Pos=846524125;

来个极端的例子,不知道mysql是否会主动避免以下情况
Master_Log_File: binlog.000002
Read_Master_Log_Pos: 1234 
Relay_Log_Pos: 1
Relay_Master_Log_File: binlog.000002
Exec_Master_Log_Pos: 99999999

这时候,Relay_Log_File的binlog文件更新了但sql线程没更新
恢复语句主动减少binglog的位置
change master to Master_Log_File='binlog.000001', Master_Log_Pos=99999999;

顺便,恢复不需要关心Relay_Log_File,这玩意会自己重置,我们通过旧Relay_Log_File的知道执行到哪里就可以了