mysql主从同步故障整理

Posted 2020-06-17

快速简单的解决办法：根据错误日志情况，简单快速确认故障点，然后确认是否可以跳过这个错误,跳过错误的方法是：set global sql_slave_skip_counter=1;跳过并忽略错误。

故障整理：

• 
  

  • 在master上删除一条记录时出现的故障。

    在master上删除一条记录后，slave上因找不到该记录而报错。出现这种情况的原因是主机上已将其删除了，对此，可采取从机直接跳过的方式解决。stop slave;set global sql_slave_skip_counter=1;start slave;

  • 主键重复。

    主从数据不一致，slave上已经有该条记录，但我们又在master上插入了同一条记录是，就会报错。

    解决办法：查到相应主键，然后确认数据是否缺少存在，去过数据已经存在，可以跳过这个错误。或者delete掉这个主键。

  • 在master上更新一条记录，而slave上却找不到。

    master上有该记录，但slave上没有，当之后又更新了这个记录时就会报错。

    解决办法：在master上，用mysqlbinlog分析一下出错的binlog日志在干什么，例如一跳update语句，就可以在slave上找一下更新后的那条记录，应该不存在。然后在master上找到这一行数据，手动inster到slave上。然后在跳过报错即可。

  • slave的中继日志relay-log损坏。

    当slave意外宕机时，有可能损坏中继日志relay-log，在次开启同步复制，就会报错。

    解决办法：找到同步的binglog日志和pos点，重新同步即可。如可查找呢：

    show slave status\G,其中，涉及几个重要参数：

    slave_io_running:接受master的binlog信息。（io线程的工作）

     master_log_file:正在读取master上binlog日志名。

     read_master_log_pos:正在读取master上当前binlog日志的pos点。

    slave_sql_running,执行写操作。（sql线程的工作）

     relay_master_log_file:正在同步master上的binlog日志名。

     exec_master_log_pos:正在同步当前binlog日志的pos点。

    可以以relay_master_log_file和exec_master_log_pos参数值为基准，进行重新同步，重新获取binlog，即重新change master to xxx xxx;

    其实在my.cnf中加入参数relay_log_recover=1就可以解决了。

  • 认为失误，server_id重复。

    解决办法：修改server_id，重新启动mysql即可。

  • 避免在master上执行大事物。

    例如要delete一个表中的old数据，表比较大，删除的数据量也比较大，当使用一条命令一次删除，就会产生大事物，就一下子就把slave卡死了。现象：slave的exec_master_log_pos(sql写线程）不变化，seconds_behind_master的值却越来越大，导致同步落后越来越多。

    解决办法：写一个存储过程，每次删除1000条，直至删除完成。存储过程以后完善。

    
    

    内容来源于mysql管理之道（第四章）手打。