MySQL日志管理

1 MySQL日志

1.1 错误日志

文件名：可用–log-error[=file_name]指定，否则默认使用hostname.err

内容：记录mysqld启动和停止时，以及服务器发生任何严重错误时记录相关信息

1.2 二进制日志

文件名：也是binlog(逻辑日志)，可用–log-bin[=file_name] 指定，默认为主机名

内容：包含了所有更新了或者潜在更新了数据的所有语句，语句以“事件”的形式保存，描述数据更改文件位置和格式

查看日志：

mysqlbinlog log-file

删除日志：

#删除所有的binlog日志，新日志从头开始编号
RESET MASTER
#删除mysql-bin.010之前的所有日志
PURGE MASTER LOGS TO 'mysql-bin.010'
#删除2022.5.1之前的binlog日志
purge master logs before '2022-05-01 08:00:00';

1.3 查询日志

文件名：使用–log指定，默认hostname.log

内容：记录客户端所有查询语句记录，在二进制日志不存在查询语句记录

1.4 慢查询日志

文件名：使用–log-slow-querie指定，默认*-slow.log，写入data目录

内容：记录执行时间超过long_query_time秒的SQL查询日志文件

其它选项：–log_slow_admin_statements：表示将慢管理语句，如OPTIMIZE TABLE、ANALYZE TABLE和ALTER TABLE写入慢查询语句

1.5 通用查询日志

查看：show variables like '%general_log%';

执行SQL命令 set global general_log=on; 开启

文件：默认存放在data目录下hostname.log文件

内容：记录客户端的所有查询行为

1.6 中继日志

文件：默认文件名hostnamet-relay-bin，存放在data目录下

功能：从服务器I/O线程将主服务器的二进制日志读取过来记录到从服务器本地文件，然后从服务器SQL线程会读取relay-log日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致

参数：show variables like '%relay%';

• max_relay_log_size
  • relay log 允许的最大值，如果该值为0，则默认值为 max_binlog_size (1G)
  • 如果不为0，则 max_relay_log_size 则为最大的relay_log文件大小
• relay_log
  • 定义 relay_log 的位置和名称，如果值为空，则默认位置在数据文件的目录
• relay_log_index
  • 定义 relay_log 索引的位置和名称，记录有几个 relay_log 文件，默认为2个
• relay_log_info_file
  • 定义 relay-log.info 的位置和名称，relay-log.info 记录 master 主库的 binary_log 的恢复位置和 从库 relay_log 的位置
• relay_log_purge
  • 是否自动清空中继日志，默认值为1(启用)
• relay_log_recovery
  • 当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该功能，建议开启
• sync_relay_log
  • 当设置为1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay log中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量I/O
  • 当设置为0时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘I/O操作。这个值默认是0，可动态修改
• sync_relay_log_info
  • 这个参数和 sync_relay_log 参数一样

1.7 审计日志

内容：企业版自带功能，社区版需使用audit审计插件完成数据库审计工作

开启步骤：

• 下载插件：https://github.com/mcafee/mysql-audit

• 查看插件功能是否开启： show variables like "%audit%";

• 开启插件功能：set global audit_json_file=1;

  注意，使用此方法开启对global全局变量的设置仅对于新开启的会话才是有效的，对已经开启的会话不生效，参数最终需持久化到my.cnf配置文件中

• 开启后，在MySQL数据目录下会多出一个mysql-audit.json审计日志

2 InnoDB日志

2.1 重做日志 (Redo Log)

文件：默认情况下，对应的物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2

内容：物理日志，记录物理数据页面的修改信息，redo log顺序写入redo log file物理文件中

重做日志有一个缓冲区Innodb_log_buffer，InnoDB优先将重做日志写入缓冲区，日志写盘通常有三种方式：

• Master Thread 每秒一次执行刷新Innodb_log_buffer到重做日志文件

• 每个事务提交时会将重做日志刷新到重做日志文件。

• 当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件

因此，重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始逐步开始的，这可以很好地解释再大的事务的提交（commit）的时间也是很短暂的

事务产生的重做日志，通过innodb_flush_log_at_trx_commit参数控制：

• 设置为 0 的时候，表示不写入buffer，直接每秒写入到redo file中，但mysql 崩溃会丢失1s数据
• 设置为 1 的时候，表示每次事务提交时都将 redo log 直接持久化到磁盘
• 设置为 2 的时候，表示每次事务提交时都只是把 redo log 写到 page cache，由OS处理回写磁盘操作，OS宕机会丢失数据

2.2 回滚日志(Undo Log)

文件：逻辑日志，记录在表空间中

• MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中

• MySQL5.6之后，undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo log文件的个数

内容：记录数据的逻辑变化，一条INSERT会对应一条DELETE的undo log，发生错误时能够恢复到事务之前的数据状态

undo log是MVCC(多版本并发控制)实现的关键