复制之所以有效,是因为写入二进制日志的事件是从源读取,然后在副本上处理。这些事件根据事件的类型以不同的格式记录在二进制日志中。使用的不同复制格式对应于在源的二进制日志中记录事件时使用的二进制日志记录格式。二进制日志记录格式与复制过程中使用的术语之间的对应关系为
使用基于语句的二进制日志记录时,源将 SQL 语句写入二进制日志。源到副本的复制通过在副本上执行 SQL 语句来实现。这被称为基于语句的复制(可以简称为SBR),它对应于 MySQL 基于语句的二进制日志记录格式。
使用基于行的日志记录时,源将事件写入二进制日志,这些事件指示如何更改单个表行。源到副本的复制通过将表示表行更改的事件复制到副本来实现。这被称为基于行的复制(可以简称为RBR)。
基于行的日志记录是默认方法。
您还可以配置 MySQL 使用基于语句和基于行的日志记录的混合,具体取决于对要记录的更改最适合哪种方法。这被称为混合格式日志记录。使用混合格式日志记录时,默认情况下使用基于语句的日志。根据某些语句以及使用的存储引擎,日志将在特定情况下自动切换到基于行的日志。使用混合格式的复制被称为混合基于的复制或混合格式复制。有关更多信息,请参见第 7.4.4.3 节,“混合二进制日志记录格式”。
NDB 集群. MySQL NDB Cluster 8.4 中的默认二进制日志记录格式为ROW
。NDB Cluster 复制使用基于行的复制;即NDB
存储引擎与基于语句的复制不兼容。有关更多信息,请参见第 25.7.2 节,“NDB 集群复制的一般要求”。
使用MIXED
格式时,二进制日志记录格式部分由使用的存储引擎和正在执行的语句决定。有关混合格式日志记录以及管理不同日志记录格式支持的规则的更多信息,请参见第 7.4.4.3 节,“混合二进制日志记录格式”。
运行中的 MySQL 服务器的日志格式由设置 binlog_format
服务器系统变量控制。此变量可以设置会话或全局范围。关于何时以及如何生效的新设置规则与其他 MySQL 服务器系统变量相同。为当前会话设置变量仅在该会话结束之前有效,并且更改对其他会话不可见。全局设置变量对连接更改后的客户端生效,但不适用于任何当前客户端会话,包括设置变量的会话。要使全局系统变量设置永久生效,以便在服务器重启后应用,您必须在选项文件中设置它。有关更多信息,请参见 第 15.7.6.1 节,“SET 语法用于变量赋值”。
在某些情况下,您无法在运行时更改二进制日志格式,或者这样做会导致复制失败。请参见 第 7.4.4.2 节,“设置二进制日志格式”。
更改全局 binlog_format
值需要足够的权限来设置全局系统变量。更改会话 binlog_format
值需要足够的权限来设置受限会话系统变量。请参见 第 7.1.9.1 节,“系统变量权限”。
更改二进制日志格式(binlog_format
系统变量)在 MySQL 8.0 中已弃用;在未来的 MySQL 版本中,您可能期望 binlog_format
完全被移除,而基于行的格式将成为 MySQL 使用的唯一日志格式。
基于语句的复制和基于行的复制格式具有不同的问题和限制。有关它们相对优缺点的比较,请参见 第 19.2.1.1 节,“基于语句的复制和基于行的复制的优缺点”。
对于基于语句的复制,您可能会遇到复制存储例程或触发器的問題。您可以通过使用基于行的复制来避免这些问题。有关更多信息,请参见 第 27.7 节,“存储程序二进制日志记录”。