登录
首页 >  数据库 >  MySQL

MySQL复制环境下诡异的binlog_format参数

来源:SegmentFault

时间:2023-02-16 15:17:57 490浏览 收藏

大家好,今天本人给大家带来文章《MySQL复制环境下诡异的binlog_format参数》,文中内容主要涉及到MySQL,如果你对数据库方面的知识点感兴趣,那就请各位朋友继续看下去吧~希望能真正帮到你们,谢谢!

源文将持续更新,请点击此处阅读原文

一、问题描述:

有一次在MySQL从库上执行binlog_format=row之后,发现binlog的格式咋还是statement,并没有变化为binlog_format,查阅MySQL官方手册发现binlog_format的确是个动态修改的参数(官方手册请点击此处),这是为啥呢?

二、假想测试:

# 测试表结构
CREATE TABLE t(id INT NOT NULL DEFAULT '0');
  1. 官方文档错误?毕竟我曾经的确给官方文档提出一个BUG,并且MySQL官网很快给修改了。。

    # 主库上测试
    # 修改主库的binlog_format
    set global binlog_format=statement;
    set session binlog_format=statement;
    insert into t values(6);
    
    # 查看binlog
    # at 441
    #161206 20:40:13 server id 2263333  end_log_pos 542 CRC32 0x3eeb2569     Query    thread_id=1215    exec_time=0    error_code=0
    use `fianna`/*!*/;
    SET TIMESTAMP=1481028133/*!*/;
    insert into t values(6)
    /*!*/;
    # at 542
    

结论:官方文档并没有欺骗我,的确是可以动态修改的。。。

  1. 莫非从库上binlog_format并不是动态修改型参数?

    # 从库上测试
    # 修改从库binlog_format
    set global binlog_format=statement;
    set session binlog_format=statement;
    insert into t values(11);
    
    # 查看binlog
    # at 984
    #161206 20:41:31 server id 2273333  end_log_pos 1032 CRC32 0xa3865eac     Rows_query
    # insert into t values(11)
    # at 1032

结论:从库上的binlog_format也是动态修改参数。。

  1. 难道从库上从主库复制来的SQL才会导致binlog_format没有修改?

    # 主从同时测试
    # 修改主库binlog_format
    set global binlog_format=row;
    set session binlog_format=row;
    # 修改从库binlog_format
    set global binlog_format=row;
    set session binlog_format=row;
    
    #  主库执行
    insert into t values(5);
    
    # 主库binlog
    # at 740
    #161206 20:43:00 server id 2263333  end_log_pos 780 CRC32 0x0ab3fb46     Write_rows: table id 3523 flags: STMT_END_F
    
    BINLOG '
    VLJGWB0liSIALwAAALYCAACAABdpbnNlcnQgaW50byB0IHZhbHVlcyg2KeLjoRw=
    VLJGWBMliSIALgAAAOQCAAAAAMMNAAAAAAEABmZpYW5uYQABdAABAwABl8Yg5A==
    VLJGWB4liSIAKAAAAAwDAAAAAMMNAAAAAAEAAgAB//4GAAAARvuzCg==
    '/*!*/;
    ### INSERT INTO `fianna`.`t`
    ### SET
    ###   @1=5 /* INT meta=0 nullable=1 is_null=0 */
    # at 780
    
    # 从库binlog
    # at 984
    #161206 20:43:01 server id 2273333  end_log_pos 1032 CRC32 0xa3865eac     Rows_query
    # insert into t values(5)
    # at 1032
    

结论:好像binlog_format对于主从复制的SQL并没有影响。。

  1. 如果restart slave,binlog_format是否有影响呢?

    # 主从同时测试
    # 修改主库binlog_format
    set global binlog_format=row;
    set session binlog_format=row;
    # 修改从库binlog_format
    set global binlog_format=row;
    set session binlog_format=row;
    stop slave;
    start slave;
    
    #  主库执行
    insert into t values(2);
    
    # 主库binlog
    # at 998
    #161206 20:53:00 server id 2263333  end_log_pos 998 CRC32 0x0ab3fb46     Write_rows: table id 3523 flags: STMT_END_F
    
    BINLOG '
    VLJGWB0liSIALwAAALYCAACAABdpbnNlcnQgaW50byB0IHZhbHVlcyg2KeLjoRw=
    VLJGWBMliSIALgAAAOQCAAAAAMMNAAAAAAEABmZpYW5uYQABdAABAwABl8Yg5A==
    VLJGWB4liSIAKAAAAAwDAAAAAMMNAAAAAAEAAgAB//4GAAAARvuzCg==
    '/*!*/;
    ### INSERT INTO `fianna`.`t`
    ### SET
    ###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
    # at 998
    
    # 从库binlog
    # at 1078
    #161206 20:53:01 server id 2273333  end_log_pos 1118 CRC32 0x81a97c17     Write_rows: table id 47129 flags: STMT_END_F
    
    BINLOG '
    F7RGWB01sCIAMAAAAAgEAACAABhpbnNlcnQgaW50byB0IHZhbHVlcygxMSmsXoaj
    F7RGWBM1sCIALgAAADYEAAAAABm4AAAAAAEABmZpYW5uYQABdAABAwAB3jnZ6w==
    F7RGWB41sCIAKAAAAF4EAAAAABm4AAAAAAEAAgAB//4LAAAAF3ypgQ==
    '/*!*/;
    ### INSERT INTO `fianna`.`t`
    ### SET
    ###   @1=2 /* INT meta=0 nullable=1 is_null=0 */
    # at 1118

结论:restart slave之后,binlog_format立即动态被修改。

三、问题总结

主从复制中,从库的binlog_format动态修改后,并不能立即于来自于主库的SQL(即复制SQL)立即生效,需要在从库执行

stop slave;
`start slave;`之后,方可生效。

今天关于《MySQL复制环境下诡异的binlog_format参数》的内容就介绍到这里了,是不是学起来一目了然!想要了解更多关于mysql的内容请关注golang学习网公众号!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表