MySQL Server会将信息写入几种类型的日志文件中。日志会记录下与被Server处理的SQL语句相关的各种信息:
通用查询日志(general query log)记录了所有从客户端收到的语句。
二进制日志(binary log)记录了对数据进行了修改的语句。
慢查询日志(slow query log)记录了长时间执行的查询。
报错日志(error log)记录了关于MySQL Server启动,关闭和异常情况的诊断信息。
这些日志可用于服务状态的确定, 对奔溃后数据恢复,以及用于有帮助,同时也有助于定位运行很慢的查询。之后我们会简单描述下每种日志的启用。虽然它们都不是默认启用的, 但是z在启用后,你需要意识到(特别对于通用查询日志),它们的大小会增长很快。因此,你并不需要将它们都启用起来,尤其对一个很繁忙的数据库。以下是推荐的日志策略:
在你最初建立MySQL Server的时候,启用通用查询日志,二进制日志及慢查询日志。
在服务配置好且运行较流畅后,关闭通用查询日志以节约磁盘空间。
除了二进制日志外,其他所有日志都是以平文本的形式进行记录。平文日志便于程序或个人进行查看。对于慢查询日志,另一种打开方法是通过使用mysqldumpslow工具;它能对日志中的内容进行总结。如果需要查看二进制日志中的内容,可以使用mysqlbinlog工具。
除了将语句记录进二进制日志和慢查询日志中,Server还会将一些额外信息写入日志中。例如,在慢查询日志中,执行次数和哪个用户执行此语句等信息会被记录下来。如果需要隐藏额外信息,在服务启动时可以使用 --log-short-format项。
Server会产生一些诊断信息(通常会记录在报错日志中),并建立多种状态文件。之后的章节中我们会对这些文件进行说明。
3.7.1通用查询日志(General Query Log)
通用查询日志包含了从客户端连接和断开、每句Server收到的执行语句(不管最终处理成功与否)的相关记录。服务会将语句按照收到的先后顺序写入日志。日志可以帮助我们判断各类语句的使用频繁度或通过那些未记录到其它日志中的语句进行问题分析。这些日志信息可以被写入日志文件中,也可以被写入数据库mysql下的general_log表中。
注意:如果你的应用非常繁忙,使用通用查询日志(General Query Log)可能导致很快磁盘空间被耗尽,并使得服务不能再写入数据(如果你设置的日志和数据文件或二进制日志存放在相同磁盘分区中)。因此,通用查询日志仅推荐在为了解决问题时才打开。
为了启用通用查询日志,你需要设置 --general-log=ON,并设置 --general-log-file项。如果general-log-file没有设置,默认文件名为host_name.log,host_name为主机名。默认情况下,除非你已经指定一个绝对路径,否则MySQL Server会在数据目录中建立通用查询日志。
3.7.2二进制日志
二进制日志包含了对数据进行修改的语句记录。例如,Server会对UPDATE和DELETE语句进行记录,但不会记录SELECT语句。语句仅在被执行后才会被写入二进制日志中。一个多语句事务中的语句在事务被确认(commit)后会以一组语句的形式被写入二进制日志中。
日志以二进制形式存储,但你可以通过使用mysqlbinlog工具对其进行查看。二进制日志被用于主从复制数据库之间的交流。此文件也可用于数据恢复。它有三种模式:statement, row和mixed。
3.7.3慢查询日志
慢查询日志记录了长时间运行的查询及其执行状态信息。默认情况下,“长时间”一般指超过10秒的查询,不过你也可以通过设置long_query_time变量来进行设置。由于无法确定执行时间,所以服务会在查询完成后进行记录。慢查询日志中的内容可以帮助我们确认哪些查询需要进行优化。
为了启用慢查询日志,使用 --slow-query-log或 --slow-query-log-file=file_name项。如果文件名为指定,默认名为host_name-slow.log,host_name为服务器主机名。除非你指定了文件绝对路径,否则默认情况下,慢查询日志文件将在数据目录下建立。
为了进一步记录那些未使用到索引的查询,你可以使用 --log-queries-not-using-indexes项。
现在服务的日志存放变得很灵活,你可以选择将日志信息存放在文件中,也可以将它们写入数据库mysql下的general_log和slow_log表中。如果你启用了这些日志,你可以通过设置 –log-output
来设置日志存放的形式。
3.7.4报错日志(error log)
MySQL Server会对正常的启动关闭和异常情况生成可用于诊断的信息:
在Windows上,服务会打开报错日志,并在数据目录中生成error日志文件。如果你在使用命令行启动服务程序时使用 --console项,则程序会将报错信息直接输出到命令行窗口中,而不会记录在报错日志中。
在Unix/Linux上,如果你直接调用mysqld,它会将诊断信息输出到标准报错输出,即你的命令行窗口(terminal)中。你可以使用 --log-error=file_name项启动Server来将报错记录到指定文件中。不过,通常我们会调用mysqld_safe脚本(mysql.server也会调用mysqld_safe)来进行启动。mysqld_safe会建立报错日志文件并在启动数据库时,将Server的输出重定向到其指定的报错日志上。(因此, Server会在报错日志中写报错信息,但是其本身不会直接建立日志文件。)默认的日志文件为host_name.err且会被放在数据目录中。
mysql_safe本身也会在报错日志中写信息。如果它发现服务挂了,它会自动重启服务,并在日志中写mysqld restarted。
报错日志中的内容对解决服务操作问题很有用。除了启动和关闭中服务碰到的问题外,还会记录由其他信息:
未能确认的启动项。如果Server尝试启动但很快就启动失败,报错日志会告诉你为什么。当Server在启动初始阶段失败,它会将信息写入报错日志中。通常碰到的原因是配置错误。如,你可能在配置文件中加入了错误的配置项。
服务打开网络接口失败:这里指TCP/IP端口,Windows命名管道,Windows共享内存(shared memory),或Unix socket文件。Server不能使用那些已经在被其它服务所使用的接口。
存储引擎初始化失败。这可能是由不正确的存储引擎设置造成(如,当一个文件被设置成InnoDB表空间的一部分而无法打开),或探测到某种情况不可能持续下去(如,当存储引擎探测到表损坏且不能被自动修正时)。
未能找到SSL认证或服务启动项中所指定的key文件。
Server无法切换到Unix上指定的用户ID。当你在启动时对 --user项进行了设置,这中情况就可能发生。如果你使用的是root账号进行的启动,那么root权限下则能切换到其指定的账号而不会出现此问题。
和复制(Replication)有关的问题。
3.7.5状态文件
MySQL Server会生成一些状态文件。其中一些的位置默认在数据目录中,但不是全部。
Server会将它的进程ID记录在一个PID文件中,在被其它程序用于向服务发送信号时使用。例如,在Unix上,进程互相之间发送信号时会使用到进程ID。mysql_safe就是一个使用这种方法通信的程序。它会查看PID文件中的服务进程ID,然后尝试向服务端发送信号以检查其是否在运行。
默认PID文件为host_name.pid且放置在数据目录中。你也可以通过 --pid-file=file_name项来改变PID文件名和文件位置。
在Unix上,MySQL Server通过建立Unix socket文件来使得本地客户端可以通过socket建立连接。默认情况下,文件为/tmp/mysql.sock。当然你也可以使用 --socket配置项在启动Server时对文件名和位置进行指定。如果你改变了位置,你同样需要客户端程序在被使用时对其的 --socket项进行设置,以使其知道socket文件的位置。