mysql binlog 格式

格式介绍

有三种格式,分别如下

  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 模式记录。