mysql 二进制日志详解_Mysql二进制日志详解

引言

注：图片取自网络

提一下比较重要的几个：

重做日志(Redo Log)：重做日志是实现mysql事务的持久性的原理之一，当新增数据时，Redo Log会备份新数据，在事务提交前，只要持久化Redo Log即可，而不需要持久化实际数据，如果这时候mysql系统崩溃，虽然数据还没有持久化新增数据，但是Redo Log已经持久化了，系统可以根据Redo Log内容将数据恢复到最新的状态。

回滚日志(Undo Log)：回滚日志是实现mysql事务的原子性和一致性的原理之一，在操作任何数据之前，会先将数据备份到某个地方(这个存储数据备份的地方称为Undo Log)，然后进行数据的修改，当修改发生错误或用户执行了Rollback回滚操作，系统就会根据Undo Log恢复到事务执行之前的状态。

二进制日志(binlog)：MySQL的二进制日志是MySQL服务层的日志之一。其记录了所有对MySQL数据库的CRUD事件，包括增删改查和对表的系列操作记录，其记录的日志都是经过comomit的操作，对于失败、回滚或未提交的操作不会记录。通过mysql的二进制日志增量，可以较好到的实现mysql的复制和备份。

慢查日志(slow_query_log):参考我的这篇文章https://blog.csdn.net/fanrenxiang/article/details/83687241

中继日志(relay_log)：这个日志暂时还没怎么研究过，只知道在mysql主从复制时候用到了，从服务器上会将二进制日志写入relay_log，然后从服务器再重放relay_log来实现mysql复制功能。

三种二进制日志格式

statement：基于SQL语句的形式，采用这种格式的话，你的二进制日志文件里记录的就是你执行的SQL语句，例如你执行的是delete from table where id<100;那记录的就是该条SQL，个人觉得记录的比较"粗糙";

row：行格式记录二进制日志，记录的是SQL对应的每一行的操作，粒度比statement细，也是推荐的格式;

mixed：混合格式，由mysql自己决定什么时候用row，什么时候用statement;

mysql> show variables like '%log_bin%'; #查看二进制相关信息

+---------------------------------+---------------------------------------+

| Variable_name | Value |

+---------------------------------+---------------------------------------+

| log_bin | ON |

| log_bin_basename | /usr/local/mysql/data/mysql-bin |

| log_bin_index | /usr/local/mysql/data/mysql-bin.index |

| log_bin_trust_function_creators | OFF |

| log_bin_use_v1_row_events | OFF |

| sql_log_bin | ON |

+---------------------------------+---------------------------------------+

6 rows in set (0.01 sec)

mysql> show variables like '%binlog_format%'; #查看二进制日志格式

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | ROW |

+---------------+-------+

1 row in set (0.00 sec)

二进制日志若未开启，在 /etc/my.cnf 中的[mysqld]下面加上即可开启

[mysqld]

log-bin=/logs/mysql-bin ##二进制日志存放位置

binlog_format=statement ##二进制日志格式

或者执行如下命令即可

mysql> set global binlog_format=MIXED;

如果你没显式的配置二进制日志的目录位置，默认在${mysql安装目录}/data/下。

二进制日志格式对比

binlog_format=statement

日志记录量较小，节约磁盘空间和网络IO

非确定行函数复制可能失败，主从复制存在不一致风险

binlog_format=row

避免主从复制不一致问题，复制效率高于statement

日志记录量大于statement，自然就消耗多一些的磁盘和IO

binlog_format=mixed

根据sql语句由系统决定使用row还是statement格式

可以使用下面语句修改日志格式：

mysql>set global binlog_format=row;

当binlog_format=statement时数据库进行批量操作时，如update tablename set column1=‘foo’ where id>2，则statement格式只记录此条sql，而row格式则会记录每一行的修改操作。

mysql 5.7版本开始，其二进制日志格式默认为row。其中，row格式中细化的binlog_row_image属性又可设置为FULL、MINIMAL、NOBLOB 类型，这里推荐使用binlog_row_img=MINIMAL。

mysql> show variables like 'binlog_row_image'; //查询row格式

mysql> set global binlog_row_image=minimal; //设置row格式

如何选择mysql的二进制日志格式

推荐使用binlog_format=mixed，若复制操作走的是内网操作，则可以选择row格式来确保主从复制一致性，同时选择binlog_row_image=minial格式来减少磁盘占用和网络IO。

binlog_format=statement还是binlog_format=row决定了复制方式是基于sql语句的复制还是基于行的复制，其优缺点大致参考这两种日志格式对应的优缺点。

二进制日志的记录时机

二进制日志文件的记录可以是同步或者异步，写入时机在mysql事务提交之后，主要由sync_binlog参数决定，当sync_binlog=1表示最高安全级别的写入(最大程度的保证事务不丢失)

mysql> show variables like '%sync_binlog%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| sync_binlog | 1 |

+---------------+-------+

1 row in set (0.01 sec)

二进制日志的文件大小

单个二进制日志文件的大小限制，可以通过以下命令查看

mysql> show variables like 'max_binlog_size';

+-----------------+------------+

| Variable_name | Value |

+-----------------+------------+

| max_binlog_size | 1073741824 |

+-----------------+------------+

1 row in set (0.01 sec)

如果超过了这个限制，则会自动滚动清理，也就是由之前的mysql-bin.000001变为mysql-bin.000002。

通过show master logs;命令来查看当前二进制日志文件数。

二进制日志文件的滚动清理

上面说到，超过限制大小后会自动生成新的二进制日志文件，这里说的是这些日志文件的删除

mysql> show variables like 'expire_logs_days';

+------------------+-------+

| Variable_name | Value |

+------------------+-------+

| expire_logs_days | 0 |

+------------------+-------+

1 row in set (0.01 sec)

如上是0，表示不过期，如果我设置为2，表示超过两天的二进制日志会被自动删除。

也可以手动 flush logs;来显式的进行二进制日志文件的滚动清理。

引申文章：

Mysql主从复制-基于GTID复制(https://blog.csdn.net/fanrenxiang/article/details/70197004)

Mysql主从复制-基于日志点复制(https://blog.csdn.net/fanrenxiang/article/details/70194707)