• MySQL主从复制中问题排查过程总结


    MySQL主从复制中问题排查过程

    一、概述

    mysql主从是常用的高可用架构之一,也是使用最广泛的的系统架构。在生产环境中mysql主从复制有时会出现复制错误问题。MySQL主从复制中的问题(Coordinator stopped beacause there were errors in the workers......)

    二、mysql主从复制原理

    mysql主从复制是一个异步复制过程(总体感觉是实时同步的),mysql主从复制整个过程是由三个线程完成。slave端有两个线程(SQL线程和IO线程),Master端有另一个(IO线程)。

    MYSQL主从复制过程

    • 在Slave服务器上执行start slave,开启主从复制开关。

    • 此时,Slave 服务器上的 IO 线程通过 Master 服务器上授权复制用户的请求连接到 Master 服务器。它还请求从 binlog 日志文件的指定位置发送 binlog 日志内容。
      (配置主从复制任务时执行change master命令时指定日志文件名和位置)

    • Master服务器收到Slave服务器IO线程的请求后,Master服务器上的IO线程是基于Slave的。
      服务器的IO线程请求的信息在指定binlog日志文件的指定位置后读取binlog日志信息,然后返回给Slave端IO线程。除了binlog日志内容,在日志内容返回后Master服务器端还有一个新的binlog。
      binlog 中的文件名和下一个指定的更新位置。

    • 当 Slave 服务器的 IO 线程从 Master 服务器获取 IO 线程发送的日志内容、日志文件和位置点时,添加 binlog。日志内容依次写入Slave端自身的relay log文件(mysql-relay-bin.xxxxxx)的末尾。并将新的binlog文件名和位置记录到master-info文件中,以便下次读取Master端新的binlog日志时,可以告诉Master服务器从新的binlog日志中从哪个文件以及从哪里开始请求新的binlog日志内容.

    • Slave server端的SQL线程实时检测本地relay log中新增的日志内容,及时relay log。
      该文件的内容被解析成在Master端执行的SQL语句的内容,在Slave服务器本身按照语句的顺序执行SQL的应用。

    • 经过上述过程,可以保证在Master和Slave端执行相同的SQL语句。当复制状态正常时,Master
      端和lave端的数据是完全一致的。

      MySQL主从复制原理

    三、问题及解决方法

    1、show slave status \G 显示如下报错信息:

    Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction ...

    img

    2、根据提示信息定位报错位置

    情况一:"Delete_rows"

    select * from performance_schema.replication_applier_status_by_worker \G
    

    img

    原因:在master上删除一条记录,而slave上找不到。

    解决方法: 由于master要删除一条记录,而slave上找不到故报错,这种情况主上都将其删除了,那么从机可以直接跳过。

    stop slave;
    set global sql_slave_skip_counter=1;
    start slave;
    

    如上命令若报错:ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction或者可以换用如下命令:

    STOP SLAVE;
    SET @@SESSION.GTID_NEXT= 'f396f867-d755-11xxx85-005xxxxxb5a:264261655'    --在session里设置gtid_next,即跳过这个GTID
    BEGIN; COMMIT;       --设置空事物
    SET SESSION GTID_NEXT = AUTOMATIC;     -- 恢复GTID
    START SLAVE;xxxx
    

    情况二:"Duplicate "

    Last_SQL_Error: Could not execute Write_rows event on table xxx;
    Duplicate entry 'xxx' for key 'PRIMARY',
    

    原因:在slave已经有该记录,又在master上插入了同一条记录

    解决方法:在从库上删除该记录,或者跳过该记录。然后在master上和slave上再分别确认一下。

    情况三:"Update_rows" (还未碰到 待验证)

    Last_SQL_Error: Could not execute Update_rows event on table xxx;
    Can't find record in 'xxx',
    

    参考原因:在master上更新一条记录,而slave上找不到,丢失了数据。

    参考方法:在master上,用mysqlbinlog 分析下出错的binlog日志在干什么。

    /usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS mysql-bin.000010 | grep -A '10' 794
     
    #120302 12:08:36 server id 22 end_log_pos 794 Update_rows: table id 33 flags: STMT_END_F
    ### UPDATE hcy.t1
    ### WHERE
    ### @1=2 /* INT meta=0 nullable=0 is_null=0 */
    ### @2='bbc' /* STRING(4) meta=65028 nullable=1 is_null=0 */
    ### SET
    ### @1=2 /* INT meta=0 nullable=0 is_null=0 */
    ### @2='BTV' /* STRING(4) meta=65028 nullable=1 is_null=0 */
    # at 794
    #120302 12:08:36 server id 22 end_log_pos 821 Xid = 60
    COMMIT/*!*/;
    DELIMITER ;
    # End of log file
    ROLLBACK /* added by mysqlbinlog */;
    /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
    

    在slave上,查找下更新后的那条记录,应该是不存在的。

    mysql> select * from t1 where id=2;
    Empty set (0.00 sec)

    然后再到master查看

    ysql> select * from t1 where id=2;
    +----+------+
    | id | name |
    +----+------+
    | 2 | BTV |
    +----+------+
    1 row in set (0.00 sec)
    

    把丢失的数据在slave上填补,然后跳过报错即可。

    mysql> insert into t1 values (2,'BTV');
    Query OK, 1 row affected (0.00 sec)
     
    mysql> select * from t1 where id=2;
    +----+------+
    | id | name |
    +----+------+
    | 2 | BTV |
    +----+------+
    1 row in set (0.00 sec)
     
    mysql> stop slave ;set global sql_slave_skip_counter=1;start slave;
    Query OK, 0 rows affected (0.01 sec)
    Query OK, 0 rows affected (0.00 sec)
    Query OK, 0 rows affected (0.00 sec)
     
    mysql> show slave status\G;
    ……
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
    

    四、通用解决方法

    image-20211223134724031

    mysql主从复制,经常会遇到错误而导致slave端复制中断,这个时候一般就需要人工干预,跳过错误才能继续
    跳过错误有两种方式

    4.1 跳过指定数量的事务

    mysql>slave stop;
    mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1        #跳过一个事务
    mysql>slave start
    

    4.2 跳所有错误或指定类型的错误

    修改mysql的配置文件,通过slave_skip_errors参数来跳所有错误或指定类型的错误

    vi /etc/my.cnf
    [mysqld]
    #slave-skip-errors=1062,1053,1146 #跳过指定error no类型的错误
    #slave-skip-errors=all #跳过所有错误
    
    
    
  • 相关阅读:
    L99
    L98
    L97
    PyQt(Python+Qt)学习随笔:model/view架构中的QStandardItemModel使用案例
    PyQt(Python+Qt)学习随笔:model/view架构中的两个标准模型QStandardItemModel和QFileSystemModel
    PyQt(Python+Qt)学习随笔:Model/View架构中的Model模型概念
    PyQt(Python+Qt)学习随笔:Model/View架构概述
    第十四章、Model/View开发:Model/View架构程序设计模式
    Python中数字按位取反的方法
    PyQt(Python+Qt)学习随笔:Model中项的标记flags取值及枚举类型Qt.ItemFlag
  • 原文地址:https://www.cnblogs.com/lkj371/p/15853946.html
Copyright © 2020-2023  润新知