MySQL Server层四个日志

一、MySQL Server层日志简介

当一个MySQL Server Client发起一个连接请求，在MySQL后端要做的事：

MySQL日志是在MySQL server上生成的，不管更改哪个存储引擎，这些日志都是需要有的，包括：

• 错误日志：记录mysqld服务运行过程中出现的cordump、error、exception等

• 查询日志：记录MySQL Server收到的所有SQL。由于上线项目的SQL太多了，开启查询日志IO太多导致MySQL效率低下，我们一般都不会开启，只有调试时才开启。比如通过查看sql发现热点数据进行缓存：
  

• 二进制日志：记录数据的更改（insert、update、delete、alter …），非常重要，可用于数据恢复，主从复制。主从复制技术依赖于log_bin，主库所有的更改操作都记录在log_bin里，从库从binlog读取主库所有的操作，自己再执行一遍。
  

• 慢查询日志：记录了一些执行时间超过指定值的SQL语句，可供开发人员分析耗时SQL，从而针对性优化

MySQL里定义了很多全局变量来记录设置或者状态，查看就是show variables（全局变量）或者show status（状态）。查看日志相关变量：

二、配置文件参数

打开my.ini，在后面加上上面的参数，保存后重启mysql服务就可以了。

通过set方法只能影响当前session，如果想要配置永久有效，需要在配置文件上进行设置，然后重启MySQL服务，就可以永久生效

linux下重启mysqld服务的命令：sudo service mysqld restart

我们查看一下配置文件/etc/mysql/my.cnf

• 给出log-error的路径就是开启了log-error，如果不自定义log-error的路径，默认在data_dir
• 在开启log-bin=mysql-bin的同时还要加上server-id=1(表示当前MySQL Server的身份），否则在linux root下sudo service mysqld restart会无法重启服务
• 设置过期的时间expire_log_days，因为总有一天磁盘会被这个日志占满，导致服务器不可运行，超过设置时间后日志文件会被删除

三、错误日志

四、二进制日志

二进制日志(BINLOG)记录了所有的DDL(数据定义语言)和DML(数据操纵语言)语句，但不包括数据查询语句。语句以“事件”的形式保存，它描述了数据的更改过程。此日志对于灾难时的数据恢复起着极其重要的作用。

两个重要的场景：主从复制、数据恢复。

查看binlog：show binary logs

二进制的内容无法直接查看，因为它并记录的不是明文，因为记录明文的话有点不太安全，毕竟是数据库表更改的详细内容，不像慢查询日志都是明文记录的。

binlog默认在MySQL的data_dir下

1. 演示binlog记录修改

先刷新一下，生成一个新的binlog

使用school数据库下的user表来演示：

执行insert和update操作

再次查看binlog

我们发现日志的filesize和刚才的不一样了，肯定记录我们刚才的数据更改操作

如果我们直接cat日志查看，会发现不是明文，无法直接查看

通过mysqlbinlog工具(mysql原生自带的工具)介意快速解析大量的binlog日志文件:

mysqlbinlog --no-defaults --database=school --base64-output=decode-rows -v --start-datetime='2022-03-01 00:00:00' --stop-datetime='2022-03-31 00:00:00' mysql-bin.000001 | more

• database：指定查看某个库的更改
• base64-output：binlog解码方式
• start-datetime & stop-datetime：指定查看某个时间段内的更改，不写则查看所有的更改
• mysql-bin.000001：查看的二进制日志文件

我们查看一下刚才发生变化的binlog：

• @1、@2、@3、@4：表示数据库表的4个字段
• server id：表示我们在my.cnf中设置的id，用于标识当前MySQL的身份
• at 565、at679：指的是当前事件在binlog记录的位置，数据恢复的时候使用。

2. 演示binlog数据恢复

创建mytest数据库，在里面创建user表并添加数据

假如现在有人把库删除了

这时mytest库的所有表和数据都没有了，然而这些操作都会记录在二进制日志binlog里面

理论上来说，可以从binlog把丢失的数据恢复出来。由于恢复过程也是对数据的修改，所以恢复过程产生的日志也要记录在binlog中，所以为了防止我们在数据恢复过程中不知道到底恢复到哪里结束好，或者分不清哪些二进制日志使我们需要恢复的哪些是恢复中新生成的，这就需要我们指定binlog恢复区间

我们现在知道，我们建库、建表、插入数据的操作都记录在mysql-bin.00003文件中

我们现在刷新一下，生成一个新的binlog，这就可以让我们接下来数据恢复的操作被记录在mysql-bin.00004文件中，而不会在追加到mysql-bin.00003

我们先查看mysql-bin.00003，找需要恢复的区间



从mysql-bin.000003中拿出区间内所有的操作，通过管道放到MySQL shell上执行

查看当前的库，可以看到mytest已经恢复出来

再查看表和数据

这样数据就全部被恢复了。

我们不仅可以通过binlog记录的位置，得到需要恢复的区间，也可以通过binlog记录的时间得到需要恢复的区间，参数为：start-datetime、stop-datetime

数据恢复在实际使用中注意：因为配置bin-log的时候还配置了mysql-bin，还配置了expire_logs_days（日志的过期时间），那么过期时间之前的数据如何恢复？

mysql数据的恢复需要依赖数据的备份和binlog的数据恢复。过期的日志数据都会进行备份，没有过期的数据可以直接通过binlog恢复。数据的备份一般都是把数据备份到sql的脚本文件当中，比如保存在~/data.sql里，然后在mysql里面用source ~/data.sql执行，或者如果在linux的shell里面可以用管道：cat ~/data.mysql|mysql -u root -p，就可以把我们之前备份的数据恢复到mysql的库表中。

五、慢查询日志

慢查询日志详解