前一阵跟一个同学唠嗑，说到了MySQL的这几个日志。那同学就感觉这几个日志挺深奥的挺难懂的。其实不用这么吓唬自己。
就比如说这几个日志，你有没有想过MySQL为啥要写日志呢？写日志就得有磁盘IO、不写不香吗？速度、性能还会变快。其实不然，MySQL会写日志，是因为记录下的日志能赋予MySQL一定的能力。
比如undo log让mysql有回滚事物的能力，redo log让mysql有崩溃恢复的能力，以及我们现在说的bin log让MySQL有搭建集群、数据备份、恢复数据的能力。
那你说，我不想让MySQL记录那些日志不行吗？肯定行啊！甚至默认情况下，MySQL都不会主动为你记录bin log ，但是话说回来，你不让它写那些日志，它就没有相应的能力给你用。是吧！所以综合来说，写日志还是很香的。
知道了这些，再去学相关的知识点是不是目的性很强了呢？关于undo log、redo log白日梦前面已经和大家分享过了，知无不言的那种分享哈，如果你又有感觉了，欢迎关注我然后去翻看。
对于大部分研发同学来说，肯定听说过bin log。然后却不一定知道binlog在哪里？谁写的？怎么配置binlog？以及binlog有啥用。所以接下来的几篇文章，我们一起看看binlog的二三事，让你更好的理解binlog。
二、什么是bin log？#
bin log是MySQL的二进制日志文件，翻译成中文名反倒是感觉怪怪的。所以说下面直接称他为binlog。
我们都知道MySQL分为两大部分。上层是MySQL-Server，下层是可插拔的存储引擎。
binlog就是由MySQL的Server层产生。
三、它在哪里？#
binlog存放的位置由datadir参数控制。
你可以通过下面的方式查看到它
知道了binlog具体在哪里，你就可以看一眼，如下
目录下有两种文件：mysql-bin.0000XX 和 mysql-bin.index
前者保存着对MySQL更改的逻辑
而后者长下面这样，估计你一看就懂了～
四、bin log的相关配置#
一般关于binlog的配置都写在MySQL的配置文件中: my.cnf , 以方便启动mysql时直接让这些配置生效
作为了解，你可以大概看一眼binlog的配置项
Copy[mysqld]
# binlog相关配置
# 指定binlog日志存储的位置
datadir = /home/mysql/mysql/var
# 规范binlog的命名为 mysql-bin.0000XX
# 如果加这行配置，binlog文件名为主机名
log-bin = mysql-bin
# 索引当前所有的binlog
log-bin-index = mysql-bin.index
# 最大的大小
max_binlog_size = 1G
# binlog的sync时机
sync-binlog = 1
# binlog的格式
binlog-format = ROW
# 保留七天的binlog
expire_logs_days = 7
五、binlog 有啥用？#
如果说redolog中记录的是偏向物理层面的记录，如：对哪个数据页的那个记录做了什么修改。
那么binlog中记录的是偏向逻辑层面的记录：如：对xxx表中的id=yyy的行做做了什么修改，更改后的值是什么。
binlog不会记录你的 select 、show这类的操作。
你可以在query log中找到曾经执行过的诸如select、show这种仅查询的SQL。
常见的binlog有如下的作用。
- delete没加where条件？不慌！binlog可以帮你恢复数据
- 搭建一套一主两从的MySQL集群，binlog帮你完成主从的数据同步。* 审计，通过分析binlog可以排查是否存在SQL注入攻击。
但是你知道吗？
默认binlog是不开启的。因为开启binlog后会稍微降低一点mysql的性能（1%）。
但是开启binlog后你就可以搭建MySQL集群，排查SQL注入，恢复误删的数据。所以线上的MySQL集群都是开启binlog的，是不是感觉开启binlog很有保障！很香呢？
六、超有用的参数 sql_log_bin#
跟大家分享一种线上实际存在的场景，你就能知道该参数的妙用了。
比如你线上使用的是一个一主两从的MySQL集群，然后有一个活动来了，你需要给线上某库的某数据表添加一列，并且这个表里面的数量非常之庞大。
添加一列是需要获取表锁的，并且庞大的数据量让你alter table异常缓慢，在获取表锁的过程中，正常的DML也会被阻塞。这时你就得考虑无损DDL，比如golang的ghost（怎么做的无损ddl原理我后门的文章会写的，本篇不展开）。
ghost工具的特点是，它需要预执行一些SQL目的是先校验一下你的集群符不符合它的要求，为了不对线上产生影响，你肯定会想把这些预执行的sql放到从库上执行。放在从库上执行固然没问题，但是你执行的sql会产生bin log。出现新的GTID（后面讲MySQL集群时会跟大家分享，这里你只需要理解成是一个事物的唯一标识就行）更要命的是，主库中没有这些GTID。
当主从都正常运行时，主从bin log不一致没关系，但是当从库宕机的时候，从库重启会将自己的GTID集合发送给主库，由于从库多出来一部分主库没有的GTID，会导致该从库不能再次加入集群。
其实这个问题也好解决。使用这个参数 sql_log_bin
该sql_log_bin变量控制是否为当前会话启用到二进制日志的日志记录（假设二进制日志本身已启用）。默认值为ON。要为当前会话禁用或启用二进制日志记录，请将会话sql_log_bin变量设置为 OFF或ON。
全局sql_log_bin变量是只读的，无法修改。
有疑问加站长微信联系（非本文作者）
