简单,可复制

点点滴滴,尽在文中

  :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

日志文件类型

MySQL有几个不同的日志文件,可以帮助你找出mysqld内部发生的事情:

日志文件

记入文件中的信息类型

错误日志

记录启动、运行或停止mysqld时出现的问题。

查询日志

记录建立的客户端连接和执行的语句。

更新日志

记录更改数据的语句。不赞成使用该日志。

二进制日志

记录所有更改数据的语句。还用于复制。

慢日志

记录所有执行时间超过long_query_time秒的所有查询或不使用索引的查询。

 

 

 

 

 

 

 

 

 

 

默认情况下,所有日志创建于mysqld数据目录中。通过刷新日志,你可以强制 mysqld来关闭和重新打开日志文件(或者在某些情况下切换到一个新的日志)。当你执行一个FLUSH LOGS语句或执行mysqladmin flush-logsmysqladmin refresh时,出现日志刷新。

 

错误日志

错误日志文件包含了当mysqld启动和停止时,以及服务器在运行过程中发生任何严重错误时的相关信息。

如果mysqld莫名其妙地死掉并且mysqld_safe需要重新启动它,mysqld_safe在错误日志中写入一条restarted mysqld消息。如果mysqld注意到需要自动检查或着修复一个表,则错误日志中写入一条消息。

在一些操作系统中,如果mysqld死掉,错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld死掉的地方。

可以用--log-error[=file_name]选项来指定mysqld保存错误日志文件的位置。如果没有给定file_name值,mysqld使用错误日志名host_name.err 并在数据目录中写入日志文件。如果你执行FLUSH LOGS,错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项,则不会重新命名)

如果不指定--log-error,或者(Windows)如果你使用--console选项,错误被写入标准错误输出stderr。通常标准输出为你的终端。

 

通用查询日志

如果你想要知道mysqld内部发生了什么,你应该用--log[=file_name]-l [file_name]选项启动它。如果没有给定file_name的值, 默认名是host_name.log所有连接和语句被记录到日志文件。当你怀疑在客户端发生了错误并想确切地知道该客户端发送给mysqld的语句时,该日志可能非常有用

mysqld按照它接收的顺序记录语句到查询日志。这可能与执行的顺序不同。这与更新日志和二进制日志不同,它们在查询执行后,但是任何一个锁释放之前记录日志。(查询日志还包含所有语句,而二进制日志不包含只查询数据的语句)

服务器重新启动和日志刷新不会产生新的一般查询日志文件(尽管刷新关闭并重新打开一般查询日志文件)。在Unix中,你可以通过下面的命令重新命名文件并创建一个新文件:

shell> mv hostname.log hostname-old.log
shell> mysqladmin flush-logs
shell> cp hostname-old.log to-backup-directory
shell> rm hostname-old.log

 

慢速查询日志

--log-slow-queries[=file_name]选项启动时,mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。获得初使表锁定的时间不算作执行时间。

如果没有给出file_name值, 默认未主机名,后缀为-slow.log。如果给出了文件名,但不是绝对路径名,文件则写入数据目录。

语句执行完并且所有锁释放后记入慢查询日志。记录顺序可以与执行顺序不相同。

慢查询日志可以用来找到执行时间长的查询,可以用于优化。但是,检查又长又慢的查询日志会很困难。要想容易些,你可以使用mysqldumpslow命令获得日志中显示的查询摘要来处理慢查询日志。

MySQL 5.1的慢查询日志中,不使用索引的慢查询同使用索引的查询一样记录。要想防止不使用索引的慢查询记入慢查询日志,使用--log-short-format选项。

MySQL 5.1,通过--log-slow-admin-statements服务器选项,你可以请求将慢管理语句,例如OPTIMIZE TABLEANALYZE TABLE和 ALTER TABLE写入慢查询日志。

用查询缓存处理的查询不加到慢查询日志中,因为表有零行或一行而不能从索引中受益的查询也不写入慢查询日志。

 

二进制日志

二进制文件介绍

二进制日志以一种更有效的格式,并且是事务安全的方式包含更新日志中可用的所有信息。

二进制日志包含了所有更新了数据或者已经潜在更新了数据(例如,没有匹配任何行的一个DELETE)的所有语句。语句以“事件”的形式保存,它描述数据更改。

备注:二进制日志已经代替了老的更新日志,更新日志在MySQL 5.1中不再使用。

 

二进制文件的行为

二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果你想要记录所有语句(例如,为了识别有问题的查询),你应使用一般查询日志。

二进制日志的主要目的是在恢复使能够最大可能地更新数据库,因为二进制日志包含备份后进行的所有更新。

二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。

运行服务器时若启用二进制日志则性能大约慢1%。但是,二进制日志的好处,即用于恢复并允许设置复制超过了这个小小的性能损失。

 

二进制文件的文件路径

当用--log-bin[=file_name]选项启动时,mysqld写入包含所有更新数据的SQL命令的日志文件。如果未给出file_name值, 默认名为-bin后面所跟的主机名。如果给出了文件名,但没有包含路径,则文件被写入数据目录。建议指定一个文件名.

如果你在日志名中提供了扩展名(例如,--log-bin=file_name.extension),则扩展名被悄悄除掉并忽略。

mysqld在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size,还会自动创建新的二进制日志。如果你正使用大的事务,二进制日志还会超过max_binlog_size:事务全写入一个二进制日志中,绝对不要写入不同的二进制日志中。

为了能够知道还使用了哪个不同的二进制日志文件,mysqld还创建一个二进制日志索引文件,包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同,扩展名为'.index'。你可以用--log-bin-index[=file_name]选项更改二进制日志索引文件的文件名。当mysqld在运行时,不应手动编辑该文件;如果这样做将会使mysqld变得混乱。

 

二进制日志选项

可以使用下面的mysqld选项来影响记录到二进制日志知的内容。又见选项后面的讨论。

·         --binlog-do-db=db_name

告诉主服务器,如果当前的数据库(USE选定的数据库)db_name,应将更新记录到二进制日志中。其它所有没有明显指定的数据库  被忽略。如果使用该选项,你应确保只对当前的数据库进行更新。

对于CREATE DATABASEALTER DATABASEDROP DATABASE语句,有一个例外,即通过操作的数据库来决定是否应记录语句,而不是用当前的数据库。

一个不能按照期望执行的例子:如果用binlog-do-db=sales启动服务器,并且执行USE prices; UPDATE sales.january SET amount=amount+1000,该语句不写入二进制日志。

·         --binlog-ignore-db=db_name

告诉主服务器,如果当前的数据库(USE选定的数据库)db_name,不应将更新保存到二进制日志中。如果你使用该选项,你应确保只对当前的数据库进行更新。

一个不能按照你期望的执行的例子:如果服务器用binlog-ignore-db=sales启动,并且执行USE prices; UPDATE sales.january SET amount=amount+1000,该语句不写入二进制日志。

类似于--binlog-do-db,对于CREATE DATABASEALTER DATABASEDROP DATABASE语句,有一个例外,即通过操作的数据库来决定是否应记录语句,而不是用当前的数据库。

要想记录或忽视多个数据库,使用多个选项,为每个数据库指定相应的选项。

服务器根据下面的规则对选项进行评估,以便将更新记录到二进制日志中或忽视。请注意对于CREATE/ALTER/DROP DATABASE语句有一个例外。在这些情况下,根据以下规则,所创建、修改或删除的数据库将代替当前的数据库。

1.    是否有binlog-do-dbbinlog-ignore-db规则?

·         没有:将语句写入二进制日志并退出。

·         有:执行下一步。

2.    有一些规则(binlog-do-dbbinlog-ignore-db或二者都有)。当前有一个数据库(USE是否选择了数据库?)?

·         没有:不要写入语句,并退出。

·         有:执行下一步。

3.    有当前的数据库。是否有binlog-do-db规则?

·         有:当前的数据库是否匹配binlog-do-db规则?

o        有:写入语句并退出。

o        没有:不要写入语句,退出。

·         No:执行下一步。

4.    有一些binlog-ignore-db规则。当前的数据库是否匹配binlog-ignore-db规则?

·         有:不要写入语句,并退出。

·         没有:写入查询并退出。

例如,只用binlog-do-db=sales运行的服务器不将当前数据库不为sales的语句写入二进制日志(换句话说,binlog-do-db有时可以表示“忽视其它数据库)

如果你正进行复制,应确保没有从服务器在使用旧的二进制日志文件,方可删除它们。

posted on 2012-11-02 19:28  ggjucheng  阅读(7106)  评论(0编辑  收藏  举报