MySQL各类日志文件相关变量介绍

文章转自:http://www.ywnds.com/?p=3721

MySQL各类日志文件相关变量介绍

查询所有日志的变量

GLOBAL表示查全局系统变量的状态值(大概有61变量左右)。

一、错误日志

log_error=/var/log/mysqld.log

错误日志的存放位置,MySQL 5.5在数据目录下,MySQL 5.6在/var/log/mysql.log文件

log_warnings=1

设定是否将警告信息记录进错误日志。默认设定为1,表示启用;可以将其设置为0以禁用;而其值为大于1的数值时表示将新发起连接时产生的“失败的连接”和“拒绝访问”类的错误信息也记录进错误日志。

二、通用日志

general_log=OFF

一般查询日志,默认关闭,在启动mysqld时可以使用了–general_log选项开启一般查询。如若启用此项,其输出位置则由–log_output选项进行定义,如果log_output的值设定为NONE,即使用启用查询日志,其也不会记录任何日志信息。作用范围为全局,可用于配置文件,属动态变量

general_log_file=FILE_NAME

查询日志的日志文件名称,默认为“localhost.log”。作用范围为全局,可用于配置文件,属动态变量。

log=YES

是否启用记录所有语句的日志信息于一般查询日志(general query log)中,默认通常为OFF。MySQL 5.6已经弃用此选项。

三、慢查询日志

slow_query_log = OFF

默认值为OFF,是否记录慢查询日志,慢查询是指查询的执行时间超出long_query_time参数所设定时长的事件。MySQL 5.5此参数为log_slow_queries={YES|NO},作用范围为全局级别,可用于配置文件,属动态变量。

log_output=FILE|TABLE|NONE

定义日志输出方式,默认是FILE。作用于查询日志和慢查询日志,属于动态变量可在线修改。如果改为TABLE存放,那么会在mysql架构的产生一个general_log和slow_log的表,此表默认使用的是CSV引擎。最好可以将次引擎改为MyISAM,但是必须在关闭慢查询之后才可修改。

slow_query_log_file = / PATH/TO/localhost-slow.log

设定文件格式的慢查询日志的存储路径

long_query_time= 10.000000

设定区别慢查询与一般查询的语句执行时间长度,这里的语句执行时长为实际的执行时间,而非在CPU上的执行时长,因此,负载较重的服务器上更容易产生慢查询。其最小值为0,默认值为10秒,这里要注意的是,MySQL只记录大于10秒的SQL查询而等于或小于10秒的则不会记录。一条SQL语句运行0.5秒和0.05秒是非常不同的,前者可能已经进行了表扫,后者可能是走了索引。它也支持微秒级的解析度。作用范围为全局或会话级别,可用于配置文件,属动态变量。

log_queries_not_using_indexes=OFF

默认值为OFF,这个参数默认为OFF,当开启后,如果运行的SQL语句没有使用索引,则MySQL数据库同样会将这条SQL语句记录到慢查询日志文件中。

log_throttle_queries_not_using_indexes=0

默认值为0,这是MySQL5.6.5版本开始新增的一个变量,用来表示每分钟允许记录到slow log的且未使用索引的SQL语句次数。该值默认为0,表示没有限制。这个参数是防止生产环境下SQL语句没有使用索引而导致慢查询日志过大的问题。

log_slow_admin_statements=OFF

默认值为OFF,这个变量是在MySQL5.6.11中加入的,记录包括表管理语句,如更改表、分析表、表、创建索引、降索引、优化表和维修表。作用范围为全局变量,可用于配置文件,属于动态变量。

log_slow_slave_statements=OFF

默认值为OFF,这个变量是在MySQL5.6.11中加入的,当慢查询日志开启的时候,这个变量的开启可以设定复制从库记录主库超过long_query_time时间的查询日志。作用范围为全局变量,可用于配置文件,属于动态变量。

四、二进制日志

expire_logs_days=0

设定二进制日志的过期天数,超出此天数的二进制日志文件将被自动删除。默认为0,表示不启用过期自动删除功能。如果启用此功能,自动删除工作通常发生在MySQL启动时或FLUSH日志时。作用范围为全局,可用于配置文件,属动态变量

binlog-format={ROW|STATEMENT|MIXED}

这个参数影响了记录二进制日志的格式,值有ROW、STATEMENT、MIXED这三种,MySQL5.5默认为MIXED混杂模式(就是平时使用statement记录二进制日志,但是需要使用ROW时就会使用);MySQL 5.6已经改为基于STATEMENT 了。

log_slave_updates=OFF

默认值为OFF,用于设定复制场景中的从服务器是否将从主服务器收到的更新操作记录进本机的二进制日志中,本参数设定的生效需要在从服务器上启用二进制日志功能。默认不会将从master取得并执行的二进制日志写入自己的二进制日志文件中。

log_bin=ON

默认为ON,启用二进制日志记录功能,作用范围为全局级别,属于静态变量。

sql_log_bin=ON

默认值为ON,用于控制二进制日志信息是否记录进日志文件,前提要开启二进制日志功能。作用范围为会话变量,属于动态变量。

max_binlog_size = 1073741824

默认为1G,指定单个二进制日志文件的最大值,如果超过该值,则产生新的二进制文件,后缀名+1,并记录到.index文件中。默认为1G,也可以手动刷新该文件。

sync_binlog=0

默认值为0,在默认情况下,二进制日志并不是在每次写的时候同步到磁盘,它会进行缓冲写。因此,当数据库所在操作系统发生宕机时,可能会有最后一部分数据没有写入二进制日志文件中。此参数表示每次缓冲多少次就同步到磁盘,1表示采用同步写磁盘的方式来写二进制日志,这时写操作不适用操作系统的缓冲来写二进制日志,会带来一定的性能下降。该值默认为0,表示采取缓冲写,性能好。

但是,将sync_binlog设为1时,又有一种情况会导致问题的发生。当使用InnoDB存储引擎时,在一个事务发出COMMIT动作之前,由于sync_binlog设为1,因此会讲二进制日志立即写入磁盘。如果这个时候已经写入了二进制日志,但是提交还没有发生,并且此时发送了宕机,那么在MySQL数据库下次启动时,因为COMMIT操作并没有发生,所以这个事物会被回滚掉。但是二进制日志以及记录了该事物信息,不能被回滚。这个问题可以通过参数innodb_support_xa设为1来解决,虽然innodb_support_xa与XA事务有关,但它同时也确保了二进制日志和innodb存储引擎数据文件的同步。

log_bin_trust_function_creators=OFF

默认值为OFF,此参数仅在启用二进制日志时有效,用于控制创建存储函数时如果会导致不安全的事件记录二进制日志条件下是否禁止创建存储函数。默认值为0,表示除非用户除了CREATE ROUTING或ALTER ROUTINE权限外还有SUPER权限,否则将禁止创建或修改存储函数,同时,还要求在创建函数时必需为之使用DETERMINISTIC属性,再不然就是附带READS SQL DATA或NO SQL属性。设置其值为1时则不启用这些限制。作用范围为全局级别,可用于配置文件,属动态变量

binlog_cache_size=32768

默认为32k,当使用事务引擎时,所有未提交的二进制日志会被记录到一个缓存中去,而该缓冲的大小有此参数控制。此值不能设置过大,当然也不能过小,不然当一个事务的记录大于设定的binglog_cahce_size时,MySQL会把缓冲中的日志写入一个临时文件中。通过SHOW GLOBAL STATUS命令查看binlog_cache_use(记录使用缓冲写二进制日志的次数)、binglog_cahce_disk_use(记录使用临时文件写二进制日志的次数)的状态,可以判断当前binlog_cache_size的设置是否适合。

max_binlog_cache_size = 18446744073709547520

二进制日志语句缓存大小,字节为单位。表示的是binlog能够使用的最大cache内存大小

当我们执行多语句事务的时候所有的会话的使用的内存超过max_binlog_cache_size的值时

就会报错:“Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes ofstorage”。此值的大小跟内存中数据同步到磁盘上的时间有关,缓存越大性能越好数据丢失比例越大,缓存越小性能越低数据丢失比例越小。

binlog_stmt_cache_size=32768

默认值32k,这个变量决定举行非事务语句在事务期间发布的二进制日志缓存的大小。如果服务器支持任何事务存储引擎,如果服务器有二进制日志启用,则为每个客户端分配一个单独的二进制日志事务和语句缓存。如果你经常使用大型非事务语句在交易过程中,你可以增加缓存大小以获得更好的性能。可以通过查状态变量binlog_stmt_cache_use和binlog_stmt_cache_disk_use的值来判断32k是否够用。

max_binlog_stmt_cache_size = 18446744073709547520

如果非事务语句在事务需要超过多少字节的内存,服务器会生成一个错误。

binlog_rows_query_log_events

MySQL 5.7新增参数,默认关闭 ,可选打开,建议打开,还是比较有用的。可以看到二进制日志格式为row的情况下的sql语句,方便排查问题和恢复数据。

binlog_max_flush_queue_time

默认值为0,用来控制MySQL 5.6新增的BLGC(binary log group commit),就是二进制日志组提交中Flush阶段中等待的时间,即使之前的一组事务完成提交,当前一组的事务也不马上进入Sync阶段,而是至少需要等待一段时间,这样做的好处是group commit的事务数量更多,然而这也可能会导致事务的响应时间变慢。该参数默认为0表示不等待,且推荐设置依然为0。除非用户的MySQL数据库系统中有大量的连接(如100个连接),并且不断地在进行事务的写入或更新操作。(注:binlog_max_flush_queue_time在MySQL的5.7.9及之后版本不再生效)

binlog_group_commit_sync_delay=N

binlog_group_commit_sync_no_delay_count=N

MySQL 5.7.9版本后,binlog_max_flush_queue_time参数失效。新增,MySQL等待binlog_group_commit_sync_delay毫秒直到达到binlog_group_commit_sync_no_delay_count事务个数时,将进行一次组提交。

五、中继日志

relay_log = mysql-relay-bin

开启中继日志,这里的值时中继日志的基名。默认是库的名字是host_name-realy-bin,服务器在数据目录中写入文件,除非给出了一个具有领先绝对路径的文件制定一个不同的目录。服务器通过在基名中添加一个数字后缀来创建中继日志文件。

relay_log_index = mysql-relay-bin.index

用于中继日志索引文件的名称,默认名称是在数据目录host_name-relay-bin.index,哪里host_name是从服务器的名称。

relay_log_info_file = relay-log.info

该文件用于记录中继日志的文件和事件位置以及二进制的文件和事件位置。

relay_log_info_repository = FILE

这个变量决定中继日志的位置写入到一个文件(中继日志信息)或表(MySQL.slave_relay_log_info)。

relay_log_purge = ON

默认值为ON,启动自动清除中继日志。这是一个全局变量。

relay_log_recovery = OFF

默认值为OFF,当slave从库宕机后,假如relay-log损坏了,导致一部分中继日志没有处理,则自动放弃所有未执行的relay-log,并且重新从master上获取日志,这样就保证了relay-log的完整性。默认情况下该功能是关闭的,将relay_log_recovery的值设置为 1时,可在slave从库上开启该功能,建议开启。

relay_log_space_limit = 0

防止中继日志写满磁盘,这里设置中继日志最大限额。但此设置存在主库崩溃,从库中继日志不全的情况,不到万不得已,不推荐使用.

sync_relay_log = 10000

sync_relay_log_info = 10000

这个参数和sync_binlog是一样的,当设置为1时,slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区,然后刷入relay log中继日志里,这样是最安全的,因为在崩溃的时候,你最多会丢失一个事务,但会造成磁盘的大量I/O。当设置为0时,并不是马上就刷入中继日志里,而是由操作系统决定何时来写入,虽然安全性降低了,但减少了大量的磁盘I/O操作。这个值默认是0,可动态修改,建议采用默认值。

max_relay_log_size = 0

#设定从服务器上中继日志的体积上限,到达此限度时其会自动进行中继日志滚动。此参数值为0时,mysqld将使用max_binlog_size参数同时为二进制日志和中继日志设定日志文件体积上限。作用范围为全局级别,可用于配置文件,属动态变量

六、事务日志

事务日志也称为重做日志(redo log),关于redo相关的变量,在“InnoDB文件及变量”章节看。

原文地址:https://www.cnblogs.com/smail-bao/p/7644722.html