【MySQL进阶之路 | 高级篇】简述Bin Log日志

1. 日志类型

MySQL有不同类型的日志文件，用来存储不同类型的日志，分为二进制日志、错误日志、通用查询日志和慢查询日志，这也是常用的4种。MySQL 8又新增两种支持的日志:中继日志和数据定义语句日志。使用这些日志文件，可以查看MySQL内部发生的事情。

这六类日志分别为：

• 慢查询日志:记录所有执行时间超过long_query_time的所有查询，方便我们对查询进行优化。
• 通用查询日志:记录所有连接的起始时间和终止时间，以及连接发送给数据库服务器的所有指令，对我们复原操作的实际场景、发现问题，甚至是对数据库操作的审计都有很大的帮助。
• 错误日志:记录MySQL服务的启动、运行或停止MysQL服务时出现的问题，方便我们了解服务器的状态，从而对服务器进行维护。
• 二进制日志:记录所有更改数据的语句，可以用于主从服务器之间的数据同步，以及服务器遇到故障时数据的无损失恢复。
• 中继日志:用于主从服务器架构中，从服务器用来存放主服务器二进制日志内容的一个中间文件。从服务器通过读取中继日志的内容，来同步主服务器上的操作。
• 数据定义语句日志:记录数除二进制日志外，其他日志都是文本文件。

除二进制日志外，其他日志都是文本文件。默认情况下，所有日志创建于MySQL数据目录中。

2. 日志的弊端

• 日志功能会降低MySQL数据库的性能。例如，在查询非常频繁的MysQL数据库系统中，如果开启了通用查询日志和慢查询日志，MySQL数据库会花费很多时间记录日志。
• 日志会占用大量的磁盘空间。对于用户量非常大、操作非常频繁的数据库，日志文件需要的存储空间设置比数据库文件需要的存储空间还要大。

3. 二进制文件（bin log）

binlog可以说是MySQL中比较重要的日志了，在日常开发及运维过程中，经常会遇到。

binlog即binary log，二进制日志文件，也叫作变更日志(update log)。它记录了数据库所有执行的DDL和DML等数据库更新事件的语句，但是不包含没有修改任何数据的语句（如数据查询语句select、show等)。

它以事件形式记录并保存在二进制文件中。通过这些信息，我们可以再现数据更新操作的全过程。

如果想要记录所有语句（例如，为了识别有问题的查询)，需要使用通用查询日志。

binlog主要应用场景:

• 一是用于数据恢复，如果MySQL数据库意外停止，可以通过二进制日志文件来查看用户执行了哪些操作，对数据库服务器文件做了哪些修改，然后根据二进制日志文件中的记录来恢复数据库服务器。
• 二是用于数据复制，由于日志的延续性和时效性，master把它的二进制日志传递给slaves来达到tnaster-slave数据一致的目的。

可以说MysQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保持数据一致性。

3.1 场景：

二进制日志可以通过数据库的全量备份和二进制日志中保存的增量信息，完成数据库的无损失恢复I但是，如果遇到数据量大、数据库和数据表很多(比如分库分表的应用)的场景，用二进制日志进行数据恢复，是很有挑战性的，因为起止位置不容易管理。

在这种情况下，一个有效的解决办法是配置主从数据库服务器，甚至是一主多从的架构，把二进制日志文件的内容通过中继日志，同步到从数据库服务器中，这样就可以有效避免数据库故障导致的数据异常等问题。

3.2 bin log的写入机制

binlog的写入时机也非常简单，事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlogcache写到binlog文件中。因为一个事务的binlog不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为binlog cache。

我们可以通过binlog_cache_size参数控制单个线程binlog cache大小，如果存储内容超过了这个参数，就要暂存到磁盘(Swap)。binlog日志刷盘流程如下:

• 上图的write，是指把日志写入到文件系统的page cache，并没有把数据持久化到磁盘，所以速度比较快。
• 上图的fsync，才是将数据持久化到磁盘的操作。

write和fsync的时机，可以由参数sync_binlog控制，默认是0。为0的时候，表示每次提交事务都只write，由系统自行判断什么时候执行fsync。虽然性能得到提升，但是机器宕机，page cache里面的 binglog会丢失。如下图:

为了安全起见，可以设置为1，表示每次提交事务都会执行fsync，就如同redo log刷盘流程一样。最后还有一种折中方式，可以设置为N(N>1)，表示每次提交事务都write，但累积N个事务后才fsync。

在出现Io瓶颈的场景里，将sync_binlog设置成一个比较大的值，可以提升性能。同样的,如果机器宕机，会丢失最近N个事务的binlog日志。

3.3 bin log与redo log的对比

• redo log它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于InnoDB存储引擎层产生的。
• 而binlog是逻辑日志，记录内容是语句的原始逻辑，类似于“给ID=2这一行的c字段加1”，属于MySQLserver层。
• 虽然它们都属于持久化的保证，但是则重点不同。redo log让InnoDB存储引擎拥有了崩溃恢复能力。binlog保证了MySQL集群架构的数据一致性。

4. 中继日志（relay log）

中继日志只在主从服务器架构的从服务器上存在。从服务器为了与主服务器保持一致，要从主服务器读取二进制日志的内容，并且把读取到的儒息写入本地的日志文件中，这个从服务器本地的日志文件就叫中继日志。然后，从服务器读取中继日志，并根据中继日志的内容对从服务器的数据进行更新，完成主从服务器的数据同步。搭建好主从服务器之后，中继日志默认会保存在从服务器的数据目录下。

搭建好主从服务器之后，中继日志默认会保存在从服务器的数据目录下。

文件名的格式是:从服务器名-relay-bin.序号。中继日志还有一个索引文件:从服务器名 -relay-bin.index，用来定位当前正在使用的中继日志。