前段时间,公司一台从服务机断电关机了,再起来的时候,
我们查看 show slave status
从库已经和主库查了好几个日志文件了,那么我们现在能做的是什么呢?
首先,首先,首先,
关注以下这几个参数
Master_Log_File: mysql-bin.000*** //主库现在最新的日志文件版本
Relay_Master_Log_File: mysql-bin.000***//从库现在执行的主库日志文件版本
Slave_IO_Running: Yes//主从数据库之前的数据传输通道是否正常
Slave_SQL_Running: Yes//从库的执行日志脚本是否正常
Exec_Master_Log_Pos: 22563785//从库执行主库日志脚本到哪个文件位置了
Seconds_Behind_Master: 0//可以理解为主从延迟的时间差,此值越大,延迟越明显
那么出现延迟了,就要恢复同步,一般情况下是因为从库执行sql的时候发生了错误,导致Slave_SQL_Running=no 所以就会越来越大的延迟.
Last_SQL_Error//最近一次的从库执行sql的异常信息
Last_SQL_Errno//最近一次从库执行主库日志文件异常的code码
以下列举了一些较为常见的错误码
1007：数据库已存在，创建数据库失败
1008：数据库不存在，删除数据库失败
1050：数据表已存在，创建数据表失败
1051：数据表不存在，删除数据表失败
1054：字段不存在，或程序文件跟数据库有冲突
1060：字段重复，导致无法插入
1061：重复键名
1068：定义了多个主键
1094：位置线程ID
1146：数据表缺失，请恢复数据库
1053：复制过程中主服务器宕机
1062：主键冲突 Duplicate entry '%s' for key %d
那么只需要看一下 Last_SQL_Error的提示,来解决掉这个问题,就可以了,如果这个错误无关紧要,就比如 1062：主键冲突 Duplicate entry '%s' for key %d 此类错误
那么直接
stop slave;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
start slave;
就可以恢复同步了.
但是如果还会持续出现此类问题,那么在你觉得安全的情况下可以去 mysql.cnf 里面
将
slave_skip_errors=error_code,error_code
保存my.cnf
重启mysql
那么此err_code的问题就不会出现了.
如果出现了
Last_Error: Relay log read failure: Could not parse relay log event entry.
此类的问题,那么就证明了,在从库执行同步操作的时间,突然断电,引起一个事件没有执行完,但是Exec_Master_Log_Pos却记录下来的此时的处理字节地址.
此时我们就需要重新设置从库同步主库的日志文件和读取文件字节码位置.
那么这个日志文件一般来说就是 Relay_Master_Log_File所指的文件版本
字节码位置怎么确定呢?那就需要去主库里的这个日志文件里面去查找Exec_Master_Log_Pos 所展示的值附近的事件.
怎么找呢?
用以下的命令
mysql-> show binlog events in 'mysql-bin.000***' limit ****,1;
命令展示出来的结果里面有Pos这个字段,那么就一直找这个pos在Exec_Master_Log_Pos之钱的事件的最接近的pos. 就是我们要找的 pos
那么在从库上执行
stop slave;
change master to master_log_file='mysql-bin.***', master_log_pos=pos;
start slave;
基本上我们就重新设置好了同步位置.最后查看一下
show slave status;
下面加上一个其他同步数据库问题的解决办法的文章
https://yq.aliyun.com/articles/27685
也希望大家看一下,希望能给大家提供一点帮助
