查看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
我们重新回顾下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的知道执行到哪里就可以了