MySQL日志文件

Mysql日志文件
重做日志（redo log）、
回滚日志（undo log）、
二进制日志（binlog）、
错误日志（errorlog）、
慢查询日志（slow query log）、
一般查询日志（general log）
中继日志（relay log）

一、重做日志（redo log）
redo日志的作用一句话概括就是：保证事务的持久性
重做日志是一种基于磁盘的数据结构，因为REDO日志会在磁盘的相应位置产生记录。
它的主要作用在于在崩溃恢复期间纠正不完整事务写入的数据。 在正常操作期间，重做日志对由 SQL 语句或低级 API 调用产生的更改表数据的请求进行记录。
在初始化期间和接受连接之前，会自动重做在意外关闭之前未完成更新数据文件的修改。

redo log可以简单分为以下两个部分：
一是内存中重做日志缓冲 (redo log buffer),是易失的，在内存中
二是重做日志文件 (redo log file)，是持久的，保存在磁盘

什么时候写redo?
在数据页修改完成之后，在脏页刷到磁盘之前，先写入redo日志。注意的是先修改数据（数据在内存中的变化，并提交），后写日志（提交后把日志写会到磁盘里）。
但是这里需要注意的是，在未提交（commit）前，redo日志在内存的日志缓冲区中，并没有写回到磁盘上。

什么时候释放?
当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

关于文件的大小和数量，由一下两个参数配置
innodb_log_file_size 重做日志文件的大小。
innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认1

redo日志空间管理
Redo log文件以ib_logfile[number]命名，Redo log 以顺序的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。

MYSQL 8.0归档日志
在MySQL中，redo log是一个文件组，一般是3个文件，循环写入，写满的时候会做redo log层面的checkpoint，然后覆盖之前的redo log；而binlog是有归档功能的，每个binlog写满之后，都会重新开启下一个binlog开始写入，这也是为什么可以使用binlog来进行数据恢复的一个原因，就是因为它的归档功能。

MySQL8.0.17中引入了redo log的归档功能，如果我们开启归档功能，redo log会持续不断的生成，而不会覆盖掉之前的redo log。这个功能主要在哪种场景下应用呢？
试想这样一种情况，在对一个高并发的数据库进行备份的时候，备份速度很慢而redo log生成的速度很快，备份的速度跟不上redo log的生成速度，导致redo log被覆盖了，此时备份的一致性就无法得到保证了。有了redo log的归档功能，就可以在备份启动的时候同步启动redo log 归档，而在备份结束的时候同步停止redo log归档，这样就可以避免这个备份的问题了。备份结束之后，依旧可以利用这个期间产生的redo log进行数据恢复。

先检查一下是否开启了归档：
使用show variables like ‘%archive%’;
redo log的归档路径有如下限制：
(1)、目录必须存在，而且其他用户不可访问，最好是700的权限模式
(2)、该用户目录不能和datadir、innodb_tmpdir、以及其他mysqld的运行目录重合，需要单独创建

1.首先在系统下创建一个目录，并且赋予相关权限
[root@mysql80 ~]# mkdir /var/mysql_arch
[root@mysql80 ~]# chown -R mysql.mysql /var/mysql_arch
[root@mysql80 ~]# chmod 700 /var/mysql_arch
2.MYSQL数据库中设置相关参数。
（1） set global innodb_redo_log_archive_dirs=‘tmp_redo_dir:/var/mysql_arch’ ;
（2）生成归档测试：
do innodb_redo_log_archive_start('tmp_redo_dir‘);
检查归档是否生成：
关闭归档就一句话：do innodb_redo_log_archive_stop();

二、回滚日志（undo log）
undo日志用来保证事务的原子性以及innodb的mvcc(多版本并发控制)

undo数据是:事务行为的记录、每次更改数据的前镜像（旧数据）记录、至少保留到事务结束
用于支持:回滚操作、MVCC机制的重要保障、在实例的恢复时起到重要作用

内容：逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。

undo log的写入时机？
undo是在事务开始之前保存的被修改数据的一个版本，产生undo日志的时候，同样会伴随类似于保护事务持久化机制的redolog的产生。

undo什么时候释放？
事务提交之后，undo log并不能立刻被删除，而是放入待清理的链表，由purge线程判断是否有其他事务在使用undo段中的上一个事务之前的版本信息，再决定是否可以清理UNDO段的空间。
如果事务 rollback，innodb 通过执行 undo log 中的所有反向操作，实现事务中所有操作的回滚，随后就会删除该事务关联的所有undo段。

undo文件
默认情况下undo文件是保存在共享表空间的，即ibdatafile文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的undo信息，全部保存在共享表空间中。
因此共享表空间可能会变的很大，默认情况下，也就是undo 日志使用共享表空间的时候，被“撑大”的共享表空间是不会也不能自动收缩的。
因此，mysql5.7之后的“独立undo 表空间”的配置就显得很有必要了。
MYSQL 8.0已经把UNDO表空间给独立出来了，不需要我们再进行额外操作了。

三、二进制日志（binlog）
用来记录操作MySQL数据库中的写入性操作（增删改，但不包括查询）
MySQL 的二进制日志（binary log）是一个二进制文件，主要用于记录修改数据或有可能引起数据变更的 SQL 语句。
二进制日志（binary log）中记录了对 MySQL 数据库执行更改的所有操作，并且记录了语句发生时间、执行时长、操作数据等其它额外信息，
但是它不记录 SELECT、SHOW 等那些不修改数据的 SQL 语句。二进制日志（binary log）主要用于数据库恢复和主从复制，以及审计（audit）操作
二进制日志（Binary log） 的操作语句
/删除所有二进制日志文件：/
reset master
reset slave

/删除部分二进制日志文件：/
purge master logs to/befor ‘args’;
例如：
PURGE MASTER LOGS TO ‘mysql-bin.010’;
PURGE MASTER LOGS BEFORE ‘2021-06-02 22:46:26’;

/查看是否启用二进制日志：/
show variables like ‘%log_bin%’;

/查看所有的二进制日志参数/
show variables like ‘%binlog%’;

/查看文件的位置/
show variables like ‘%datadir%’;

/查看当前服务器所有的二进制日志文件/
show binary logs;
show master logs;

四、错误日志（errorlog）
启动、运行或停止 mysqld 时遇到的问题
MySQL 错误日志记录 MySQL 运行过程中较为严重的警告和错误信息，以及 MySQL 每次启动和关闭的详细信息。
MySQL 错误日志默认是开启的。可以通过 MySQL 配置文件中的 log-error=/var/log/mysqld.log 配置，修改错误日志的配置信息。
可以通过如下 SQL 查看错误日志的详细信息：
show variables like ‘%log_err%’;

五、慢查询日志（slow query log）
执行时间超过 long_query_time 秒的查询
记录所有执行时间超过 long_query_time 秒的查询 SQL 或者没有使用索引的查询 SQL，默认情况下，MySQL 不开启慢查询日志，
long_query_time值查询语句： show variables like ‘long_query_time’;
long_query_time值修改语句： set long_query_time = 秒数;

/查看当前慢查询日志的开启情况：/
show variables like ‘%query%’;

slow_query_log：ON 表示开启慢查询日志，OFF 表示关闭慢查询日志
slow_query_log_file：记录慢查询日志的文件地址（默认为主机名.log）
long_query_time：指定了慢查询的阈值，单位是秒，即执行语句的时间若超过这个值则为慢查询语句
log_queries_not_using_indexes：ON 表示会记录所有没有利用索引来进行查询的语句，前提是 slow_query_log 的值也是 ON，否则，不会奏效，OFF 表示不会记录所有没有利用索引来进行查询的语句。

六、一般查询日志（general log）
从已建立的客户端连接收到的语句
记录已连接MYSQL数据库的客户端所执行的语句。

可以通过如下 SQL 查看当前的通用日志是否开启：
SHOW VARIABLES LIKE ‘%general%’;
开启通用查询日志：
set global general_log = on;
关闭通用查询日志：
set global general_log = off;

七、中继日志（relay log）
从复制源服务器收到的数据更改
当日志时间和系统时间不一致时的处理方式
在MySQL 5.7.2 新增了 log_timestamps 这个参数，该参数主要是控制 error log、 General query log 等记录日志的显示时间参数，并且数据库安装后这些日志时间戳默认为UTC，因此会造成与系统时间不一致，与北京时间相差8个小时
查看当前日志时间戳：
SHOW GLOBAL VARIABLES LIKE ‘log_timestamps’；
因为log_timestamps 是一个GLOBAL的全局参数,所以直接在登录后去set全局参数,重启后就会直接失效因此需要在mysql的配置文件中[mysqld]中增加一条：
log_timestamps=SYSTEM
并且重启MYSQL后生效。

补充：数据文件
获取硬盘中数据存储的位置：
SHOW VARIABLES LIKE ‘datadir’;

db.opt 文件
该文件记录这个库的默认使用的字符集和校验规则，文件存放在所属数据库的目录下。

FRM 文件
不论使用什么存储引擎，每一张表都会有一个以表名命名的 .frm 文件，与表相关的元数据（meta）信息都存放在此文件中，包括表结构的定义信息等，文件存放在所属数据库的目录下。

MYD 文件
MyISAM 存储引擎专用，存放 MyISAM 表的数据（data)。每一张 MyISAM 表都会有一个 .MYD 文件，文件存放在所属数据库的目录下。

MYI 文件
也是 MyISAM 存储引擎专用，存放 MyISAM 表的索引相关信息。每一张 MyISAM 表对应一个 .MYI 文件，文件存放在所属数据库的目录下。

IBD 文件和 IBDATA 文件 :
存放 InnoDB 的数据文件（包括索引）。InnoDB 存储引擎有两种表空间方式：独享表空间和共享表空间。

独享表空间：使用 .ibd 文件来存放数据，且每一张 InnoDB 表对应一个 .ibd 文件，文件存放在所属数据库的目录下。

共享表空间：使用 ibdata 文件，所有表共同使用一个（或多个，自行配置）ibdata 文件。

ibdata1 ibdata n文件
系统表空间（数据文件）undo 段，文件存放在 datadir 目录下。

ib_logfile0、ib_logfile1 文件
redlog 文件，文件存放在 datadir 目录下。

pid 文件是 mysqld 应用程序在 Unix/Linux 环境下的一个进程文件，和许多其他 Unix/Linux 服务端程序一样，它存放着自己的进程 id。

socket 文件也是在 Unix/Linux 环境下才有的，用户在 Unix/Linux 环境下客户端连接可以不通过 TCP/IP 网络而直接使用 Unix Socket 来连接 MySQL。