目录

二进制记录格式

设置二进制日志格式

混合二进制记录格式

更改mysql数据库表的日志记录格式

二进制日志包含描述数据库更改（例如表创建操作或表数据更改）的“ 事件 ”。它还包含针对可能进行了更改的语句的事件（例如， DELETE操作，没有任何匹配到的行），除非使用基于行的日志记录。二进制日志还包含有关每个语句花费该更新数据多长时间的信息。二进制日志有两个重要目的：

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

• 某些数据恢复操作需要使用二进制日志。还原备份后，将重新执行在执行备份后记录的二进制日志中的事件。这些事件使数据库从备份开始就保持最新状态。请参见 第7.5节“使用二进制日志进行时间点（增量）恢复”。

二进制日志不用于诸如SELECT或 SHOW不修改数据的语句 。要记录所有语句（例如，确定有问题的查询），请使用常规查询日志。请参见第5.4.3节“常规查询日志”。

运行启用了二进制日志记录的服务器会使性能稍慢。但是，二进制日志在使您能够设置复制和进行还原操作方面的好处通常超过了这种较小的性能下降。

二进制日志通常可以抵抗意外的暂停，因为仅记录或读取完整的事务。有关更多信息，请参见 第16.3.2节“处理复制从站的意外中止”。

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

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

要启用二进制日志，请使用 –log_bin [=basename]选项启动服务器 。如果未给出base_name值，则默认名称为 --pid-file选项的值 （默认为主机名），后跟-bin。如果指定了基本名称，则服务器将文件写入数据目录中，除非基本名称带有开头的绝对路径名以指定其他目录。建议您显式指定基本名称，而不要使用主机名的默认名称。原因请参见第B.4.7节“ MySQL中的已知问题”。

如果您在日志名称中提供扩展名（例如 --log-bin=base_name.extension），则该扩展名将被悄悄的删除并忽略。

mysqld在二进制日志基本名称后附加数字扩展名以生成二进制日志文件名。每次服务器创建新的日志文件时，该数目都会增加，从而创建了有序的文件系列。每次服务器启动或刷新日志时，服务器都会在系列中创建一个新文件。在当前日志的大小达到max_binlog_size变量值后，服务器就会自动创建一个新的二进制日志文件 。如果您使用大型事务，则二进制 log 文件可能会变得大于max_binlog_size，因为事务会一次性写入文件，而不会在 files 之间分割。。

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

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

具有足以设置受限 session 系统变量(请参阅第 5.1.8.1 节，“系统变量权限”)的权限的客户端，可以通过使用SET sql_log_bin=OFF语句禁用其自身语句的二进制记录 。

默认情况下，服务器记录事件的长度以及事件本身，并使用它来验证事件是否被正确写入。您还可以通过设置binlog_checksum系统变量来使服务器编写事件的校验和 。从二进制日志中读回时，默认情况下，主服务器使用事件长度，但可以通过启用master_verify_checksum系统变量来使用校验和（如果可用） 。从属I / O线程还验证从主控接收到的事件。通过启用slave_sql_verify_checksum系统变量，可以在从中继（ the relay log）日志中读取时使 slave （从属）SQL线程使用校验和（如果可用） 。

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

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

默认情况下，从复制服务器不会将从主复制服务器接收到的任何数据写入其自己的二进制日志中。要记录这些修改，除了–log-bin选项外，还要使用–log-slave-updates选项（请参见第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，它还会为您安全地更新二进制日志索引文件（并且可以使用date参数）。请参见 第13.4.1.1节“ PURGE BINARY LOGS语句”。

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

shell> mysqlbinlog log_file | mysql -h server_name

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

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

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

在未提交的事务中，所有更改事务表（例如表）的更新（UPDATE， DELETE或 INSERT）都会被InnoDB缓存，直到服务器接收到一条 COMMIT语句。此时，mysqld在COMMIT执行之前将整个事务写入二进制日志 。

对非事务表的修改不能回滚。如果回滚的事务包括对非事务表的修改，则会在末尾使用ROLLBACK语句记录整个事务，以确保这些修改的表可以还原。

当处理事务的线程启动时，它会为缓冲区语句分配一个缓冲区，大小取决于binlog_cache_size。如果语句大于此值，则线程将打开一个临时文件来存储事务。当线程结束时，将删除临时文件。

Binlog_cache_use 变量显示使用此缓冲区(可能还有临时文件)存储语句的事务数。该 Binlog_cache_disk_use状态变量显示有多少事务实际上不得不使用临时文件。这两个变量可用于调整 binlog_cache_size到足够大的值，从而避免使用临时文件。

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

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

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

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

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

如果服务器无法写入二进制日志，刷新二进制日志文件或将二进制日志同步到磁盘，则主复制数据库上的二进制日志可能会变得不一致，并且从复制数据库可能会与主数据库失去同步。 binlog_error_action系统变量控制在二进制 log 遇到此类错误时采取的操作。

• 默认设置，ABORT_SERVER使服务器停止二进制日志记录并关闭。此时，您可以确定并纠正错误原因。重新启动后，恢复将继续进行，就像服务器意外中止一样（请参见第16.3.2节“处理复制从属的意外中止 ”）。

• 该设置IGNORE_ERROR提供了与旧版本MySQL的向后兼容性。使用此设置，服务器将继续进行中的事务并记录错误，然后停止二进制日志记录，但继续执行更新。此时，您可以确定并纠正错误原因。要恢复二进制日志记录， log_bin必须再次启用，这需要重新启动服务器。仅在需要向后兼容性且二进制日志在此MySQL服务器实例上为非必需时才使用此选项。例如，您可能只将二进制日志用于服务器的间歇审核或调试，而不将其用于从服务器复制或将其用于时间点还原操作。

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

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

注意

innodb_support_xa已弃用，并将在以后的版本中删除。 InnoDB从MySQL 5.7.10开始，始终启用XA事务中的两阶段提交支持。

如果MySQL服务器在崩溃恢复时发现二进制日志短于其应有的时间，则它至少缺少一个成功提交的InnoDB事务。如果sync_binlog=1在请求时disk/file 系统进行了实际的同步（有些没有这样做），则不会发生这种情况，因此服务器将显示一条错误消息The binary log file_name is shorter than its expected size。在这种情况下，此二进制日志不正确，应从主数据的新快照重新开始复制​​。 

解析二进制日志时，以下系统变量的会话值将写入二进制日志并由从属复制服务器遵循：

• sql_mode（除了NO_DIR_IN_CREATE不复制模式外 ；请参见 第16.4.1.37节“复制和变量”）

• foreign_key_checks

• unique_checks

• character_set_client

• collation_connection

• collation_database

• collation_server

• sql_auto_is_null

二进制记录格式

服务器使用几种日志记录格式将信息记录在二进制日志中。所使用的确切格式取决于所使用的MySQL版本。有三种日志记录格式：

• MySQL中的复制功能最初是基于SQL语句从主服务器到从服务器的传播。这称为基于语句的日志记录。您可以通过使用–binlog-format=STATEMENT启动服务器来使用此格式。

• 在基于行的日志记录中，主服务器将事件写入二进制日志，该事件指示如何影响各个表行。因此，表始终使用主键以确保可以有效地标识行是很重要的。您可以通过--binlog-format=ROW启动使服务器使用基于行的日志记录 。

• 还有第三个选项：混合日志记录。对于混合日志记录，默认使用 statement-based记录，但日志记录在某些情况下会自动切换到 row-based，如下所述。通过使用选项–binlog-format=MIXED启动mysqld，可以使 MySQL 显式使用混合日志记录。

日志记录格式还可以通过使用的存储引擎来设置或限制。这有助于消除在使用不同存储引擎的主服务器和从服务器之间复制某些语句时出现的问题。

使用基于语句的复制时，复制不确定性语句可能会出现问题。在确定给定语句对于基于语句的复制是否安全时，MySQL确定是否可以保证可以使用基于语句的日志记录来复制该语句。如果MySQL无法做出保证，它将标记该语句为潜在不可靠的对象，并发出警告，Statement may not be safe to log in statement format.

您可以通过使用MySQL的基于行的复制来避免这些问题。

设置二进制日志格式

您可以通过使用–binlog-format=type启动 MySQL 服务器来显式选择二进制 logging 格式。 type支持的值为：

• STATEMENT导致 logging 基于语句。

• ROW导致 logging 基于行。

• MIXED导致 logging 使用混合格式。

日志记录格式也可以在运行时进行切换，尽管请注意，在许多情况下您无法执行此操作，如本节后面所述。设置binlog_format 系统变量的全局值，以指定更改后连接的客户端的格式：

mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';

单个 client 可以通过设置binlog_format的 session value 来控制自己的 statements 的 logging 格式：

mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';

更改全局 binlog_format值需要足够的特权来设置全局系统变量。更改会话binlog_format值需要足够的特权来设置受限制的会话系统变量。请参见第5.1.8.1节“系统变量特权”。

客户端可能要基于每个会话设置二进制日志记录的原因有几个：

• 对数据库进行许多细微更改的会话可能要使用基于行的日志记录。

• 执行与WHERE子句中的许多行匹配的更新的会话 可能要使用基于语句的日志记录，因为记录几条语句比记录多行会更有效。

• 有些语句在主服务器上需要大量执行时间，但只会导致修改几行。因此，使用基于行的日志记录来复制它们可能是有益的。

您无法在运行时切换复制格式时，不过会有一些例外情况：

• 从存储的函数或触发器中。

• 如果NDB启用了存储引擎。

• 会话当前处于基于行的复制模式并且具有打开的临时表。

在任何这些情况下尝试切换格式都会导致错误。

不存在任何临时表时，建议不要在运行时切换复制格式，因为仅在使用基于语句的复制时才记录临时表，而对于基于行的复制则不记录它们。对于混合复制，通常会记录临时表。用户定义函数（UDF）和该UUID()函数会发生异常 。

在复制进行过程中切换复制格式也会导致问题。每个MySQL Server可以设置自己的并且只能设置自己的二进制日志记录格式（无论binlog_format是在全局范围还是在会话范围内设置，均为true ）。这意味着更改主复制服务器上的日志记录格式不会导致从属服务器更改其日志记录格式以匹配。使用 STATEMENT模式时， binlog_format不会复制系统变量。使用MIXED或 ROW记录模式时，它会被复制，但被从属设备忽略。

 复制从站无法将以ROW日志记录格式 接收的二进制日志条目STATEMENT转换为在其自己的二进制日志中使用的格式。因此，如果主服务器需要，则从服务器必须使用ROW或 MIXED格式化。将 master 上的二进制 logging 格式从STATEMENT更改为ROW或MIXED，而复制正在进行到STATEMENT格式的从属可能导致复制失败，并出现错误，例如执行行 event 错误：’无法执行语句：无法写入二进制 log，因为语句是行格式，BINLOG_FORMAT = STATEMENT。当 master 仍在使用MIXED或ROW格式时，将从站上的二进制 logging 格式更改为STATEMENT格式也会导致相同类型的复制失败。要安全地更改格式，必须停止复制并确保对 master 和 slave 进行相同的更改。

如果使用InnoDB表且 transaction 隔离 level 为阅读提交或阅读不满意，则只能使用 row-based logging。可以将 logging 格式更改为STATEMENT，但在运行时这样做会导致错误，因为InnoDB无法再执行插入操作。

将二进制 log 格式设置为ROW时，使用 row-based 格式将许多更改写入二进制 log。但是，某些更改仍使用 statement-based 格式。示例包括所有 DDL(数据定义语言)语句，例如CREATE TABLE，ALTER TABLE或DROP TABLE。

 –binlog-row-event-max-size选项可用于能够进行 row-based 复制的服务器。行以块的大小存储在二进制 log 中，块大小以字节为单位，不超过此选项的 value。 value 必须是 256 的倍数。默认的 value 是 8192。

警告当使用 statement-based logging 进行复制时，如果语句的设计方式使得数据修改是不确定的，则 master 和 slave 上的数据可能会变得不同;也就是说，它留给了查询优化器的意愿。通常，即使在复制之外，这也不是一种好的做法。有关此问题的详细说明，请参阅第 B.4.7 节，“MySQL 中的已知问题”。
有关复制从站保留的日志的信息，请参阅第 16.2.4 节，“复制中继和状态日志”。

混合二进制记录格式

当以MIXED日志记录格式运行时，服务器在以下情况下自动从基于语句的记录切换为基于行的记录：

• 当 function 包含UUID()时。

• 当更新一个或多个具有AUTO_INCREMENT列的表并调用触发器或存储的 function 时。与所有其他不安全的语句一样，binlog_format = STATEMENT，则会生成警告。

有关更多信息，请参阅第 16.4.1.1 节，“复制和 AUTO_INCREMENT”。

• 当视图的主体需要 row-based 复制时，创建视图的语句也会使用它。例如，当创建视图的语句使用UUID() function 时会发生这种情况。

• 当涉及到对 UDF 的调用时。

• 如果按行记录语句并且执行该语句的 session 具有任何临时表，则按行记录将用于所有后续语句（访问临时表的语句除外），直到该会话使用的所有临时表都被删除为止。无论是否实际记录任何临时表，这都是对的。

无法使用 row-based 格式记录临时表;因此，一旦使用 row-based logging，使用该 table 的所有后续 statement 都是不安全的。服务器通过将 session 期间执行的所有语句视为不安全来近似此条件，直到 session 不再保留任何临时表为止。

• 使用FOUND_ROWS()或ROW_COUNT()时。 (Bug#12092，Bug#30244)

• 使用USER()，CURRENT_USER()或CURRENT_USER时。 (Bug#28086)

• 当语句引用一个或多个系统变量时。 (缺陷号 31168)

 以下系统变量（仅与会话范围一起使用）不会导致切换日志记录格式：

• auto_increment_increment

• auto_increment_offset

• character_setclient

• character_set_connection

• character_set_database

• character_set_server

• collation_connection

• collation_database

• collation_server

• foreignkey_checks

• identity

• lastinsert_id

• lctimenames

• pseudo_thread_id

• sql_auto_is_null

• timezone

• timestamp

• unique_checks

有关复制如何处理sql_mode的信息，请参阅第 16.4.1.37 节，“复制和变量”。

• 当涉及的其中一个表是mysql数据库中的日志表时。

• 使用LOAD_FILE() function 时。 (Bug#39701)

注意
如果您尝试使用基于语句的日志记录去执行应该基于行的日志记录时，会生成警告。警告显示在 client(在 SHOW WARNINGS的输出中)和mysqld error log 中。每次执行这样的语句时，都会向表中添加一条SHOW WARNINGS 警告。但是，只有为每个客户端会话生成警告的第一条语句才被写入错误日志，以防止日志泛滥。
除了上述决定外，各个引擎还可以确定更新表中信息时使用的日志记录格式。单个引擎的日志记录功能可以定义如下：

• 如果引擎支持基于行的日志记录，则称该引擎具有行记录功能。

• 如果引擎支持基于语句的日志记录，则称该引擎具有语句记录能力。

给定的存储引擎可以支持一种或两种日志格式。下表列出了每个引擎支持的格式。

是否要记录语句和要使用的记录模式是根据语句类型(安全，不安全或二进制注入)，二进制日志记录格式（STATEMENT，ROW，或 MIXED），存储引擎(具有语句能力，行能力，两者兼有，或两者都没有)。（二进制注入是指记录必须使用ROW格式记录的更改。） 

可能会在有或没有警告的情况下记录语句；失败的语句不会记录，但会在日志中生成错误。如下决策表所示。 Type， binlog_format， SLC和 RLC列概述了条件，而Error / Warning 和Logged as列表示相应的操作。SLC 代表“具有语句记录能力 ”，而 RLC代表 “具有行记录能力 ”。

 当确定产生警告时，会生成标准的 MySQL 警告(并且可以使用 SHOW WARNINGS)。该信息也将写入mysqld错误日志。每个客户端连接的每个错误实例仅记录一个错误，以防止泛滥日志。日志消息包含尝试的SQL语句。

如果log_error_verbosity在从属服务器上大于等于2，则从属服务器会将错误状态信息记录到错误日志，以提供有关其状态的信息，例如二进制日志和中继日志坐标开始工作（切换到另一个中继日志，断开连接后重连，对于基于语句的日志记录不安全的语句等）。

更改mysql数据库表的日志记录格式

mysql 数据库中 授权表的内容可以直接（例如，用INSERT或 DELETE）修改，也可以 间接地（例如用GRANT或 CREATE USER）修改。mysql使用以下规则将影响数据库表的语句写入二进制日志：

• 根据binlog_format系统变量的设置记录直接更改mysql数据库表中数据的数据操作语句。这适用于语句，如 INSERT， UPDATE， DELETE， REPLACE， DO，LOAD DATA，SELECT，和 TRUNCATE TABLE。
• 间接更改mysql数据库的语句将记录为 statements（基于语句的存储格式），不管binlog_format的值为何，这适用于 GRANT, REVOKE, SET PASSWORD, RENAME USER, CREATE (所有形式，除了CREATE TABLE ... SELECT), ALTER (所有形式), and DROP (所有形式).

CREATE TABLE ... SELECT 是数据定义和数据操作的组合。 CREATE TABLE 部分使用statement format记录日志， SELECT 部分的日志记录方式取决于 binlog_format的值。

简单总结

以下配置文件的参数影响着二进制日志记录的信息和行为：

max_binlog_size    —-单个二进制文件的最大值，超过该值，产生一个新的二进制文件，后缀名加一，并记录到.index文件中。

binlog_cache_size   —-基于会话，事务提交会将二进制日志缓冲记录到日志文件。

sync_binlog  –表示每写缓冲多少次就同步到磁盘。如果想得到最大的高可用，建议此值设置为ON.

binlog-do-db   —-这两个表示需要写入或忽略写入哪些库的日志。默认为空，表示写入所有库

binlog-ignore-db

log-slave-update    –如果当前数据库是复制中的slave角色，是不会从master取得并执行的二进制日志写入自己的二进制日志文件中去的。如果需要写入，要设置log_slave_update。如果需要搭建master=>slave=>架构的复制，则必须设置该参数。

binlog_format –二进制日志的记录格式。值为statement、row和mixed。

innodb_support_xa   –开启此参数可以确保二进制日志和innodb存储引擎数据文件的同步。

假如binlog_format模式选用ROW，则innodb的事务隔离基本设置为READ COMMITTED;