MySQL 二进制日志格式

3/7/2017来源:SQL技巧人气:599

MySQL 二进制日志格式

日志分类

MySQL存储引擎层日志 innodb 重做日志 回滚日志 MySQL服务层日志 二进制日志 慢查日志 通用日志

二进制日志介绍

记录了所有对MySQL数据库修改事件, 包括DDL和DML操作. 其中binlog仅记录成功执行的日志, 对于回滚或者Syntax Error而未执行的事件并不记录.

启用二进制日志

MariaDB [(none)]> show variables like 'log_bin'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | OFF | +---------------+-------+ 1 row in set (0.00 sec)

log_bin为OFF说为未启用二进制日志, 我们尝试通过以下指令打开

MariaDB [(none)]> set global log_bin = 'mariadb-bin'; ERROR 1238 (HY000): Variable 'log_bin' is a read only variable

好吧, 其实仍然是要修改my.cnf配置文件, 在my.cnf或自定义配置中添加[mysqld]组, 设置log_bin属性的值为mariadb-bin以开启binlog.

[mysqld] log_bin = /var/log/mysql/mariadb-bin

以后我们查看目录/var/log/mysql/的时候就会发现有如mariadb-bin.000001的一系列日志.待重启MySQL后执行

MariaDB [(none)]> show variables like 'log_bin'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | ON | +---------------+-------+ 1 row in set (0.00 sec)

现在也可以正常显示binary的信息

MariaDB [(none)]> show binary logs; +------------------+-----------+ | Log_name | File_size | +------------------+-----------+ | mysql-bin.000001 | 313 | +------------------+-----------+ 1 row in set (0.00 sec)

NOTE: mysql> flush logs; 用于产生新的二进制日志, 方便调试.

二进制日志的格式

基于段的日志格式 - statement

这是MySQL 5.7之前默认的日志格式, 记录CUD的SQL语句.

MariaDB [(none)]> show variables like 'binlog_format'; +---------------+-----------+ | Variable_name | Value | +---------------+-----------+ | binlog_format | STATEMENT | +---------------+-----------+ 1 row in set (0.00 sec) 查看日志

mysqlbinlog工具可直接用于查看日志

mysqlbinlog mysql-bin.000001 优点:

记录每个事件所执行的SQL语句, 故不需要记录每一行的具体变化, 所以日志记录量相对较少, 节约磁盘IO与网络IO(如果只对一条记录修改或者插入, ROW格式的日志量有可能少于STATEMENT格式).

缺点:

为了确保这些SQL语句能在从库中正确地执行, 所以要记录上下文信息, 以保证重放时的行为一致. 但如果使用UUID()这类非确定性函数, 可能会造成主从的数据不一致.

基于行的日志格式 - row

在MySQL 5.7后的默认格式, 每当进行CUD操作修改行记录时都会将数据写入binlog.

如果我们有一个修改了10k条数据的情况下, 基于段的日志格式仅会记录该条SQL, 而基于行的日志则会有10k条记录

查看日志 mysqlbinlog -vv mysql-bin.000001

优点

使主从复制更加安全, 由于ROW格式记录了每一行的更改, 当日志被从库重放时仅需应用该条更改即可, 使得不确定性函数也能安全地使用. 更大程度上减少由于主从数据不一致而造成复制链路中断的情况. 基于行的复制比基于段的复制要高效

缺点

记录的日志量较大

混合日志格式 - mixed

混合使用STATEMENT和ROW, 根据SQL语句由系统决定使用基于段还是基于行的日志格式, 如非确定性函数则会以ROW格式记录, 其他的以STATEMENT记录.

修改binlog格式

MariaDB [(none)]> set binlog_format = 'statement'; Query OK, 0 rows affected (0.00 sec) MariaDB [(none)]> show variables like 'binlog_format'; +---------------+-----------+ | Variable_name | Value | +---------------+-----------+ | binlog_format | STATEMENT | +---------------+-----------+ 1 row in set (0.00 sec)

ROW日志格式的相关优化

由于ROW格式记录的日志量巨大, 在MySQL 5.6以后, 官方增加了binlog_row_image参数改善其记录方式.

MariaDB [(none)]> show variables like 'binlog_row_image'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | binlog_row_image | FULL | +------------------+-------+ 1 row in set (0.00 sec)

FULL为默认值, 意思是记录一行纪录里面的所有内容, 无论该列是否被修改.

MINIMAL仅记录被修改的列, 这样就可以大大减少记录量.

NOBLOB与FULL类型, 但是如果没有修改BLOB或TEXT类型的列, 就不会记录该大数据类型的列.

实验

假如有表结构如下

CREATE TABLE `t_test` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `title` varchar(32) NOT NULL DEFAULT '', `content` text, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

表中有记录

id->1, title->'prontera', content->'hey guy'

FULL (全记录)

我们修改id为1的记录, 然后查看/var/log/mysql中的binlog

MariaDB [employees]> update t_test set title = 'solar' where id = 1; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0

可以看出, 我们仅仅set title, 但是binlog_row_image为FULL的时候会记录所有的列

BINLOG ' HPyWWBMBAAAANwAAAM8BAAAAACEAAAAAAAEACWVtcGxveWVlcwAGdF90ZXN0AAMDD/wDYAACBA== HPyWWBgBAAAASQAAABgCAAAAACEAAAAAAAEAA///+AEAAAAIcHJvbnRlcmEHAGhleSBndXn4AQAA AAVzb2xhcgcAaGV5IGd1eQ== '/*!*/; ### UPDATE `employees`.`t_test` ### WHERE ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='prontera' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */ ### @3='hey guy' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */ ### SET ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='solar' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */ ### @3='hey guy' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */

MINIMAL (按需记录)

同样地, 将id为1的记录的title更新为原先的’prontera’, 对比binlog的确是有效地减少了日志量

BINLOG ' rv2WWBMBAAAANwAAAM8BAAAAACEAAAAAAAEACWVtcGxveWVlcwAGdF90ZXN0AAMDD/wDYAACBA== rv2WWBgBAAAALQAAAPwBAAAAACEAAAAAAAEAAwEC/gEAAAD+CHByb250ZXJh '/*!*/; ### UPDATE `employees`.`t_test` ### WHERE ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### SET ### @2='prontera' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */

NOBLOB (除去BLOB&TEXT的全纪录) 更新时不包含text类型的列

MariaDB [employees]> update t_test set title = 'juno' where id = 1; Query OK, 1 row affected (0.01 sec) Rows matched: 1 Changed: 1 Warnings: 0

类似于FULL模式, 但是binlog不会记录没有被更新的大数据类型(BLOB或TEXT类型)

BINLOG ' hP+WWBMBAAAANwAAAM8BAAAAACEAAAAAAAEACWVtcGxveWVlcwAGdF90ZXN0AAMDD/wDYAACBA== hP+WWBgBAAAAMwAAAAICAAAAACEAAAAAAAEAAwMD/AEAAAAFcGF5b278AQAAAARqdW5v '/*!*/; ### UPDATE `employees`.`t_test` ### WHERE ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='payon' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */ ### SET ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='juno' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */

更新时包含text列

MariaDB [employees]> update t_test set title = 'prontera', content = 'google' where id = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0

当有大数据类型的列被更新时, 该列才会被记录, 一定程度上减少了日志量.

BINLOG ' PQCXWBMBAAAANwAAAM8BAAAAACEAAAAAAAEACWVtcGxveWVlcwAGdF90ZXN0AAMDD/wDYAACBA== PQCXWBgBAAAAPgAAAA0CAAAAACEAAAAAAAEAAwMH/AEAAAAEanVub/gBAAAACHByb250ZXJhBgBn b29nbGU= '/*!*/; ### UPDATE `employees`.`t_test` ### WHERE ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='juno' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */ ### SET ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='prontera' /* VARSTRING(96) meta=96 nullable=0 is_null=0 */ ### @3='google' /* BLOB/TEXT meta=2 nullable=1 is_null=0 */

通过实验, 在基于ROW格式情况下, 即使处于同一IDC, 也建议使用minimal模式以大量减少日志量.

Github

基于Docker Compose构建的MySQL MHA集群