5.4.4.2 Setting The Binary Log Format设置二进制日志格式

You can select the binary logging format explicitly by starting the MySQL server with --binlog-format=type. 您可以通过使用--binlog-format=type启动MySQL服务器来显式地选择二进制日志记录格式。The supported values for type are:type支持的值为:

Setting the binary logging format does not activate binary logging for the server. The setting only takes effect when binary logging is enabled on the server, which is the case when the log_bin system variable is set to ON. 设置二进制日志记录格式不会激活服务器的二进制日志记录。只有当服务器上启用二进制日志记录时,该设置才会生效,当log_bin系统变量设置为ON时就是这种情况。From MySQL 8.0, binary logging is enabled by default, and is only disabled if you specify the --skip-log-bin or --disable-log-bin option at startup.在MySQL 8.0中,默认情况下会启用二进制日志记录,并且只有在启动时指定--skip-log-bin--disable-log-bin选项时才会禁用二进制日志记录。

The logging format also can be switched at runtime, although note that there are a number of situations in which you cannot do this, as discussed later in this section. 日志记录格式也可以在运行时切换,但请注意,在许多情况下您无法切换,如本节稍后所述。Set the global value of the binlog_format system variable to specify the format for clients that connect subsequent to the change:设置binlog_format系统变量的全局值,以指定更改后连接的客户端的格式:

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

An individual client can control the logging format for its own statements by setting the session value of binlog_format:单个客户端可以通过设置binlog_format的会话值来控制其自身语句的日志记录格式:

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

Changing the global binlog_format value requires privileges sufficient to set global system variables. 更改全局binlog_format值需要足够的权限来设置全局系统变量。Changing the session binlog_format value requires privileges sufficient to set restricted session system variables. 更改会话binlog_format值需要足够的权限来设置受限制的会话系统变量。See Section 5.1.9.1, “System Variable Privileges”.请参阅第5.1.9.1节,“系统变量权限”

There are several reasons why a client might want to set binary logging on a per-session basis:客户端可能希望在每个会话的基础上设置二进制日志记录,原因有几个:

There are exceptions when you cannot switch the replication format at runtime:当您无法在运行时切换复制格式时,会出现例外情况:

Trying to switch the replication format in any of these cases (or attempting to set the current replication format) results in an error. 在任何这些情况下尝试切换复制格式(或尝试设置当前复制格式)都会导致错误。You can, however, use PERSIST_ONLY (SET @@PERSIST_ONLY.binlog_format) to change the replication format at any time, because this action does not modify the runtime global system variable value, and takes effect only after a server restart.但是,您可以随时使用PERSIST_ONLYSET @@PERSIST_ONLY.binlog_format)更改复制格式,因为此操作不会修改运行时全局系统变量值,并且仅在服务器重新启动后生效。

Switching the replication format at runtime is not recommended when any temporary tables exist, because temporary tables are logged only when using statement-based replication, whereas with row-based replication and mixed replication, they are not logged.当存在任何临时表时,不建议在运行时切换复制格式,因为只有在使用基于语句的复制时才会记录临时表,而对于基于行的复制和混合复制,则不会记录临时表。

Switching the replication format while replication is ongoing can also cause issues. 在进行复制时切换复制格式也会导致问题。Each MySQL Server can set its own and only its own binary logging format (true whether binlog_format is set with global or session scope). This means that changing the logging format on a replication source server does not cause a replica to change its logging format to match. 每个MySQL Server都可以设置自己的,并且只能设置自己的二进制日志记录格式(无论binlog_format设置为全局范围还是会话范围,都为true)。这意味着更改复制源服务器上的日志记录格式不会导致复制副本更改其日志记录格式以匹配。When using STATEMENT mode, the binlog_format system variable is not replicated. 使用STATEMENT模式时,不复制binlog_format系统变量。When using MIXED or ROW logging mode, it is replicated but is ignored by the replica.当使用MIXEDROW日志记录模式时,它会被复制,但会被复制副本忽略。

A replica is not able to convert binary log entries received in ROW logging format to STATEMENT format for use in its own binary log. 复制副本无法将以ROW日志记录格式接收的二进制日志条目转换为STATEMENT格式,以便在其自己的二进制日志中使用。The replica must therefore use ROW or MIXED format if the source does. 因此,如果源使用ROWMIXED格式,则复制副本必须使用ROW格式。Changing the binary logging format on the source from STATEMENT to ROW or MIXED while replication is ongoing to a replica with STATEMENT format can cause replication to fail with errors such as Error executing row event: 'Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT.' 在复制到具有STATEMENT格式的副本时,将源上的二进制日志记录格式从STATEMENT更改为ROWMIXED可能会导致复制失败,并出现错误,例如执行行事件时出错:“无法执行语句:由于语句为行格式且BINLOG_FORMAT = STATEMENT,因此无法写入二进制日志。”Changing the binary logging format on the replica to STATEMENT format when the source is still using MIXED or ROW format also causes the same type of replication failure. 当源仍在使用MIXEDROW格式时,将副本上的二进制日志记录格式更改为STATEMENT格式也会导致相同类型的复制失败。To change the format safely, you must stop replication and ensure that the same change is made on both the source and the replica.要安全地更改格式,必须停止复制,并确保对源和复制副本都进行了相同的更改。

If you are using InnoDB tables and the transaction isolation level is READ COMMITTED or READ UNCOMMITTED, only row-based logging can be used. 如果使用InnoDB表,并且事务隔离级别为READ COMMITTEDREAD UNCOMITTED,则只能使用基于行的日志记录。It is possible to change the logging format to STATEMENT, but doing so at runtime leads very rapidly to errors because InnoDB can no longer perform inserts.可以将日志记录格式更改为STATEMENT,但在运行时这样做会很快导致错误,因为InnoDB无法再执行插入。

With the binary log format set to ROW, many changes are written to the binary log using the row-based format. 当二进制日志格式设置为ROW时,许多更改都使用基于行的格式写入二进制日志。Some changes, however, still use the statement-based format. 但是,有些更改仍然使用基于语句的格式。Examples include all DDL (data definition language) statements such as CREATE TABLE, ALTER TABLE, or DROP TABLE.示例包括所有DDL(数据定义语言)语句,如CREATE TABLEALTER TABLEDROP TABLE

When row-based binary logging is used, the binlog_row_event_max_size system variable and its corresponding startup option --binlog-row-event-max-size set a soft limit on the maximum size of row events. 当使用基于行的二进制日志记录时,binlog_row_event_max_size系统变量及其相应的启动选项--binlog-row-event-max-size对行事件的最大大小设置了软限制。The default value is 8192 bytes, and the value can only be changed at server startup. Where possible, rows stored in the binary log are grouped into events with a size not exceeding the value of this setting. If an event cannot be split, the maximum size can be exceeded.默认值为8192字节,并且该值只能在服务器启动时更改。在可能的情况下,存储在二进制日志中的行被分组为大小不超过此设置值的事件。如果无法拆分事件,则可能会超出最大大小。

The --binlog-row-event-max-size option is available for servers that are capable of row-based replication. --binlog-row-event-max-size选项可用于能够进行基于行的复制的服务器。Rows are stored into the binary log in chunks having a size in bytes not exceeding the value of this option. The value must be a multiple of 256. The default value is 8192.行以字节为单位存储在二进制日志中,其大小不超过此选项的值。该值必须是256的倍数。默认值为8192。

Warning警告

When using statement-based logging for replication, it is possible for the data on the source and replica to become different if a statement is designed in such a way that the data modification is nondeterministic; that is, it is left up to the query optimizer. 在使用基于语句的日志记录进行复制时,如果语句的设计使数据修改不具有确定性,则源和副本上的数据可能会变得不同;也就是说,这取决于查询优化器。In general, this is not a good practice even outside of replication. For a detailed explanation of this issue, see Section B.3.7, “Known Issues in MySQL”.总的来说,即使在复制之外,这也不是一个好的做法。有关此问题的详细解释,请参阅B.3.7节,“MySQL中的已知问题”