MySQL8.0大师之路：第11章：MySQL服务器管理-11.14 MySQL 设置二进制日志格式

JeeStudy · 发表于 2020-4-21 22:29:10

设置二进制日志格式
您可以通过使用--binlogformat = type启动MySQL服务器来显式选择二进制日志记录格式。支持的类型值为：
•STATEMENT：使日志记录基于语句。
•ROW ：使日志记录基于行。这是默认值。
•MIXED ：使日志记录使用混合格式。
日志记录格式也可以在运行时进行切换，尽管请注意，在许多情况下您无法执行此操作，如本节后面所述。设置binlog_format系统变量的全局值，以指定更改后连接的客户端的格式：

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

单个客户端可以通过设置binlog_format的会话值来控制其自己的语句的日志记录格式：

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

更改全局binlog_format值需要足够的特权来设置全局系统变量。更改会话binlog_format值需要足够的特权来设置受限制的会话系统变量。

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

•对数据库进行许多细微更改的会话可能要使用基于行的日志记录。
•执行与WHERE子句中的许多行匹配的更新的会话可能要使用基于语句的日志记录，因为与许多行相比，记录一些语句会更高效。
•有些语句在主服务器上需要大量执行时间，但导致仅修改了几行。因此，使用基于行的日志记录来复制它们可能是有益的。
当您无法在运行时切换复制格式时，会有一些例外情况：
•无法从存储的函数或触发器中更改复制格式。
•如果启用了NDB存储引擎。
•如果会话具有打开的临时表，则无法更改该会话的复制格式（SET @@ SESSION.binlog_format）。
•如果任何复制通道都有打开的临时表，则不能全局更改复制格式（SET @@ GLOBAL.binlog_format或SET @@ PERSIST.binlog_format）。
•如果当前正在运行任何复制通道应用程序线程，则无法全局更改复制格式（SET @@ GLOBAL.binlog_format或SET @@ PERSIST.binlog_format）。
在任何这些情况下尝试切换复制格式（或尝试设置当前复制格式）都会导致错误。但是，您可以随时使用PERSIST_ONLY（SET @@ PERSIST_ONLY.binlog_format）更改复制格式，因为此操作不会修改运行时全局系统变量值，并且仅在服务器重新启动后才生效。
不存在任何临时表时，建议不要在运行时切换复制格式，因为仅在使用基于语句的复制时才记录临时表，而对于基于行的复制和混合复制，则不记录它们。
在复制进行过程中切换复制格式也会导致问题。每个MySQL Server可以设置自己的并且只能设置自己的二进制日志记录格式（无论binlog_format是设置为全局范围还是会话范围，均为true）。这意味着更改复制主服务器上的日志记录格式不会导致从属服务器更改其日志记录格式以匹配。使用STATEMENT模式时，不会复制binlog_format系统变量。使用MIXED或ROW日志记录模式时，将复制它，但从属服务器将忽略它。
复制从站无法将以ROW日志记录格式接收的二进制日志条目转换为STATEMENT格式，以在其自己的二进制日志中使用。因此，如果主站执行此操作，则从站必须使用ROW或MIXED格式。在复制过程中将主数据库上的二进制日志记录格式从STATEMENT更改为ROW或MIXED时，正在复制到具有STATEMENT格式的从属数据库，这会导致复制失败并显示以下错误，例如错误执行行事件：'无法执行语句：无法写入二进制日志，因为语句为行格式，并且BINLOG_FORMAT = STATEMENT。当主服务器仍使用MIXED或ROW格式时，将从服务器上的二进制日志记录格式更改为STATEMENT格式也会导致相同类型的复制失败。为了安全地更改格式，必须停止复制并确保在主服务器和从服务器上都进行了相同的更改。
如果您使用的是InnoDB表，并且事务隔离级别为READ COMMITTED或READ UNCOMMITTED，则只能使用基于行的日志记录。可以将日志记录格式更改为STATEMENT，但是在运行时这样做会很快导致错误，因为InnoDB无法再执行插入。
将二进制日志格式设置为ROW时，使用基于行的格式将许多更改写入二进制日志。但是，某些更改仍然使用基于语句的格式。示例包括所有DDL（数据定义语言）语句，例如CREATE TABLE，ALTER TABLE或DROP TABLE。

使用基于行的二进制日志记录时，binlog_row_event_max_size系统变量及其相应的启动选项--binlog-row-event-max-size设置了行事件最大大小的软限制。默认值为8192字节，并且只能在服务器启动时更改该值。如果可能，将二进制日志中存储的行分组为大小不超过此设置的值的事件。如果事件无法拆分，则可以超过最大大小。
--binlog-row-event-max-size选项适用于能够进行基于行的复制的服务器。行以块大小存储在二进制日志中，块大小不超过此选项的值。该值必须是256的倍数。默认值为8192。
警告：使用基于语句的日志记录进行复制时，如果语句的设计方式使得数据修改不确定，则主数据库和从数据库上的数据可能会有所不同。也就是说，它由查询优化器决定。通常，即使在复制之外，这也不是一个好习惯。

		自动登录	找回密码
密码			立即加入

MySQL8.0大师之路：第11章：MySQL服务器管理-11.14 MySQL 设置二进制日志格式

最佳新人

活跃会员

热心会员

推广达人

宣传达人

灌水之王

突出贡献

优秀版主

荣誉管理

论坛元老