mysql8错误⽇志_MySQL8服务器⽇志
错误⽇志：
启动、运⾏、停⽌ 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不适⽤复制环境，或者不需要做时间点恢复的话，可以不⽤开启⼆进制⽇志
与⼆进制⽇志相关系统变量：
下载mysql服务端命令
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只同时刷新通⽤⽇志⽂件、慢查询⽇志⽂件、错误⽇志⽂件

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。