mysql binlog格式 有更新!

  |   0 评论   |   259 浏览

格式介绍

有三种格式,分别如下

  1. Statement:每条修改数据的sql都会保存在binlog中
  2. Row:只保存哪条记录被修改了,不记录修改的上下文/sql等
  3. MixedLevel:以上两种的混合使用

分别介绍下优缺点和适用场景

Statement

  • 优点
    • 相比row:不记录每一行的变化,可以减少io提升性能。当然,这也取决于应用的sql,如果是普通的一行修改,区别可能不大,但如果是整表操作,或者带条件的update?等,row会产生大量的日志
  • 缺点
    • 由于记录的只是执行语句,为了这些语句能在slave上正确运行,因此还必须记录每条语句在执行的时候的一些相关信息,以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能,slave可与master上要保持一致会有很多相关问题(如sleep()函数, lastinsert_id(),以及user-defined functions(udf)会出现问题).

Row

  • 优点
    能保存每行数据修改的细节,且不会出现某些特定情况下的存储过程,或function,以及trigger的调用和触发无法被正确复制的问题
  • 缺点
    也就是上面提到的,如果表结构修改之类的,会产生大量的记录

MixedLevel

mysql会根据情况来区别对带不同的sql,基本上是优化中和了上面两种情况吧。

配置和格式设定

1.基本配制

Mysql BInlog日志格式可以通过mysql的my.cnf文件的属性binlog_format指定。如以下:

binlog_format = MIXED //binlog日志格式

log_bin =目录/mysql-bin.log //binlog日志名

expire_logs_days = 7 //binlog过期清理时间

max_binlog_size 100m //binlog每个日志文件大小

2.Binlog日志格式选择

Mysql默认是使用Statement日志格式,推荐使用MIXED.

由于一些特殊使用,可以考虑使用ROWED,如自己通过binlog日志来同步数据的修改,这样会节省很多相关操作。对于binlog数据处理会变得非常轻松,相对mixed,解析也会很轻松(当然前提是增加的日志量所带来的IO开销在容忍的范围内即可)。

3.mysqlbinlog格式选择

mysql对于日志格式的选定原则:如果是采用 INSERT,UPDATE,DELETE 等直接操作表的情况,则日志格式根据 binlog_format 的设定而记录,如果是采用 GRANT,REVOKE,SET PASSWORD 等管理语句来做的话,那么无论如何 都采用 SBR 模式记录。

评论

发表评论

validate