MySQL文件未保存退出_MySQL日志文件（转）

如果你想要知道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

在Windows

中，服务器打开日志文件期间你不能重新命名日志文件。你必须先停止服务器然后重新命名日志文件。然后，重启服务器来创建新的日志文件。

5.11.3. 二进制日志

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

二进制日志包含了所有更新了数据或者已经潜在更新了数据(例如，没有匹配任何行的一个DELETE

)的所有语句。语句以“事件

”的形式保存，它描述数据更改。

注

释：二进制日志已经代替了老的更新日志，更新日志在MySQL 5.1

中不再使用。

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

。

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

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

MySQL中的复制

。

运行服务器时若启用二进制日志则性能大约慢1%

。但是，二进制日志的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。

当用--log-bin[=file_name

]

选项启动时，mysqld

写入包含所有更新数据的SQL

命令的日志文件。如果未给出file_name

值， 默认名为-bin

后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。建议指定一个文件名，原因参见A.8.1节，“MySQL中的打开事宜”

。

如果你在日志名中提供了扩展名(

例如，--log-bin=file_name.extension

)

，则扩展名被悄悄除掉并忽略。

mysqld

在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size

，还会自动创建新的二进制日志。如果你正使用大的事务，二进制日志还会超过max_binlog_size

：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

为了能够知道还使用了哪个不同的二进制日志文件，mysqld

还创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同，扩展名为'.index'

。你可以用--log-bin-index[=file_name

]

选项更改二进制日志索引文件的文件名。当mysqld

在运行时，不应手动编辑该文件；如果这样做将会使mysqld

变得混乱。

可以用RESET MASTER

语句删除所有二进制日志文件，或用PURGE MASTER LOGS

只删除部分二进制文件。参见13.5.5.5节，“RESET语法”

和13.6.1节，“用于控制主服务器的SQL语句”

。

二进制日志格式有一些已知限制，会影响从备份恢复。参见6.7节，“复制特性和已知问题”

。

可以使用下面的mysqld

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

·

--binlog-do-db=db_name

告诉主服务器，如果当前的数据库(

即USE

选定的数据库)

是db_name

，应将更新记录到二进制日志中。其它所有没有明显指定的数据库

被忽略。如果使用该选项，你应确保只对当前的数据库进行更新。

对于CREATE DATABASE

、ALTER DATABASE

和DROP 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 DATABASE

、ALTER DATABASE

和DROP DATABASE

语句，有一个例外，即通过操作的数据库来决定是否应记录语句，而不是用当前的数据库。

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

服务器根据下面的规则对选项进行评估，以便将更新记录到二进制日志中或忽视。请注意对于CREATE

/

ALTER

/

DROP DATABASE

语句有一个例外。在这些情况下，根据以下规则，所创建、修改或删除的

数据库将代替当前的数据库。

1.

是否有binlog-do-db

或binlog-ignore-db

规则?

·

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

·

有：执行下一步。

2.

有一些规则(

binlog-do-db

或binlog-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

有时可以表示“忽视其它数据库

”)

。

如果你正进行复制，应确保没有从服务器在使用旧的二进制日志文件，方可删除它们。一种方法是每天一次执行mysqladmin flush-logs

并删除三天前的所有日志。可以手动删除，或最好使用PURGE MASTER LOGS

(

参见13.6.1节，“用于控制主服务器的SQL语句”

)

，该语句还会安全地更新二进制日志索引文件(

可以采用日期参数)

。

具有SUPER

权限的客户端可以通过SET SQL_LOG_BIN=0

语句禁止将自己的语句记入二进制记录。参见13.5.3节，“SET语法”

。

你可以用mysqlbinlog

实用工具检查二进制日志文件。如果你想要重新处理日志止的语句，这很有用。例如，可以从二进制日志更新MySQL

服务器，方法如下：

shell>

mysqlbinlog log-file | mysql -h server_name

如果你正使用事务，必须使用MySQL

二进制日志进行备份，而不能使用旧的更新日志。

查询结束后、锁定被释放前或提交完成后则立即记入二进制日志。这样可以确保按执行顺序记入日志。

对非事务表的更新执行完毕后立即保存到二进制日志中。对于事务表，例如BDB

或InnoDB

表，所有更改表的更新(

UPDATE

、DELETE

或INSERT

)

被缓存起来，直到服务器接收到COMMIT

语句。在该点，执行完COMMIT

之前，mysqld

将整个事务写入二进制日志。当处理事务的线程启动时，它为缓冲查询分配binlog_cache_size

大小的内存。如果语句大于该值，线程则打开临时文件来保存事务。线程结束后临时文件被删除。

Binlog_cache_use

状态变量显示了使用该缓冲区(

也可能是临时文件)

保存语句的事务的数量。Binlog_cache_disk_use

状态变量显示了这些事务中实际上有多少必须使用临时文件。这两个变量可以用于将binlog_cache_size

调节到足够大的值，以避免使用临时文件。

max_binlog_cache_size(

默认4GB)

可以用来限制用来缓存多语句事务的缓冲区总大小。如果某个事务大于该值，将会失败并 回滚。

如果你正使用更新日志或二进制日志，当使用CREATE ... SELECT

or

INSERT ... SELECT

时，并行插入被转换为普通插入。这样通过在备份时使用日志可以确保重新创建表的备份。

请注意MySQL 5.1

值的二进制日志格式与以前版本的MySQL

不同，因为复制改进了。参见6.5节，“不同MySQL版本之间的复制兼容性”

。

默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或机器(

不仅仅是MySQL

服务器)

崩溃，有可能二进制日志中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog

全局变量(1

是最安全的值，但也是最慢的)

，使二进制日志在每N

次二进制日志写入后与硬盘同步。参见5.3.3节，“服务器系统变量”

。即使sync_binlog

设置为1,

出现崩溃时，也有可能表内容和二进制日志内容之间存在不一致性。例如，如果使用InnoDB

表，MySQL

服务器处理COMMIT

语句，它将整个事务写入二进制日志并将事务提交到InnoDB

中。

如果在两次操作之间出现崩溃，重启时，事务被InnoDB

回滚，但仍然存在二进制日志中。可以用--innodb-safe-binlog

选项解决该问题，可以增加InnoDB

表内容和二进制日志之间的一致性。(

注释：在MySQL 5.1

中不需要--innodb-safe-binlog

；由于引入了XA

事务支持，该选项作废了)。

该选项可以提供更大程度的安全，还应对MySQL

服务器进行配置，使每个事务的二进制日志(

sync_binlog =1

)

和(

默认情况为真)

InnoDB

日志与硬盘同步。该选项的效果是崩溃后重启时，在滚回事务后，MySQL

服务器从二进制日志剪切 回滚的InnoDB

事务。这样可以确保二进制日志反馈InnoDB

表的确切数据等，并使从服务器保持与主服务器保持同步(

不接收 回滚的语句)

。

请注意即使MySQL

服务器更新其它存储引擎而不是InnoDB

，也可以使用--innodb-safe-binlog

。在InnoDB

崩溃恢复时，只从二进制日志中删除影响InnoDB

表的语句/

事务。如果崩溃恢复时MySQL

服务器发现二进制日志变短了(

即至少缺少一个成功提交的InnoDB

事务)

，如果sync_binlog =1

并且硬盘/

文件系统的确能根据需要进行同步(

有些不需要)

则不会发生，则输出错误消息("

二进制日志<

名>

比期望的要小")

。在这种情况下，二进制日志不准确，复制应从主服务器的数据快照开始。

写入二进制日志文件和二进制日志索引文件的方法与写入MyISAM

表相同。参见A.4.3节，“MySQL处理磁盘满的方式”

。