mysql8 错误日志_MySQL 8 服务器日志

错误日志：

启动、运行、停止 mysqld(MySQL Server) 遇到的问题

通用查询日志：

建立客户端连接和从客户端接收的语句

二进制日志：

更改数据的语句(也用于复制)

中继日志：

从复制master server接收到的数据更改

慢查询日志：

执行查询超过long_query_time 系统变量指定的秒数

DDL日志(元数据日志)：

DDL语句执行的元数据操作

通过刷新日志可以强制服务器关闭并重新打开日志文件(有时还会生成一个新的日志文件)

刷新日志文件方法：

mysql> flush logs;

mysql> mysqladmin flush-logs

mysql> mysqladmin refresh

shell> mysqldump --flush-logs

此外，当二进制日志的大小达到 max_binlog_size 系统变量设置也会刷新该日志

注：官档中提到 mysqldump 的 --master-data 选项也可会刷新日志，测试发现不能

通用查询日志和慢查询日志的一些说明：

log_output 系统变量：控制通用查询日志和慢查询日志输出目标位置，可选值包括：TABLE，FILE，NONE；这些值可以任意组合，NONE的优先级最高

如果将设置log_output='table'，则通用查询日志文件、慢查询日志文件中只会保存系统启动信息

general_log 系统变量：控制是否启用通用日志

general_log_file 系统变量：控制通用日志文件

slow_query_log 系统变量：控制是否启用慢查询日志

slow_query_log_file 系统变量：控制慢查询日志文件

注：如果将通用查询日志和慢查询日志存放在TABLE中，可以通过查询mysql schema下的general_log表以及slow_log表获取日志内容

关于日志表的一些补充：

写到日志表中的条目不会写到二进制日志文件中，所以也不会复制到 SLAVE Server

关于日志表清理方法：可以通过TRUNCAET TABLE语句清理，或者通过一个轮询的方式，比如：

mysql > user mysql;

mysql> create table general_log2 like general_Log;

mysql> drop table general_log to gerneral_log_backup, gerneral_logs2 to general_log;

通过mysqldump命令只会dump日志表的定义，不会dump日志表中的数据，这样在恢复时，可以保证恢复日志表结构

如果日志写到文件当中，可以通过如下方式清理日志文件：

shell> mv host_name.log host_name-old.log

shell> mysqladmin flush-logs

shell> mv host_name-old.log backup-directory

也可以通过一种通用方式处理：

SET GLOBAL general_log = 'OFF';

shell> mv host_name.log host_name-old.log

SET GLOBAL general_log = 'ON';

在会话级启停通用查询日志，可以通过 sql_log_off 会话变量实现

写在通用查询日志中的密码会被重写，通过在MySQL Server启动时添加 --log-raw 选项密码不会重写，这在排查问题时可能有用，但是不安全，生成中不建议使用

log_timestamps 系统变量：

这个系统变量影响通用查询日志文件、慢查询日志文件、错误日志的显示时间戳，通过存储在日志表中的日志时间戳显示没有影响

log_timestamps 系统变量有两个取值：UTC、SYSTEM

错误日志：

错误日志包含：MySQL Server 启停时间信息，以及在启停和运行过程中的错误、警告、提示信息

如果使用mysqld_safe启用MySQL Server，在mysqld异常终止时，mysqld_safe会重启mysqld并把信息写到错误日志中

在MySQL 8.0 中，错误日志子系统有执行log event过滤以及写log event的组件和控制组件选择的系统变量组成

log_error 系统变量：指定错误日志位置

log_error_verbosity 系统变量：指定错误日志记录等级(0、1、2 分别对应 error、error warning、error warning note)

log_error_services 系统变量：指定过滤组件、写组件

二进制日志：

二进制日志包含描述数据库更改的 events，还包含每个更新语句花费的时间

二进制日志记录对数据库对象做出更改的语句，如果这个语句可能更改数据，比如：delete from table_name where 1=0;在二进制日志格式为STATEMENT时会记录到二进制日志文件中，而二进制日志格式为ROW时则不会记录到二进制日志文件中

二进制日志有两个重要作用：

复制

恢复

二进制日志会对系统产生一些额外的开销，如果MySQL Server不适用复制环境，或者不需要做时间点恢复的话，可以不用开启二进制日志

与二进制日志相关系统变量：

log_bin 系统变量：指定二进制日志的basename

log_slave_updates 系统变量：这个系统变量应用在Slave Server中，在Slave Server应用从Master Server接收的二进制events时，是否将应用的events写到Slave Server自身的二进制日志中

slave_preserve_commit_order 系统变量：这个系统变量也是在Slave Server中使用，而且是在多线程复制Slave Server才有意义

配置多线程复制Slave，设置 slave_parallel_workers 系统变量为非 0 值

可以将 slave_parallel_type 系统变量设置为 Logical Clock，这样对于Master Server端组提交的事务可以在Slave Server端并行化应用接收的events

二进制日志刷新的几种情形：

MySQL Server 启动

flush logs

日志文件大小达到max_binlog_size 系统变量定义的值

注：二进制日志文件大小可能会超过 max_binlog_size 指定的大小，比如：一个大事务写到日志文件，由于事务以 one piece 存储到日志文件中，不会在日志文件中分割

log_bin_index 系统变量：查看二进制日志文件索引文件位置

sql_log_bin 会话变量：可以在会话级关闭二进制日志生成

验证二进制日志完整性：

默认情况下，MySQL Server 会写events和events长度用于验证events是否正确写入

如果 binlog_checksum 系统变量启用，MySQL Server 还会写入events校验和

这样在从二进制日志读信息时，Master Server会使用events长度，以及校验和信息(如果配置了master_verify_checksum 系统变量)

在Slave Server端，IO线程会验证从Master Server端接收的events，如果Slave Server端配置了slave_sql_verify_checksum 系统变量，Slave Server的SQL线程也会验证校验和信息

在二进制日志中记录的events的格式取决于二进制日志的格式，二进制日志格式包括：STATEMENT、ROW、MIX-BASED

可以通过 RESET MASTER命令删除所有的二进制日志，或者通过 PURGE BINARY LOG语句删除部分二进制日志

补充说明一下：

在复制环境中，在Master Server端，RESET MASTER不仅会删除所有的二进制日志，如果使用的是基于GTID复制模式，也会清除所有的GTID信息；在Slave Server端，RESET SLAVE删除所有中继日志，RESET SLAVE ALL不仅会删除所有中继日志，而且会清除连接、状态信息，在MySQL 8 中，默认使用mysql.slave_relay_log_info、mysql.slave_master_info表存储有关信息

可以通过mysqlbinlog命令查看二进制日志内容，这是MySQL Server做时间点恢复会有用，比如：

shell> mysqlbinlog log_file | mysql -h server_name

对于事务表，在语句或者事务完成后，释放锁或者提交前，会立即记录在二进制日志中

对于非事务表，在语句执行后，就会立即记录在二进制日志中

在一个未提交的事务中，所有对支持事务表的更改，在Server未接收到提交之前会先进行缓存；提交后，在执行COMMIT前，MySQL Server将整个事务写到二进制日志中

当一个线程开始处理事务时，会分配一个binlog_cache_size 系统变量的buffer用于buffer事务语句，如果事务语句大于binlog_cache_size 指定的值，线程打开一个临时文件用于存储该事务

binlog_cache_use 状态变量：查看MySQL Server中使用binlog_cache这个buffer的事务数量(包括使用临时文件的事务)

binlog_cache_disk_use 状态变量：查看MySQL Server中使用临时文件的事务

通过这两个状态变量，可以来调整binlog_cache_size值

MySQL Server中还定义了一个系统变量 max_binlog_cache_size用来限制整个Server中所有线程能够使用的binlog buffer 大小

基于ROW格式的二进制日志，对于像CREATE ... SELECT 和 INSERT ... SELECT语句会将其转化为一般的INSERT语句，这对于binlog_cache_size有一定的影响

binlog_error_action 系统变量：控制在写、刷新、同步二进制日志时发生错误，MySQL Server所采取的动作，默认是：ABORT_SERVER，另外一个值是：IGNORE_ERROR，这个值用于向后兼容

sync_binlog 系统变量：控制通过二进制日志的频率，默认值 1，是最安全的，但也是最慢的，与其相关的另一个系统变量：innodb_flush_log_at_trx_commit，默认值也是 1

早期MySQL Server存在的一种情况：

使用InnoDB表，MySQL处理事务，在将事务写到二进制日志后，提交事务到InnoDB前，系统崩溃，重启后，InnoDB回滚该事务，但是事务相关的日志保留在二进制日志文件中

早期解决这种情况的方法是使用XA事务，使InnoDB支持事务的两阶段提交，MySQL Server会截断二进制日志到最后有效的位置

在MySQL 8.0以后总是启用XA事务的两阶段提交，保证InnoDB 表数据与二进制日志数据一致

如果MySQL Server在崩溃恢复时发现二进制日志比他应该的大小下的时候，它丢失了至少一个成功提交的事务；在这种情况下，二进制日志是不正确的，复制应该从Master Server 新的快照中开始；

这种情况不会发生，如果sync_binlog=1并且二进制日志真的同步到磁盘上(有时不会)

sync_binlog=1: Enables synchronization of the binary log to disk before transactions are committed. This is the safest setting but can have a negative impact on performance due to the increased number of disk writes. In the event of a power failure or operating system crash, transactions that are missing from the binary log are only in a prepared state. This permits the automatic recovery routine to roll back the transactions, which guarantees that no transaction is lost from the binary log.

二进制日志格式：

binlog_format 系统变量：可选值：STATEMENT、ROW、MIXED

基于MIXED的二进制日志格式默认使用基于STATEMENT二进制日志格式

在复制模式下，主从节点的binglog_format应该保持一致

在使用InnoDB存储引擎，同时事务隔离等级时READ-COMMITTED情况下，将BINLOG_FORMAT设置为STATEMENT，会导致InnoDB表不能插入数据

binlog_row_event_max_size 系统变量：

Where possible, rows stored in the binary log are grouped into events with a size not exceeding the value of this setting. If an event cannot be split, the maximum size can be exceeded.

慢查询日志：

The server uses the controlling parameters in the following order to determine whether to write a query to the slow query log:

1. The query must either not be an administrative statement, orlog_slow_admin_statements must be enabled.

2. The query must have taken at least long_query_time seconds, or log_queries_not_using_indexes must be enabled and the query used no indexes for row lookups.

3. The query must have examined at least min_examined_row_limit rows.

4. The query must not be suppressed according to the log_throttle_queries_not_using_indexes setting.

MySQL 8.0.14 版本之后在使用慢查询日志文件时，可以设置log_slow_extra 系统变量，会在慢查询日志文件中多出一些额外字段信息，

慢查询日志文件中的SET语句，指定一个时间戳，在MySQL 8.0.14版本之前是指语句写入日志文件的时间，在MySQL 8.0.14 版本之后指语句开始执行时间

DDL日志：

DDL日志是为了维护DDL操作的原子性，DDL日志会在需要时，生成在数据目录下：ddl_log.log

一般是不需要人为干预该日志文件，除非该日志文件达到上限，4G

Server 日志维护：

在Linux(RedHat)安装上，可以使用mysql-log-rotate脚本做日志维护

在其它系统上，可以通过cron调用脚本的方式做日志维护工作

binlog_expire_logs_seconds：控制二进制日志过期天数，默认是30天，删除过期二进制日志文件发生在Server 启动，或者刷新二进制日志文件；如果是在复制环境中使用该参数，注意该值不能小于Slave落后Master的最大时间

强制MySQL使用新的日志文件：FLUSH LOGS、MYSQLADMIN FLUSH-LOGS、MYSQLADMIN REFRESH、MYSQLDUMP --LFUSH-LOGS

FLUSH LOGS命令支持选择特定的待刷新的日志文件，比如：FLUSH BINARY LOGS

这样如果是要使用新的通用日志文件、慢查询日志文件、错误日志文件，在类-Unix平台上可以这样实现：

cd mysql-data-directory

mv mysql.log mysql.log.old

mv mysql-slow.logmysql-slow.log.old

mv err.log err.log.old

flush general logs;

flush slow logs;

flush error logs;

而不会对其他日志文件有影响

补充说明一下：

通过重命名日志文件的方式刷新日志文件，要注意MySQL Server要有新生成的日志文件目录的写入权限

通过FLUSH 命令刷新需要连接到MySQL Server，其实通过信号也可以刷新日志文件，在MySQL 8.0.19版本，可以通过SIGUSR1只同时刷新通用日志文件、慢查询日志文件、错误日志文件