• ADADADADAD

    MySQL中binlog三种格式的优缺点是什么[ mysql数据库 ]

    mysql数据库 时间:2024-11-26 22:15:44

    作者:文/会员上传

    简介:

    MySQL binlog的格式有三种,基于SQL语句的复制(statement-based replication, SBR),基于行的复制(row-based replication, RBR),混合模式复制(mixed-based replication, MBR)。

    以下为本文的正文内容,内容仅供参考!本站为公益性网站,复制本文以及下载DOC文档全部免费。

    MySQL binlog的格式有三种,基于SQL语句的复制(statement-based replication, SBR),基于行的复制(row-based replication, RBR),
    混合模式复制(mixed-based replication, MBR)。相应地,binlog的格式也有三种:STATEMENT,ROW,MIXED。它主要用于mysql的复制技术。

    STATEMENT是基于sql语句级别的binlog,每一条修改数据的sql都会被保存到binlog里;ROW是基于行级别的,他会记录每一行记录的变化,就是将每一行的修改都记录到
    binlog里面,记录的非常详细,但sql语句并没有在binlog里,在replication里面也不会因为存储过程触发器等造成Master-Slave数据不一致的问题,但是有个致命的缺点
    日志量比较大.由于要记录每一行的数据变化,当执行update语句后面不加where条件的时候或alter table的时候,产生的日志量是相当的大。MIXED:在默认情况下是
    statement,但是在某些情况下会切换到row状态,如当一个DML更新一个ndb引擎表,或者是与时间用户相关的函数等。

    SBR 的优点:
    历史悠久,技能成熟
    binlog文件较小
    binlog中包含了所有数据库修改信息,可以据此来审核数据库的安全等情况
    binlog可以用于实时的还原,而不仅仅用于复制
    主从版本可以不一样,从服务器版本可以比主服务器版本高
    SBR 的缺点:
    不是所有的UPDATE语句都能被复制,尤其是包含不确定操作的时候。
    调用具有不确定因素的 UDF 时复制也可能出疑问
    运用以下函数的语句也不能被复制:
    * LOAD_FILE()
    * UUID()
    * USER()
    * FOUND_ROWS()
    * SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
    INSERT … SELECT 会产生比 RBR 更多的行级锁
    复制须要执行 全表扫描(WHERE 语句中没有运用到索引)的 UPDATE 时,须要比 RBR 请求更多的行级锁
    对于有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 语句会阻塞其他 INSERT 语句
    对于一些复杂的语句,在从服务器上的耗资源情况会更严重,而 RBR 模式下,只会对那个发生变化的记录产生影响
    存储函数(不是存储流程 )在被调用的同时也会执行一次 NOW() 函数,这个可以说是坏事也可能是好事
    确定了的 UDF 也须要在从服务器上执行
    数据表必须几乎和主服务器保持一致才行,否则可能会导致复制出错
    执行复杂语句如果出错的话,会消耗更多资源


    RBR 的优点:
    任何情况都可以被复制,这对复制来说是最安全可靠的
    和其他大多数数据库系统的复制技能一样
    多数情况下,从服务器上的表如果有主键的话,复制就会快了很多
    复制以下几种语句时的行锁更少:
    * INSERT … SELECT
    * 包含 AUTO_INCREMENT 字段的 INSERT
    * 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
    执行 INSERT,UPDATE,DELETE 语句时锁更少
    从服务器上采用多线程来执行复制成为可能
    RBR 的缺点:
    binlog 大了很多
    复杂的回滚时 binlog 中会包含大量的数据
    主服务器上执行 UPDATE 语句时,所有发生变化的记录都会写到 binlog 中,而 SBR 只会写一次,这会导致频繁发生 binlog 的并发写疑问
    UDF 产生的大 BLOB 值会导致复制变慢
    不能从 binlog 中看到都复制了写什么语句(加密过的)
    当在非事务表上执行一段堆积的SQL语句时,最好采用 SBR 模式,否则很容易导致主从服务器的数据不一致情况发生
    另外,针对系统库 mysql 里面的表发生变化时的处理准则如下:
    如果是采用 INSERT,UPDATE,DELETE 直接操作表的情况,则日志格式根据 binlog_format 的设定而记录
    如果是采用 GRANT,REVOKE,SET PASSWORD 等管理语句来做的话,那么无论如何 都采用 SBR 模式记录。


    MBR融合了两种记录模式的优点。故个人推荐使用MBR模式。

    查看binlog格式方法:
    mysql> show variables like 'binlog_format';
    +---------------+-----------+
    | Variable_name | Value |
    +---------------+-----------+
    | binlog_format | STATEMENT |
    +---------------+-----------+
    1 row in set (0.00 sec)


    如何修改binlog格式为MBR模式:

    不重启修改方法(只对该登录会话有效,重新登录无效)
    mysql> SET SESSION binlog_format = 'MIXED';
    Query OK, 0 rows affected (0.00 sec)

    mysql> show variables like 'binlog_format';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | binlog_format | MIXED |
    +---------------+-------+
    1 row in set (0.00 sec)

    重启MySQL服务修改方法:
    编辑/etc/my.cnf文件,加入以下设置:
    binlog_format=mixed
    重启服务后永久生效。

    MySQL中binlog三种格式的优缺点是什么.docx

    将本文的Word文档下载到电脑

    推荐度:

    下载
    热门标签: mysqlbinlog