暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

5.4.4.2设置二进制日志格式

原创 由迪 2020-08-06
1454

您可以通过使用启动MySQL服务器来显式选择二进制日志记录格式 。支持的值为: --binlog-format=*type*type

  • 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值需要足够的特权来设置受限制的会话系统变量。请参见第5.1.9.1节“系统变量特权”

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

  • 对数据库进行许多小更改的会话可能要使用基于行的日志记录。
  • 执行与WHERE子句中的许多行匹配的更新的会话 可能要使用基于语句的日志记录,因为与多行记录相比,记录几条语句效率更高。
  • 有些语句需要在源上执行很多时间,但是导致仅修改了几行。因此,使用基于行的日志记录来复制它们可能是有益的。

当您无法在运行时切换复制格式时,会有一些例外情况:

  • 复制格式不能从存储的函数或触发器中更改。
  • 如果NDB启用了存储引擎。
  • 如果会话具有打开的临时表,则不能为该会话(SET @@SESSION.binlog_format)更改复制格式。
  • 如果任何复制通道都有打开的临时表,则不能全局(SET @@GLOBAL.binlog_formatSET @@PERSIST.binlog_format)更改复制格式。
  • 如果当前正在运行任何复制通道应用程序线程,则不能全局(SET @@GLOBAL.binlog_formatSET @@PERSIST.binlog_format)更改复制格式。

在任何这些情况下尝试切换复制格式(或尝试设置当前复制格式)都会导致错误。但是,您可以随时使用PERSIST_ONLYSET @@PERSIST_ONLY.binlog_format)更改复制格式,因为此操作不会修改运行时全局系统变量值,并且仅在服务器重启后才生效。

不存在任何临时表时,建议不要在运行时切换复制格式,因为仅在使用基于语句的复制时才记录临时表,而对于基于行的复制和混合复制,则不记录它们。

在复制进行过程中切换复制格式也会导致问题。每个MySQL Server都可以设置自己的并且只能设置自己的二进制日志记录格式(无论binlog_format是全局范围还是会话范围,都为true )。这意味着更改复制源服务器上的日志记录格式不会导致副本更改其日志记录格式以匹配。使用 STATEMENT模式时, binlog_format不会复制系统变量。使用MIXEDROW记录模式时,它已被复制但被副本忽略。

副本无法将以ROW日志记录格式 接收的二进制日志条目 STATEMENT转换为在其自己的二进制日志中使用的格式。因此,如果源使用副本,则副本必须使用ROWMIXED格式化。从更改源上的二进制日志记录格式 STATEMENTROWMIXED同时复制正在进行与副本STATEMENT格式可能会导致复制失败,错误,例如错误执行行事件:“无法执行语句:自言是行不可能写入二进制日志格式,BINLOG_FORMAT = STATEMENT。” 将副本上的二进制日志记录格式更改为STATEMENT 当源仍在使用时格式化MIXEDROW格式化也会导致相同类型的复制失败。为了安全地更改格式,必须停止复制并确保对源和副本进行相同的更改。

如果使用InnoDB表,并且事务隔离级别为READ COMMITTEDREAD UNCOMMITTED,则只能使用基于行的日志记录。这是 可能的更改日志格式 STATEMENT,但在运行时引线这样做非常迅速地错误,因为InnoDB不能再进行插入。

将二进制日志格式设置ROW为时,使用基于行的格式将许多更改写入二进制日志。但是,某些更改仍然使用基于语句的格式。实例包括所有DDL(数据定义语言)语句,例如CREATE TABLEALTER TABLE,或 DROP TABLE

使用基于行的二进制日志记录时, binlog_row_event_max_size 系统变量及其相应的启动选项 --binlog-row-event-max-size对行事件的最大大小设置了软限制。默认值为8192字节,并且只能在服务器启动时更改该值。如果可能,将二进制日志中存储的行分组为大小不超过此设置值的事件。如果事件无法拆分,则可以超过最大大小。

--binlog-row-event-max-size 选项可用于能够进行基于行的复制的服务器。将行以块的形式存储在二进制日志中,块的大小不超过此选项的值(以字节为单位)。该值必须是256的倍数。默认值为8192。

警告

当使用基于语句的日志记录进行复制时,如果以一种不确定的方式修改数据的方式设计语句,则源和副本上的数据可能会有所不同 。也就是说,它由查询优化器决定。通常,即使在复制之外,这也不是一个好习惯。有关此问题的详细说明,请参见 第B.3.7节“ MySQL中的已知问题”

「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论