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）