Binlog（一） 之 作用、三种模式介绍
目录
- 一、简介
- 二、作用
- 三、Binlog日志格式
- 3.1 三种模式
- 3.1.1 Statement
- 3.1.2 Row
- 3.1.3 Mixed
- 3.1 三种模式
- 3.2 三个模式下的注意事项
- 3.2.1 当存在临时表问题
- 3.2.2 在 主、从 复制过程中切换模式问题
- 3.2.3 主、从 模式不匹配问题
- 3.2.4 与存储引擎之间的关系问题
- 四、参数配置
- 五、参考
- 六、相关文章
一、简介
MySQL中的日志文件有很多，不同的数据库引擎自身还会维护属于自己不同作用的日志文件，而Binlog就是MySQL原始的二进制日志文件，它的全称是Binary Log。如果需要打开Binary Log需要借助MySQL提供的mysqlbinlog工具进行打开；
二进制日志文件中描述数据库更改的“事件”，主要是对数据库/表的更改操作，不包含select、show语句的记录；
二、作用
- MySQL主从模式下的，副本数据复制
有点类似于Redis的主从备份，Master命令执行完毕之后会将命令分发给所有副本，以完成数据在主从中能够达到一致性。
- 数据恢复
当数据误删，可以使用MySQL的工具从Binlog日志指定时间或指定日志偏移量进行数据恢复。
三、Binlog日志格式
服务器使用多种日志格式在二进制日志中记录信息。采用的确切格式取决于所使用的 MySQL 版本。共有三种日志格式，通过参数
binlog-format进行配置。
3.1 三种模式
3.1.1 Statement
这种方式是MySQL5.6版本中默认的方式；
该日志格式中，每个事件记录的是引起数据变化的SQL语句；
- 优势：
暂用磁盘空间非常少
速度快，对数据库的性能影响也会小很多 - 缺点：
对于非确定的SQL语句，在数据库服务主从复制或者数据备份的时候会产生结果的不一致性，譬如在SQL语句中使用了譬如NOW()或者UUID()内置函数，主服务器执行这些不确定函数的值与副本服务器执行时的值是为一致的。
引入官网的一段话：
With statement-based replication, there may be issues with replicating nondeterministic statements.
In deciding whether or not a given statement is safe for statement-based replication, MySQL determines whether it can guarantee that the statement can be replicated using statement-based logging. If MySQL cannot make this guarantee, it marks the statement as potentially unreliable and issues the warning, Statement may not be safe to log in statement format.
You can avoid these issues by using MySQL's row-based replication instead.
3.1.2 Row
该日志格式中，每个事件记录的是变化（受到影响）的行记录被修改的形式
- 优势：
解决了Statement模式下非确定语句带来的数据不一致的问题 - 缺点：
暂用磁盘空间大，对数据库服务的影响稍大一些
3.1.3 Mixed
混合日志记录，它会自动根据执行语句是否安全（主要是备份、恢复的一致性安全）进行切换Statement与Row模式；
服务器Mixed模式下，在如下场景会自动从Statement模式切换成Row模式，这里只选择了三个典型的场景，具体详见官网：https://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html
- 语句中包含
UUID() - 当AUTO_INCREMENT更新一个或多个带有列的表 并调用触发器或存储函数时。
- 如果语句按行记录并且执行该语句的会话有任何临时表，则所有后续语句（访问临时表的语句除外）都使用按行记录，直到删除该会话正在使用的所有临时表。
3.2 三个模式下的注意事项
下面的四种情况，看起来注意的事项比较多，但本质上只要记住，三个模式下，并不是完全兼容的即可。
3.2.1 当存在临时表问题
当存在任何临时表时，不建议在运行时切换复制格式，因为仅在基于Statement模式下的复制才会记录临时表，而Row和Mixed模式的大多数时间并不会记录这些。从而导致最终数据的不一致性。
3.2.2 在 主、从 复制过程中切换模式问题
在主从模式下，每个MySQL机器节点的binlog_format都是自己配置；主从的binlog_format并不会一起跟着修改；在Statement模式下，binlog_format的修改不会被记录进入binlog日志中；而在Row和Mixed模式下，虽然会记录进入日志，但是副本在进行复制运行的时会自动忽略对于binlog_format的执行。
若需要安全的更改模式，您必须停止复制，然后再确保Master Server与副本Server使用相同的更改。
这时候你可能会问，在主从同步的过程中就算不能保持各个Server的format一致性，又会出现什么样的问题呢？这里的本质请看3.2.3小节。
3.2.3 主、从 模式不匹配问题
Master Server如果使用了ROW或MIXED模式，则副本Server也必须使用，否则会出现副本Server无法解析并放入自己的Binlog文件中。
3.2.4 与存储引擎之间的关系问题
若使用InnoDB引擎，并且事务的隔离级别设置为READ COMMITTED、READ UNCOMMITED，则Binlog模式只能配置为ROW模式，如果切换成其它模式，那么在之后执行SQL语句时，会立即报错。
四、参数配置
关于Binlog的所有配置，可详见官网：
https://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html
这些配置都在my.ini或者my.cnf中[mysqld]的模块下进行配置；
这里只对Binlog日志的常用配置进行说明：
-
log-bin=[=base_name]
是一个复合配置，它等效于log-bin、log_bin_basename。作用是在开启Binlog的同时指定binlog文件名基础前缀。
binlog日志的默认名称为主机名的默认值.数字索引，官网强烈建议我们更换文件名称的基础前缀，原因如下：https://dev.mysql.com/doc/refman/5.6/en/known-issues.html,
后面数字索引的作用在于，每生成一个Binlog文件，数字会自增长，以示区分。
以下三种情况，服务器会自动创建一个新文件：- 服务器已启动或重新启动
- 服务器刷新日志
- 当前入职文件的大小达到max_binlog_size
注：在上述第三点中，实际上日志文件可能大于max_binlog_size，这是因为事务是不可分割的，必须在同一个日志文件中；
-
binlog_row_image=[full/minimal/noblob]
- full：记录前图像和后图像中的所有列。
- minimal：只记录之前图像中标识要更改的行所需的那些列；仅记录后映像中由 SQL 语句指定值或由自动增量生成的那些列。
- noblob：记录所有列（与 相同 full），除了 不需要标识行或未更改的BLOB和 TEXT列。
-
binlog_stmt_cache_size
此变量决定二进制日志的缓存大小，用于保存事务期间发出的非事务性语句。说白了，在执行事务期间，是不会向Binlog日志写入任何信息的，这些即将被写入日志的数据被缓存在Cache中，等到事务提交之后，才会从缓存写入日志中。Cache的作用域是针对不同客户端级别进行隔离的。
最小值：4096，默认值：32768，32位系统最大值：4294967295，64位系统最大值：18446744073709547520 -
expire_logs_days
自动二进制日志文件删除的天数。默认值是0，这意味着“不自动删除”。可能的删除发生在启动时和二进制日志刷新时。
最大值：99 -
max_binlog_size
如果对二进制日志的写入导致当前日志文件的大小超过这个变量的值，服务器就会旋转二进制日志(关闭当前文件并打开下一个文件)。最小值为4096字节。最大值为1GB，默认为1GB。一个事务被写到一个二进制日志块中，所以它永远不会被分成几个二进制日志。因此，如果您有大事务，您可能会看到大于max_binlog_size的二进制日志文件。
五、参考
六、相关文章
- [Binlog（二）之 文件结构与文件解读] : https://www.jianshu.com/p/b809e4c64ee1
- [Binlog（三） 之 数据误删恢复] : https://www.jianshu.com/p/95f9be2d5982
网友评论