文章目录

  • 1. 日志类型
  • 1.1 日志的弊端
  • 2. 二进制日志（bin log）
  • 2.1 概念
  • 2.2 应用场景
  • 2.3 删除二进制文件
  • 3. 中继日志
  • 3.1 概念
  • 3.2 恢复的典型错误


1. 日志类型

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

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

1.1 日志的弊端

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

2. 二进制日志（bin log）

2.1 概念

它记录了数据库所有执行的DDL和DML等数据库更新事件的语句，但是不包含没有修改任何数据的语句（如数据查询语句select、show等）。

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

2.2 应用场景

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

2.3 删除二进制文件

#删除文件名2之前的二进制文件（不包含文件名2）
purge master logs to '文件名2'

#查看时间
mysqlbinlog --no-defaults "/var/lib/mysql/binlog/atguigu-bin.000005"
#删除20220105这个时间之前的创建的所有日志文件
PURGE MASTER LOGS before "20220105";

#删除所有二进制日志文件
RESET MASTER;

3. 中继日志

3.1 概念

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

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

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

3.2 恢复的典型错误

如果从服务器宕机，有的时候为了系统恢复，要重装操作系统，这样就可能会导致你的服务器名称与之前不同。而中继日志里是包含从服务器名的。在这种情况下，就可能导致你恢复从服务器的时候，无法从宕机前的中继日志里读取数据，以为是日志文件损坏了，其实是名称不对了。

解决的方法也很简单，把从服务器的名称改回之前的名称。