文档主页
MySQL 5.7参考手册
相关文档 下载本手册
PDF(US Ltr) - 38.2Mb
PDF(A4) - 38.2Mb
PDF(RPM) - 37.6Mb
HTML下载(TGZ) - 10.2Mb
HTML下载(Zip) - 10.3Mb
HTML下载(RPM) - 9.0Mb手册
页) - 197.4Kb手册
页(Zip) - 305.9Kb
信息(Gzip) - 3.5Mb
信息(Zip) - 3.5Mb
摘自本手册

5.4.4二进制日志

二进制日志包含描述数据库更改的事件,如表创建操作或对表数据的更改。它还包含可能可能进行更改的语句的事件(例如, DELETE不匹配行的a),除非使用基于行的日志记录。二进制日志还包含每条语句花费多长时间更新数据的信息。二进制日志有两个重要目的:

  • 对于复制,主复制服务器上的二进制日志提供了要发送到从服务器的数据更改记录。主服务器将包含在其二进制日志中的事件发送到其从服务器,从服务器执行这些事件以便在主服务器上进行相同的数据更改。请参见 第16.2节“复制实现”

  • 某些数据恢复操作需要使用二进制日志。备份恢复后,重新执行备份后记录的二进制日志中的事件。这些事件从备份的角度来说是最新的数据库。请参见 第7.5节“使用二进制日志进行时间点恢复(增量)”

二进制日志不用于诸如SELECTSHOW不修改数据的语句 要记录所有语句(例如,识别问题查询),请使用常规查询日志。请参见第5.4.3节“常规查询日志”

运行启用二进制日志记录的服务器会使性能稍微降低。但是,二进制日志的优点使您能够设置复制和还原操作,这通常会超过这个较小的性能下降。

二进制日志通常对意外的暂停有弹性,因为只有完整的事务被记录或回读。有关更多信息请参见 第16.3.2节“处理意外的复制从站”

写入二进制日志的语句中的密码被服务器重写,不会以纯文本形式出现。另请参见 第6.1.2.3节“密码和记录”

以下讨论描述了影响二进制日志记录操作的一些服务器选项和变量。有关完整列表,请参见 第16.1.6.4节“二进制日志记录选项和变量”

要启用二进制日志,请使用该 选项启动服务器 如果没有给定值,则默认名称是该 选项的值(默认为主机名) 如果给出了基本名称,则服务器将该文件写入数据目录,除非使用前导绝对路径名给出基本名称来指定不同的目录。建议您明确指定一个基本名称,而不是使用主机名称的缺省值; 请参阅 第B.5.7节“MySQL中的已知问题”--log-bin[=base_name]base_namepid-file-bin

如果您在日志名称中提供扩展名(例如, ),则会以静默方式删除并忽略扩展名。 --log-bin=base_name.extension

mysqld将数字扩展名附加到二进制日志基本名称以生成二进制日志文件名称。每次服务器创建一个新的日志文件时,这个数字都会增加,从而创建一系列有序的文件。每次启动或刷新日志时,服务器都会在系列中创建一个新文件。当前日志的大小达到后,服务器也会自动创建一个新的二进制日志文件 max_binlog_size二进制日志文件可能会变得比max_binlog_size如果您正在使用大型事务更大, 因为一个事务写入文件的一块,永远不会在文件之间分割。

要跟踪哪些二进制日志文件已被使用, mysqld还会创建一个二进制日志索引文件,其中包含所有使用的二进制日志文件的名称。默认情况下,它与二进制日志文件具有相同的基本名称,并带有扩展名'.index'您可以使用该 选项更改二进制日志索引文件的名称 mysqld运行时,不应该手动编辑这个文件 这样做会混淆 mysqld--log-bin-index[=file_name]

术语二进制日志文件通常表示包含数据库事件的单独编号的文件。术语 二进制日志共同表示编号的二进制日志文件加上索引文件的集合。

具有该SUPER 特权的客户端可以通过使用SET sql_log_bin=0语句来禁用其自己的语句的二进制日志记录请参见 第5.1.5节“服务器系统变量”

默认情况下,服务器记录事件的长度以及事件本身,并使用它来验证事件是否正确写入。您还可以通过设置binlog_checksum系统变量来使服务器为事件写入校验和 从二进制日志读回时,主设备默认使用事件长度,但是可以通过启用master_verify_checksum系统变量来使用校验和 从I / O线程还会验证从主设备接收的事件。当通过启用slave_sql_verify_checksum系统变量从中继日志读取时,可以使从属SQL线程使用校验和(如果可用)

记录在二进制日志中的事件的格式取决于二进制记录格式。支持三种格式类型,基于行的日志记录,基于语句的日志记录和基于混合的日志记录。二进制日志记录格式取决于MySQL版本。有关日志格式的一般说明,请参见 第5.4.4.1节“二进制日志记录格式”有关二进制日志格式的详细信息,请参阅 MySQL内部:二进制日志

服务器以--binlog-do-db--binlog-ignore-db选项选项相同的方式 评估 --replicate-do-db--replicate-ignore-db选项。有关如何完成的信息,请参见 第16.2.5.1节“数据库级复制和二进制日志记录选项的评估”

默认情况下,复制从服务器不会将从复制主服务器接收到的任何数据修改写入到其自己的二进制日志中。要记录这些修改,--log-slave-updates除了选项之外,还要使用该选项启动从站--log-bin(请参见第16.1.6.3节“复制从站选项和变量”)。当一个从设备也作为链接复制中的其他从设备的主设备时,这就完成了。

您可以使用RESET MASTER语句或其子集删除所有二进制日志文件 PURGE BINARY LOGS请参见 第13.7.6.6节“RESET语法”第13.4.1.1节“PURGE BINARY LOGS语法”

如果您正在使用复制,则不应删除主服务器上的旧二进制日志文件,直到您确定没有从服务器仍然需要使用它们。例如,如果你的奴隶永远不会超过三天,一天一次,你可以在主服务器上执行mysqladmin flush-logs,然后删除超过三天的日志。您可以手动删除这些文件,但最好使用它PURGE BINARY LOGS,它也可以安全地为您更新二进制日志索引文件(以及可以采用日期参数)。请参见 第13.4.1.1节“PURGE BINARY LOGS语法”

您可以使用mysqlbinlog实用程序显示二进制日志文件的内容 当您想要重新处理日志中的语句以进行恢复操作时,这会很有用。例如,您可以从二进制日志中更新MySQL服务器,如下所示:

            
Press CTRL+C to copy
shell> mysqlbinlog log_file | mysql -h server_name

mysqlbinlog也可以用来显示复制从属中继日志文件的内容,因为它们使用与二进制日志文件相同的格式写入。有关 mysqlbinlog实用程序以及如何使用它的更多信息,请参见 第4.6.7节“ mysqlbinlog - 处理二进制日志文件的实用程序”有关二进制日志和恢复操作的更多信息,请参见 第7.5节“使用二进制日志进行时间点恢复(增量)”

二进制日志记录是在语句或事务完成后,但在任何锁定被释放或任何提交完成之前立即完成的。这可确保日志以提交顺序进行记录。

非事务表的更新在执行后立即存储在二进制日志中。

在未提交的事务中,更改事务表(例如)的所有更新(UPDATEDELETEINSERT)将InnoDB被缓存,直到COMMIT服务器接收到一条 语句。此时,mysqldCOMMIT执行之前将整个事务写入二进制日志

对非事务表的修改无法回滚。如果回滚的事务包括对非事务表的修改,则整个事务将ROLLBACK 在最后使用语句进行记录, 以确保对这些表的修改被复制。

当处理事务的线程开始时,它将缓冲区分配binlog_cache_size给缓冲区语句。如果一个语句比这个大,那么线程将打开一个临时文件来存储事务。线程结束时临时文件被删除。

所述Binlog_cache_use状态变量表明,用这种缓冲液(和可能的一个临时文件),用于存储语句事务的数目。Binlog_cache_disk_use状态变量显示许多这些交易实际上是如何不得不使用临时文件。这两个变量可用于调整 binlog_cache_size到足够大的值,以避免使用临时文件。

所述max_binlog_cache_size系统变量(默认4GB,这也是最大)可被用来限制用于高速缓存的多语句事务的总大小。如果事务大于这么多字节,它将失败并回滚。最小值是4096。

如果您正在使用二进制日志和基于行的日志记录,并发插入转换为正常插入CREATE ... SELECTINSERT ... SELECT语句。这样做是为了确保您可以通过在备份操作期间应用日志来重新创建表的精确副本。如果您使用基于语句的日志记录,则原始语句将写入日志。

二进制日志格式有一些已知的限制,可能会影响从备份恢复。请参见第16.4.1节“复制功能和问题”

存储程序的二进制日志记录按 第23.7节“存储程序的二进制日志记录”中所述完成

请注意,由于复制的增强,二进制日志格式在MySQL 5.7与以前版本的MySQL中不同。请参见第16.4.2节“MySQL版本之间的复制兼容性”

写入二进制日志文件和二进制日志索引文件的处理方式与写入MyISAM 表的方式相同请参见第B.5.3.4节“MySQL如何处理整个磁盘”

默认情况下,二进制日志在每次write(sync_binlog=1)时同步到磁盘如果 sync_binlog未启用,并且操作系统或计算机(不仅是MySQL服务器)崩溃,则可能会丢失二进制日志的最后一条语句。为防止出现这种情况,请sync_binlog在每个N提交组之后启用 系统变量以将二进制日志同步到磁盘 请参见 第5.1.5节“服务器系统变量”最安全的值 sync_binlog是1(默认值),但这也是最慢的。

例如,如果您正在使用InnoDB表并且MySQL服务器处理COMMIT 语句,则会将许多准备好的事务顺序写入二进制日志,同步二进制日志,然后提交此事务InnoDB如果服务器在这两个操作之间崩溃,则事务InnoDB在重新启动时回退, 但仍然存在于二进制日志中。假设这个问题被解决 --innodb_support_xa,默认设置为1。虽然这个选项与XA交易的支持有关InnoDB,这也确保了二进制日志和InnoDB数据文件的同步。为了提供更高的安全性,MySQL服务器还应该配置为InnoDB在提交事务之前将二进制日志和日志同步 到磁盘。InnoDB日志默认同步的,并且sync_binlog=1可用于二进制日志同步。这个选项的作用是在崩溃后重新启动时,在事务回滚之后,MySQL服务器扫描最新的二进制日志文件以收集事务xid值并计算二进制日志文件中的最后有效位置。MySQL服务器然后告诉InnoDB完成任何已成功写入二进制日志的准备事务,并将二进制日志截断到最后一个有效位置。这确保了二进制日志反映了InnoDB的确切数据 ,因此从服务器与主服务器保持同步,因为它没有收到已经回退的语句。

注意

innodb_support_xa已弃用,将在未来版本中删除。 InnoDB对于XA事务中的两阶段提交的支持始终从MySQL 5.7.10开始启用。

如果MySQL服务器在崩溃恢复时发现二进制日志比本来应该是短的,它至少缺少一个成功提交的InnoDB事务。如果sync_binlog=1磁盘/文件系统在被请求(有些不需要)时执行实际同步,则不应该发生这种情况,所以服务器将输出错误消息在这种情况下,这个二进制日志不正确,应该从主数据的新快照重新开始复制​​。 The binary log file_name is shorter than its expected size

在解析二进制日志时,下列系统变量的会话值被写入到二进制日志中,并由复制从服务器记录:


用户评论
  发布者 罗纳德·布拉德福德 在2011年3月2日
二进制日志可以提供有关每个表的DML语句频率的有价值的信息。

这个简单的一行Linux命令可以提供有价值的输出:

$ mysqlbinlog /path/to/mysql-bin.000999 | \
grep -i -e“^ update”-e“^ insert”-e“^ delete”-e“^ replace”-e“^ alter”| \
cut -c1-100 | tr'[AZ]'[az]'| \
sed -e“s / \ t / /g;s/\`//g;s/(.*$//;s/set。* $ //; s / as。* $ //”| sed -e“s / where。* $ //” |
\ sort | uniq -c | sort

-nr 33389 update e_acc 17680
insert into r_b 17680
insert into e_rec
14332 insert into rcv_c
13543 update e_rec
10805 update loc
3339 insert into r_att
2781 insert into o_att
...

更多详情,请访问 http://ronaldbradford.com/blog/mysql-dml-stats-per-table-2009-09-09/
注册 登录 您必须登录后才能发表评论。