• mysql binlog_format row and Statement 比较


    两种模式的对比:
    Statement 优点
    历史悠久,技术成熟;
    产生的 binlog 文件较小;
    binlog 中包含了所有数据库修改信息,可以据此来审核数据库的安全等情况;
    binlog 可以用于实时的还原,而不仅仅用于复制;
    主从版本可以不一样,从服务器版本可以比主服务器版本高;

    Statement 缺点
    不是所有的 UPDATE 语句都能被复制,尤其是包含不确定操作的时候;
    调用具有不确定因素的 UDF 时复制也可能出现问题;
    运用以下函数的语句也不能被复制:
    * LOAD_FILE()
    * UUID()
    * USER()
    * FOUND_ROWS()
    * SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
    INSERT … SELECT 会产生比 RBR 更多的行级锁;
    复制须要执行全表扫描 (WHERE 语句中没有运用到索引) 的 UPDATE 时,须要比 row 请求更多的行级锁;
    对于有 AUTO_INCREMENT 字段的 InnoDB 表而言,INSERT 语句会阻塞其他 INSERT 语句;
    对于一些复杂的语句,在从服务器上的耗资源情况会更严重,而 row 模式下,只会对那个发生变化的记录产生影响;
    存储函数(不是存储流程 )在被调用的同时也会执行一次 NOW() 函数,这个可以说是坏事也可能是好事;
    确定了的 UDF 也须要在从服务器上执行;
    数据表必须几乎和主服务器保持一致才行,否则可能会导致复制出错;
    执行复杂语句如果出错的话,会消耗更多资源;

    Row 优点
    任何情况都可以被复制,这对复制来说是最安全可靠的;
    和其他大多数数据库系统的复制技能一样;
    多数情况下,从服务器上的表如果有主键的话,复制就会快了很多;
    复制以下几种语句时的行锁更少:
    * INSERT … SELECT
    * 包含 AUTO_INCREMENT 字段的 INSERT
    * 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
    执行 INSERT,UPDATE,DELETE 语句时锁更少;
    从服务器上采用多线程来执行复制成为可能;

    Row 缺点
    生成的 binlog 日志体积大了很多;
    复杂的回滚时 binlog 中会包含大量的数据;
    主服务器上执行 UPDATE 语句时,所有发生变化的记录都会写到 binlog 中,而 statement 只会写一次,这会导致频繁发生 binlog 的写并发请求;
    UDF 产生的大 BLOB 值会导致复制变慢;
    不能从 binlog 中看到都复制了写什么语句(加密过的);
    当在非事务表上执行一段堆积的 SQL 语句时,最好采用 statement 模式,否则很容易导致主从服务器的数据不一致情况发生;
    另外,针对系统库 MySQL 里面的表发生变化时的处理准则如下:
    如果是采用 INSERT,UPDATE,DELETE 直接操作表的情况,则日志格式根据 binlog_format 的设定而记录;
    如果是采用 GRANT,REVOKE,SET PASSWORD 等管理语句来做的话,那么无论如何都要使用 statement 模式记录;
    使用 statement 模式后,能处理很多原先出现的主键重复问题

  • 相关阅读:
    Javascript | 模拟mvc实现点餐程序
    DataTables实现按分组小计
    [Webcast]Silverlight探秘系列课程
    python 环境搭建
    MailMessage
    WebRequest
    消息队列(Message Queue)
    c# 缓存
    c# 反射
    数据库连接超时
  • 原文地址:https://www.cnblogs.com/moss_tan_jun/p/6401140.html
Copyright © 2020-2023  润新知