MySQL各种日志介绍-优快云博客

binlog
Redo log
Undo log
Error Log
Relay Log

binlog

记录所有DDL和DML语句（记录修改的细节），但不包括查询和无修改数据的操作
相关参数：log_bin(=1启用)、max_binlog_size(最大大小)、binlog_format(格式，一般设置为row)、expire_logs_days(过期时间，过期会自动删除)

Redo log

重做日志，存储引擎InnoDB生成的日志，记录“物理级别”上的页修改操作。
默认一个日志文件组，2个日志文件 ib_logifile0和ib_logfile1，大小一样。如果ib_logifile0写慢了，就接着写ib_logifile1，循环使用
总日志大小不能大于最大值512G，总日志大小=innodb_log_files_in_group * innodb_log_file_size
        InnoDB引擎的事务采用WAL技术，先写日志，再写磁盘，这个日志就是Redo Log。当发生宕机且数据未刷到磁盘，可以通过Redo Log恢复。
每次事务提交时只把修改了那些东西记录到磁盘，并不刷新内存中修改过的所有页面到磁盘。
        比如，某个事务将系统表空间中第10号页面中偏移量为 100 处的那个字节的值 1 改成 2 。
只需要记录：将第0号表空间的10号页面的偏移量为 100 处的值更新为 2 。*
优点：1、Redo Log降低刷盘频率
2、Redo Log 占用空间非常小
特点：顺序写入磁盘，效率比随机IO快
**Binlog是数据库层产生的。**
*假设一个事务，对表做10万行的记录插入，在这个过程中，一直不断的往Redo Log顺序记录，而 Binlog 不会记录，直到这个事务提交，才会一次写入到 Binlog 文件中。*
当事务COMMIT时，将Redo Log Buffer中的内容刷新到Redo Log File，追加写，定期将内存中修改的数据刷新到磁盘（随机IO）

---触发Redo Log写文件的场景：

Redo Log Buffer空间不足时（占用空间一半时后台线程会主动刷盘）
事务提交
后台线程
做checkpoint
实例shutdown时
binlog切换时

刷盘控制参数innodb_flush_log_at_trx_commit ，默认值1，每次事务提交都fsync，最安全，即使宕机也不会丢失事务（高峰期可临时改为2以应对大负载）

InnoDB有一个后台线程，每隔1秒会把Redo Log Buffer中的内容写到文件系统缓存page cache，然后调用刷盘操作（即没有提交事务的Redo Log记录也可能会刷盘）

日志时间参数 log_timestamps
在5.7.2之后新增的参数，默认UTC，比北京时间慢8小时
show variables like 'log_timestamps';
修改

--v5.7
set global log_timestamps=system;  
同时修改配置文件 
[mysqld]
log_timestamps=system

--8.0 支持参数持久化设置
set global log_timestamps=system;

Undo log

回滚日志，存储引擎InnoDB生成的日志，逻辑操作日志（比如对某一行数据进行了insert操作，那么Undo log记录一条与之相反的delete操作）

Error Log

        主要记录MySQL服务器启动和停止过程中的信息、服务器在运行过程中发生的故障和异常情况等。
        错误日志功能是默认开启，无法被禁止
        以文本文件形式存储，可使用文本编辑器直接查看
        错误日志默认存储在数据目录下，名称mysqld.log（Linux系统）或hostname.err（mac系统）。可在my.cnf或者my.ini中制定文件名：
[mysqld]
log-error=[path/[filename]]
修改配置项后重启MySQL服务生效。查看路径 show variables like 'log_err%';
        删除：很久以前的错误日志可直接删除
        刷新：mysqladmin -uroot -p flush-logs
MySQL 5.5.7以前的版本，flush-logs将错误日志文件重命名为filename.err_old,并创建新的日志文件。
从MySQL 5.5.7开始，flush-logs只是重新打开日志文件，并不做日志备份和创建的操作。
如果日志文件不存在，MySQL启动或者执行flush-logs时会自动创建新的日志文件。重新创建错误日志，大小为0字节。

Relay Log

中继日志（relay log）只存在于主从架构的从服务器上。默认会保存在从服务器的数据目录下。
文件名的格式是：从服务器名 - relay-bin.序号。
中继日志还有一个索引文件：从服务器名 - relay-bin.index，用来定位当前正在使用的中继日志。

主从复制原理图

从服务器I/O线程读取主服务器的二进制日志(binlog)记录到从服务器本地，然后从服务器SQL线程会读取中继日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。
I/O线程将来自master的binlog存储到中继日志中，中继日志充当缓冲，这样master不必等待slave执行完成就可以发送下一个binlog。

**查看中继日志**
中继日志文件的格式与二进制日志文件相同，并且可以使用mysqlbinlog进行读取。

这一段的意思是，主服务器（"server id 1"）对表kaito.test进行了2步操作，
定位到表kaito.test编号是91的记录，日志位置是832。删除编号是91的记录，日志位置是872。
**相关参数解析**
通过语句：show variables like '%relay%'查看relay所有相关参数如下，

max_relay_log_size：标记relay log允许的最大值，如果该值为0，则默认值为max_binlog_size(1G)；如果不为0，则max_relay_log_size则为最大的relay_log文件大小。
relay_log：定义relay_log的位置和名称，如果值为空，则默认位置在数据文件的目录（datadir），文件名默认为host_name-relay-bin.nnnnnn。
relay_log_purge：是否自动清空不再需要中继日志时。默认值为1(启用)。
relay_log_recovery：当slave从库宕机后，假如relay-log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log，并且重新从master上获取日志，这样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为1时，可在slave从库上开启该功能，建议开启。
relay_log_space_limit：防止中继日志写满磁盘，这里设置中继日志最大限额。注意，但此设置存在主库崩溃，从库中继日志不全的情况，不到万不得已，**不推荐使用**！
sync_relay_log：同sync_binlog，当设置为1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，然后刷入relay log中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量I/O。当设置为0时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘I/O操作。这个值**默认是0**，可动态修改，建议**采用默认值**。

删除Relay Log文件

IO Thread负责写入完Relay Log之后，判断当前文件是否超过max_relay_log_size 如果超过则自动生成一个新的relay-log-file。
SQL Thread每执行完一个events时判断，如果该Relay Log已经不再需要则自动删除Relay Log文件。目前除了这个，没有明确的机制。
由SQL Thread负责清除Relay Log
开启relay_log_purge时，不需要人工清理Relay Log。
人工清理：从库上 reset slave 和 reset slave all
如果SQL Thread 太繁忙可能导致Relay Log无法及时清除

General Query Log

        通用查询日志。记录用户的所有操作，包括启动和关闭MySQL服务、所有用户的连接开始时间和截止时间、发给MySQL数据库服务器的所有SQL指令等。默认OFF
        以文本文件的形式存储在文件系统中
        SHOW VARIABLES LIKE '%general%';
启动日志

方法1：修改my.cnf或者my.ini配置文件启动日志
[mysqld]
general_log=ON
general_log_file=[path[filename]]   --不指定时，存储存数据目录中
方法2：
set global general_log=on;
set global general_log_file='path/filename';

停止日志
修改配置文件重启服务 general_log=OFF
或者 set global general_log=off;

部分转自 [KAiTO 的文章]