--binlog-row-event-max-size=N

使用基于行的二进制日志记录时，此设置是基于行的二进制日志事件的最大大小（以字节为单位）的软限制。在可能的情况下，存储在二进制日志中的行将分组到事件中，其大小不超过此设置的值。如果事件无法拆分，则最大大小可能会超过。该值必须为 256 的倍数（否则会被向下取整）。默认值为 8192 字节。

--log-bin[=base_name]

指定用于二进制日志文件的基名。启用二进制日志记录后，服务器会将所有更改数据的语句记录到二进制日志中，该日志用于备份和复制。二进制日志是一系列文件，它们具有基名和数字扩展名。--log-bin 选项值是日志序列的基名。服务器通过在基名中添加数字后缀来按顺序创建二进制日志文件。

如果您没有提供 --log-bin 选项，MySQL 会使用 binlog 作为二进制日志文件的默认基名。为了与早期版本兼容，如果您提供 --log-bin 选项但不带字符串或带空字符串，则基名默认为 host_name-bin，使用主机名。

二进制日志文件的默认位置是数据目录。您可以使用--log-bin选项指定备用位置，通过在基本名称前面添加一个绝对路径名来指定不同的目录。当服务器从二进制日志索引文件读取条目时（该文件跟踪已使用的二进制日志文件），它会检查该条目是否包含相对路径。如果包含，则会将路径的相对部分替换为使用--log-bin选项设置的绝对路径。二进制日志索引文件中记录的绝对路径保持不变；在这种情况下，必须手动编辑索引文件才能启用新的路径。二进制日志文件基本名称和任何指定的路径都可用作log_bin_basename系统变量。

在 MySQL 9.0 中，无论您是否指定 --log-bin 选项，二进制日志记录默认情况下都是启用的。唯一的例外是，如果您使用 mysqld 通过使用 --initialize 或 --initialize-insecure 选项手动初始化数据目录，在这种情况下，二进制日志记录默认情况下是禁用的。可以通过指定 --log-bin 选项在此情况下启用二进制日志记录。当二进制日志记录启用时，log_bin 系统变量（显示服务器上二进制日志记录的状态）将设置为 ON。

要禁用二进制日志记录，您可以在启动时指定 --skip-log-bin 或 --disable-log-bin 选项。如果指定了这两个选项中的任何一个，并且也指定了 --log-bin，则最后指定的选项优先。当二进制日志记录禁用时，log_bin 系统变量将设置为 OFF。

当服务器上使用 GTID 时，如果您在异常关闭后重新启动服务器时禁用二进制日志记录，一些 GTID 可能会丢失，导致复制失败。在正常关闭期间，当前二进制日志文件中的 GTID 集将保存到 mysql.gtid_executed 表中。在没有发生这种情况的异常关闭之后，在恢复期间，GTID 将从二进制日志文件添加到该表中，前提是二进制日志记录仍然启用。如果为服务器重启禁用了二进制日志记录，服务器将无法访问二进制日志文件以恢复 GTID，因此无法启动复制。在正常关闭后，可以安全地禁用二进制日志记录。

--log-replica-updates 和 --replica-preserve-commit-order 选项需要二进制日志记录。如果您禁用二进制日志记录，请省略这些选项，或者指定 --log-replica-updates=OFF 和 --skip-replica-preserve-commit-order。当指定 --skip-log-bin 或 --disable-log-bin 时，MySQL 默认情况下会禁用这些选项。如果您将 --log-replica-updates 或 --replica-preserve-commit-order 与 --skip-log-bin 或 --disable-log-bin 一起指定，则会发出警告或错误消息。

当启用二进制日志记录时，可以使用默认服务器 ID 启动服务器，但是，如果您没有通过设置 server_id 系统变量显式指定服务器 ID，则会发出信息消息。对于在复制拓扑中使用的服务器，您必须为每个服务器指定唯一的非零服务器 ID。

有关二进制日志的格式和管理的信息，请参阅 第 7.4.4 节“二进制日志”。

--log-bin-index[=file_name]

二进制日志索引文件的名称，其中包含二进制日志文件的名称。默认情况下，它与使用 --log-bin 选项为二进制日志文件指定的路径和基本名称相同，并且带有扩展名 .index。如果您没有指定 --log-bin，则默认二进制日志索引文件名是 binlog.index。如果您指定 --log-bin 选项，且没有字符串或为空字符串，则默认二进制日志索引文件名是 host_name-bin.index，使用主机名称。

有关二进制日志的格式和管理的信息，请参阅 第 7.4.4 节“二进制日志”。

--binlog-do-db=db_name

此选项以类似于 --replicate-do-db 影响复制的方式影响二进制日志记录。

此选项的效果取决于使用的是基于语句的日志记录格式还是基于行的日志记录格式，这与 --replicate-do-db 的效果取决于使用的是基于语句的复制还是基于行的复制相同。您应该牢记，用于记录给定语句的格式不一定与 binlog_format 值指示的格式相同。例如，DDL 语句（如 CREATE TABLE 和 ALTER TABLE）始终作为语句记录，而不考虑生效的日志记录格式，因此以下基于语句的 --binlog-do-db 规则始终适用于确定是否记录该语句。

基于语句的日志记录。 仅将那些默认数据库（即，由 USE 选择的数据库）为 db_name 的语句写入二进制日志。要指定多个数据库，请多次使用此选项，每个数据库一次；但是，这样做不会导致跨数据库语句（如 UPDATE some_db.some_table SET foo='bar'）在选择不同的数据库（或没有数据库）时被记录。

使用基于语句的日志记录时，以下不按预期工作的情况示例：如果服务器使用 --binlog-do-db=sales 启动，并且您发出以下语句，则 UPDATE 语句不会被记录

USE prices;
UPDATE sales.january SET amount=amount+1000;

这种“只需检查默认数据库” 行为的主要原因是，仅从语句本身很难知道是否应该复制它（例如，如果您使用的是多表 DELETE 语句或多表 UPDATE 语句，这些语句跨多个数据库执行）。如果不需要，则检查仅默认数据库而不是所有数据库的速度更快。

另一个可能不那么明显的案例发生在复制了给定数据库，即使在设置选项时没有指定它。如果服务器使用 --binlog-do-db=sales 启动，则以下 UPDATE 语句将被记录，即使 prices 未在设置 --binlog-do-db 时包含在内

USE sales;
UPDATE prices.discounts SET percentage = percentage + 10;

因为 sales 是发出 UPDATE 语句时的默认数据库，所以 UPDATE 将被记录。

基于行的日志记录。 日志记录仅限于数据库 db_name。仅记录对属于 db_name 的表的更改；默认数据库对此没有影响。假设服务器使用 --binlog-do-db=sales 启动，并且基于行的日志记录生效，然后执行以下语句

USE prices;
UPDATE sales.february SET amount=amount+100;

根据 UPDATE 语句，对 sales 数据库中的 february 表的更改将被记录；无论是否发出 USE 语句，都会发生这种情况。但是，当使用基于行的日志记录格式和 --binlog-do-db=sales 时，以下 UPDATE 所做的更改将不会被记录

USE prices;
UPDATE prices.march SET amount=amount-25;

即使将 USE prices 语句更改为 USE sales，UPDATE 语句的效果仍然不会写入二进制日志。

在 --binlog-do-db 处理方面，基于语句的日志记录与基于行的日志记录的另一个重要区别在于，对涉及多个数据库的语句的处理方式不同。假设服务器使用 --binlog-do-db=db1 启动，并且执行以下语句

USE db1;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

如果您使用的是基于语句的日志记录，则对两个表的更新都将写入二进制日志。但是，当使用基于行的格式时，仅记录对 table1 的更改；table2 位于不同的数据库中，因此不会被 UPDATE 更改。现在假设，不是 USE db1 语句，而是使用了 USE db4 语句

USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

在这种情况下，当使用基于语句的日志记录时，UPDATE 语句不会写入二进制日志。但是，当使用基于行的日志记录时，会记录对 table1 的更改，但不会记录对 table2 的更改——换句话说，仅记录对 --binlog-do-db 命名的数据库中的表的更改，默认数据库的选择对此行为没有影响。

--binlog-ignore-db=db_name

此选项以类似于 --replicate-ignore-db 影响复制的方式影响二进制日志记录。

此选项的效果取决于使用的是基于语句的日志格式还是基于行的日志格式，这与 --replicate-ignore-db 的效果取决于使用的是基于语句的复制还是基于行的复制的方式相同。您应该记住，用于记录给定语句的格式可能不一定是 binlog_format 值指示的格式。例如，DDL 语句，例如 CREATE TABLE 和 ALTER TABLE 始终记录为语句，而不考虑生效的日志格式，因此以下针对 --binlog-ignore-db 的基于语句的规则始终适用于确定是否记录该语句。

基于语句的日志记录。 告诉服务器不要记录任何默认数据库（即 USE 选择的数据库）为 db_name 的语句。

当没有默认数据库时，不会应用任何 --binlog-ignore-db 选项，并且此类语句始终会被记录。（错误 #11829838，错误 #60188）

基于行的格式。 告诉服务器不要记录对数据库 db_name 中任何表的更新。当前数据库无效。

当使用基于语句的日志记录时，以下示例不会像您预期的那样工作。假设服务器启动时使用 --binlog-ignore-db=sales，您发出以下语句

USE prices;
UPDATE sales.january SET amount=amount+1000;

在这种情况下，UPDATE 语句 会 被记录，因为 --binlog-ignore-db 仅适用于默认数据库（由 USE 语句确定）。由于语句中明确指定了 sales 数据库，因此该语句没有被过滤。但是，当使用基于行的日志记录时，UPDATE 语句的效果 不会 写入二进制日志，这意味着对 sales.january 表的更改不会被记录；在这种情况下，--binlog-ignore-db=sales 会导致对源中 sales 数据库副本的所有更改被忽略，以用于二进制日志记录。

要指定多个要忽略的数据库，请多次使用此选项，每个数据库使用一次。由于数据库名称可能包含逗号，因此如果您提供逗号分隔的列表，则该列表将被视为单个数据库的名称。

如果您使用的是跨数据库更新，并且您不希望记录这些更新，则不应使用此选项。

--binlog-checksum={NONE|CRC32}

启用此选项会导致源为写入二进制日志的事件写入校验和。设置为 NONE 以禁用，或设置为用于生成校验和的算法的名称；目前，仅支持 CRC32 校验和，并且 CRC32 是默认值。您不能在事务中更改此选项的设置。

--max-binlog-dump-events=N

此选项在内部由 MySQL 测试套件用于复制测试和调试。

--sporadic-binlog-dump-fail

此选项在内部由 MySQL 测试套件用于复制测试和调试。

binlog_cache_size

用于在事务期间保存对二进制日志更改的内存缓冲区的尺寸。

当在服务器上启用二进制日志记录（将 log_bin 系统变量设置为 ON）时，如果服务器支持任何事务性存储引擎，则会为每个客户端分配一个二进制日志缓存。如果事务数据超过内存缓冲区中的空间，则多余的数据将存储在临时文件中。当服务器上的二进制日志加密处于活动状态时，内存缓冲区不会被加密，但用于保存二进制日志缓存的任何临时文件都会被加密。在每个事务提交后，二进制日志缓存都会通过清除内存缓冲区以及截断（如果使用了）临时文件来重置。

如果您经常使用大型事务，则可以通过减少或消除对临时文件的写入需求来增加此缓存大小以获得更好的性能。 Binlog_cache_use 和 Binlog_cache_disk_use 状态变量可以用于调整此变量的大小。参见 第 7.4.4 节，“二进制日志”。

binlog_cache_size 仅设置事务缓存的大小；语句缓存的大小由 binlog_stmt_cache_size 系统变量控制。

binlog_checksum

启用后，此变量会导致源为二进制日志中的每个事件写入校验和。 binlog_checksum 支持值 NONE（禁用校验和）和 CRC32。默认值为 CRC32。当 binlog_checksum 被禁用（值 NONE）时，服务器通过写入和检查每个事件的事件长度（而不是校验和）来验证它是否仅将完整事件写入二进制日志。

将此变量在源上设置为副本无法识别的值会导致副本将其自己的 binlog_checksum 值设置为 NONE，并以错误停止复制。如果与旧副本的向后兼容性是一个问题，您可能希望将该值明确设置为 NONE。

MySQL 9.0 中的组复制支持校验和，因此组成员可以使用默认设置。

更改 binlog_checksum 的值会导致二进制日志被轮换，因为校验和必须为整个二进制日志文件写入，而不能仅为其中的一部分写入。您不能在事务中更改 binlog_checksum 的值。

当使用 binlog_transaction_compression 系统变量启用二进制日志事务压缩时，不会为压缩事务有效载荷中的单个事件写入校验和。相反，会为 GTID 事件写入校验和，以及为压缩的 Transaction_payload_event 写入校验和。

binlog_direct_non_transactional_updates

由于并发问题，当事务包含对事务表和非事务表的更新时，副本可能会变得不一致。MySQL 尝试通过将非事务性语句写入事务缓存来保持这些语句之间的因果关系，事务缓存在提交时被刷新。但是，当代表事务对非事务表进行的修改立即对其他连接可见时，问题就会出现，因为这些更改可能不会立即写入二进制日志。

binlog_direct_non_transactional_updates 变量提供了一种可能的解决此问题的方法。默认情况下，此变量被禁用。启用 binlog_direct_non_transactional_updates 会导致对非事务表的更新直接写入二进制日志，而不是写入事务缓存。

设置此系统变量的会话值是一个受限制的操作。会话用户必须拥有足够的权限来设置受限制的会话变量。参见 第 7.1.9.1 节，“系统变量权限”。

binlog_direct_non_transactional_updates 仅适用于使用基于语句的二进制日志记录格式复制的语句；也就是说，它仅在 binlog_format 的值为 STATEMENT 或 binlog_format 为 MIXED 并且给定语句正在使用基于语句的格式复制时有效。当二进制日志格式为 ROW 或 binlog_format 设置为 MIXED 并且给定语句正在使用基于行的格式复制时，此变量无效。

当二进制日志格式为 ROW 或 MIXED 时，此变量无效。

binlog_encryption

为此服务器上的二进制日志文件和中继日志文件启用加密。 OFF 是默认值。 ON 为二进制日志文件和中继日志文件设置加密。二进制日志记录不需要在服务器上启用即可启用加密，因此您可以在没有二进制日志的副本上加密中继日志文件。要使用加密，必须安装和配置密钥环插件以提供 MySQL Server 的密钥环服务。有关如何执行此操作的说明，请参见 第 8.4.4 节，“MySQL 密钥环”。任何支持的密钥环插件都可以用来存储二进制日志加密密钥。

当您首次启动启用二进制日志加密的服务器时，会在初始化二进制日志和中继日志之前生成一个新的二进制日志加密密钥。此密钥用于加密每个二进制日志文件（如果服务器启用了二进制日志记录）和中继日志文件（如果服务器启用了复制通道）的文件密码，并且从文件密码生成的更多密钥用于加密文件中的数据。中继日志文件会针对所有通道进行加密，包括组复制应用程序通道以及在激活加密后创建的新通道。二进制日志索引文件和中继日志索引文件永远不会被加密。

如果您在服务器运行时激活加密，此时会生成一个新的二进制日志加密密钥。唯一的例外是，如果之前在服务器上启用了加密，然后被禁用，在这种情况下，会再次使用之前使用的二进制日志加密密钥。二进制日志文件和中继日志文件会立即轮换，并且使用此二进制日志加密密钥加密新文件以及所有后续二进制日志文件和中继日志文件的文件密码。服务器上仍然存在的现有二进制日志文件和中继日志文件不会自动加密，但如果不再需要，您可以清除它们。

如果您通过将 binlog_encryption 系统变量更改为 OFF 来停用加密，二进制日志文件和中继日志文件会立即轮换，并且所有后续日志记录都不会加密。之前加密的文件不会自动解密，但服务器仍然能够读取它们。要激活或停用服务器运行时的加密，需要 BINLOG_ENCRYPTION_ADMIN 权限（或已弃用的 SUPER 权限）。组复制应用程序通道不包含在中继日志轮换请求中，因此这些通道的未加密日志记录直到在正常使用中轮换其日志时才开始。

有关二进制日志文件和中继日志文件加密的更多信息，请参见 第 19.3.2 节，“加密二进制日志文件和中继日志文件”。

binlog_error_action

控制服务器遇到错误时发生的情况，例如无法写入、刷新或同步二进制日志，这会导致源的二进制日志不一致，并且副本失去同步。

此变量默认为 ABORT_SERVER，这使得服务器在遇到二进制日志的此类错误时停止日志记录并关闭。重新启动后，恢复过程与意外服务器停止的情况相同（请参见 第 19.4.2 节，“处理副本的意外停止”）。

当 binlog_error_action 设置为 IGNORE_ERROR 时，如果服务器遇到此类错误，它将继续进行中的事务，记录错误，然后停止日志记录，并继续执行更新。要恢复二进制日志记录，必须再次启用 log_bin，这需要重新启动服务器。此设置提供与旧版 MySQL 的向后兼容性。

binlog_expire_logs_seconds

设置以秒为单位的二进制日志过期时间段。在过期时间段结束之后，可以自动删除二进制日志文件。可能的删除操作发生在启动时以及刷新二进制日志时。日志刷新发生在 第 7.4 节，“MySQL 服务器日志” 中所述的时间。

默认的二进制日志过期时间段为 2592000 秒，相当于 30 天（30*24*60*60 秒）。

可以通过将 binlog_expire_logs_auto_purge 系统变量设置为 OFF 来禁用二进制日志的自动清除。这优先于对 binlog_expire_logs_seconds 的任何设置。

要手动删除二进制日志文件，请使用 PURGE BINARY LOGS 语句。请参见 第 15.4.1.1 节，“PURGE BINARY LOGS 语句”。

binlog_expire_logs_auto_purge

启用或禁用二进制日志文件的自动清除。将此变量设置为 ON（默认值）启用自动清除；将它设置为 OFF 禁用自动清除。等待清除的间隔由 binlog_expire_logs_seconds 控制。

此变量对 PURGE BINARY LOGS 没有影响。

binlog_format

此系统变量设置二进制日志记录格式，可以是 STATEMENT、ROW 或 MIXED 之一。（请参见 第 19.2.1 节，“复制格式”。）此设置在服务器上启用二进制日志记录时生效，当 log_bin 系统变量设置为 ON 时，就会出现这种情况。在 MySQL 9.0 中，二进制日志记录默认启用，默认使用基于行的格式。

binlog_format 可以在启动时或运行时设置，但例外是，在某些情况下，运行时更改此变量是不可能的，或者会导致复制失败，如下所述。

默认值为 ROW。例外: 在 NDB Cluster 中，默认值为 MIXED；NDB Cluster 不支持基于语句的复制。

设置此系统变量的会话值是一个受限制的操作。会话用户必须拥有足够的权限来设置受限制的会话变量。参见 第 7.1.9.1 节，“系统变量权限”。

管理更改此变量生效时间以及生效持续时间的规则与其他 MySQL 服务器系统变量相同。有关更多信息，请参见 第 15.7.6.1 节，“SET 语法用于变量赋值”。

当指定 MIXED 时，使用基于语句的复制，但仅当仅基于行的复制保证能够产生正确结果时除外。例如，当语句包含可加载函数或 UUID() 函数时，就会发生这种情况。

有关在设置每个二进制日志记录格式时如何处理存储程序（存储过程和函数、触发器和事件）的详细信息，请参见 第 27.8 节，“存储程序二进制日志记录”。

运行时无法切换复制格式的情况例外

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

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

更改复制源服务器上的日志记录格式不会导致副本更改其日志记录格式以匹配。如果副本启用了二进制日志记录，并且更改导致副本使用 STATEMENT 格式日志记录，而源使用 ROW 或 MIXED 格式日志记录，则在复制进行时切换复制格式会导致问题。副本无法将以 ROW 日志记录格式接收的二进制日志条目转换为 STATEMENT 格式以供其自身的二进制日志使用，因此这种情况会导致复制失败。有关更多信息，请参见 第 7.4.4.2 节，“设置二进制日志格式”。

二进制日志格式会影响以下服务器选项的行为

这些影响将在各个选项的描述中详细讨论。

binlog_group_commit_sync_delay

控制二进制日志提交在将二进制日志文件同步到磁盘之前等待多长时间（以微秒为单位）。默认情况下，binlog_group_commit_sync_delay 设置为 0，这意味着没有延迟。将 binlog_group_commit_sync_delay 设置为微秒延迟可以使更多事务一起同步到磁盘，从而减少提交一组事务的总时间，因为较大的组每个组所需的单位时间更少。

当 sync_binlog=0 或 sync_binlog=1 设置时，binlog_group_commit_sync_delay 指定的延迟将在每次二进制日志提交组同步之前应用（或者在 sync_binlog=0 的情况下，在继续之前应用）。当 sync_binlog 设置为大于 1 的值 n 时，延迟将在每 n 个二进制日志提交组之后应用。

设置 binlog_group_commit_sync_delay 可以增加任何具有（或可能在故障转移后具有）副本的服务器上的并行提交事务的数量，因此可以增加副本上的并行执行。要从这种效果中获益，副本服务器必须设置 replica_parallel_type=LOGICAL_CLOCK。在设置 binlog_group_commit_sync_delay 时，重要的是要同时考虑源和副本的吞吐量。

设置 binlog_group_commit_sync_delay 也可以减少任何具有二进制日志的服务器（源服务器或副本服务器）对二进制日志的 fsync() 调用次数。

请注意，设置 binlog_group_commit_sync_delay 会增加服务器上事务的延迟，这可能会影响客户端应用程序。此外，在高并发工作负载下，延迟可能会增加争用，从而降低吞吐量。通常，设置延迟的好处超过了缺点，但应始终进行调整以确定最佳设置。

binlog_group_commit_sync_no_delay_count

在放弃由 binlog_group_commit_sync_delay 指定的当前延迟之前等待的最大事务数。如果 binlog_group_commit_sync_delay 设置为 0，则此选项无效。

binlog_max_flush_queue_time

binlog_max_flush_queue_time 已弃用，并且将在未来的 MySQL 版本中被删除。以前，此系统变量控制在继续从刷新队列读取事务之前继续进行组提交的时间（以微秒为单位）。它不再有任何作用。

binlog_order_commits

当此变量在复制源服务器上启用（这是默认值）时，发送到存储引擎的事务提交指令将在单个线程上进行序列化，以便事务始终以与写入二进制日志的相同顺序提交。禁用此变量允许使用多个线程发送事务提交指令。与二进制日志组提交结合使用，这可以防止单个事务的提交速率成为吞吐量的瓶颈，因此可能提高性能。

事务在所有参与的存储引擎都确认事务已准备好提交时写入二进制日志。然后，二进制日志组提交逻辑在它们的二进制日志写入完成后提交一组事务。当 binlog_order_commits 被禁用时，由于此过程使用多个线程，因此提交组中的事务可能以与它们在二进制日志中的顺序不同的顺序提交。（来自单个客户端的事务始终按时间顺序提交。）在许多情况下，这并不重要，因为在单独的事务中执行的操作应产生一致的结果，如果情况并非如此，则应使用单个事务。

如果你想确保源服务器和多线程副本上的事务历史记录保持一致，请在副本上设置 replica_preserve_commit_order=1。

binlog_rotate_encryption_master_key_at_startup

指定服务器启动时是否旋转二进制日志主密钥。二进制日志主密钥是用于加密服务器上二进制日志文件和中继日志文件的二进制日志加密密钥。当服务器第一次启动并启用二进制日志加密 (binlog_encryption=ON) 时，会生成一个新的二进制日志加密密钥并用作二进制日志主密钥。如果 binlog_rotate_encryption_master_key_at_startup 系统变量也设置为 ON，则无论何时重启服务器，都会生成另一个二进制日志加密密钥，并用作所有后续二进制日志文件和中继日志文件的二进制日志主密钥。如果 binlog_rotate_encryption_master_key_at_startup 系统变量设置为 OFF（默认值），则服务器重启后会再次使用现有的二进制日志主密钥。有关二进制日志加密密钥和二进制日志主密钥的更多信息，请参见 第 19.3.2 节，“加密二进制日志文件和中继日志文件”。

binlog_row_event_max_size

当使用基于行的二进制日志记录时，此设置是基于行的二进制日志事件的最大大小（以字节为单位）的软限制。在可能的情况下，存储在二进制日志中的行将被分组到大小不超过此设置值的事件中。如果无法拆分事件，则可能会超过最大大小。默认值为 8192 字节。

此全局系统变量是只读的，只能在服务器启动时设置。因此，它的值只能通过使用 PERSIST_ONLY 关键字或 @@persist_only 限定符与 SET 语句一起修改。

binlog_row_image

对于 MySQL 基于行的复制，此变量确定如何将行图像写入二进制日志。

设置此系统变量的会话值是一个受限制的操作。会话用户必须拥有足够的权限来设置受限制的会话变量。参见 第 7.1.9.1 节，“系统变量权限”。

在 MySQL 基于行的复制中，每个行更改事件包含两个图像，一个 “before” 图像，其列在搜索要更新的行时与其匹配，以及一个 “after” 图像，其中包含更改。通常，MySQL 会为 before 和 after 图像记录完整行（即所有列）。但是，严格来说，并非必须在两个图像中都包含所有列，并且我们通常可以通过仅记录实际需要的列来节省磁盘、内存和网络使用量。

对于 before 图像，仅记录唯一标识行所需的最小列集。如果包含该行的表具有主键，则仅主键列写入二进制日志。否则，如果该表具有唯一键，并且所有列都是 NOT NULL，则只需要记录唯一键中的列。（如果表既没有主键，也没有没有任何 NULL 列的唯一键，则所有列都必须在 before 图像中使用并记录。）在 after 图像中，只需要记录实际上已更改的列。

你可以使用 binlog_row_image 系统变量使服务器记录完整行或最小行。此变量实际上接受三个可能值中的一个，如下所示

默认值为 full。

当使用 minimal 或 noblob 时，仅当以下条件对源表和目标表都成立时，才能保证删除和更新对于给定表正确工作

（换句话说，表必须相同，除了可能不是表主键一部分的索引。）

如果不满足这些条件，则目标表中的主键列值可能不足以提供删除或更新的唯一匹配。在这种情况下，不会发出警告或错误；源和副本会默默地发生分歧，从而破坏一致性。

当二进制日志记录格式为 STATEMENT 时，设置此变量无效。当 binlog_format 为 MIXED 时，binlog_row_image 的设置将应用于使用基于行的格式记录的更改，但此设置对作为语句记录的更改没有影响。

在全局或会话级别设置 binlog_row_image 不会导致隐式提交；这意味着可以在事务进行期间更改此变量，而不会影响事务。

binlog_row_metadata

配置使用基于行的日志记录时添加到二进制日志的表元数据的数量。当设置为 MINIMAL（默认值）时，仅记录与 SIGNED 标志、列字符集和几何类型相关的元数据。当设置为 FULL 时，将记录表的完整元数据，例如列名、ENUM 或 SET 字符串值、PRIMARY KEY 信息等。

扩展元数据用于以下目的

binlog_row_value_options

当设置为 PARTIAL_JSON 时，这将启用对仅修改 JSON 文档一小部分的更新使用空间效率高的二进制日志格式，这会导致基于行的复制仅将 JSON 文档的修改部分写入更新的二进制日志中的后镜像，而不是写入完整文档（参见 JSON 值的局部更新）。这适用于使用任何 JSON_SET()、JSON_REPLACE() 和 JSON_REMOVE() 序列修改 JSON 列的 UPDATE 语句。如果服务器无法生成局部更新，则改用完整文档。

默认值为一个空字符串，它将禁用该格式的使用。要取消设置 binlog_row_value_options 并恢复为写入完整的 JSON 文档，请将其值设置为空字符串。

设置此系统变量的会话值是一个受限制的操作。会话用户必须拥有足够的权限来设置受限制的会话变量。参见 第 7.1.9.1 节，“系统变量权限”。

binlog_row_value_options=PARTIAL_JSON 仅在启用二进制日志记录且 binlog_format 设置为 ROW 或 MIXED 时生效。基于语句的复制 始终 仅记录 JSON 文档的修改部分，无论 binlog_row_value_options 设置为任何值。为了最大限度地节省空间，请将 binlog_row_image=NOBLOB 或 binlog_row_image=MINIMAL 与此选项一起使用。 binlog_row_image=FULL 存储的空间比这两者都少，因为完整的 JSON 文档存储在前镜像中，而局部更新仅存储在后镜像中。

mysqlbinlog 输出以事件的形式包含局部 JSON 更新，这些事件使用 BINLOG 语句以 base-64 字符串的形式编码。如果指定了 --verbose 选项，mysqlbinlog 将使用伪 SQL 语句将局部 JSON 更新显示为可读的 JSON。

如果副本上的 JSON 文档无法应用修改，MySQL 复制将生成错误。这包括无法找到路径。请注意，即使有此安全检查和其他安全检查，如果副本上的 JSON 文档与源上的 JSON 文档不同，并且应用了局部更新，理论上仍然有可能在副本上生成有效的但意外的 JSON 文档。

binlog_rows_query_log_events

此系统变量仅影响基于行的日志记录。启用后，它会导致服务器将信息日志事件（如行查询日志事件）写入其二进制日志。此信息可用于调试和相关目的，例如在无法从行更新重建原始查询时获取在源上发出的原始查询。

设置此系统变量的会话值是一个受限制的操作。会话用户必须拥有足够的权限来设置受限制的会话变量。参见 第 7.1.9.1 节，“系统变量权限”。

这些信息事件通常会被读取二进制日志的 MySQL 程序忽略，因此在从备份进行复制或恢复时不会造成任何问题。要查看它们，请使用 mysqlbinlog 的 --verbose 选项两次增加详细程度，可以是 -vv 或 --verbose --verbose。

binlog_stmt_cache_size

二进制日志用于保存事务期间发出的非事务性语句的内存缓冲区的尺寸。

当服务器上启用了二进制日志记录（log_bin 系统变量设置为 ON）时，如果服务器支持任何事务性存储引擎，则会为每个客户端分配单独的二进制日志事务和语句缓存。如果用于事务的非事务性语句的数据超过了内存缓冲区中的空间，则多余的数据将存储在临时文件中。当服务器上启用了二进制日志加密时，内存缓冲区不会被加密，但用于保存二进制日志缓存的任何临时文件都会被加密。在每个事务提交后，二进制日志语句缓存会通过清除内存缓冲区并在使用临时文件时截断临时文件来重置。

如果在事务期间经常使用大型非事务性语句，可以增加此缓存尺寸以获得更好的性能，方法是减少或消除写入临时文件的需要。 Binlog_stmt_cache_use 和 Binlog_stmt_cache_disk_use 状态变量可用于调整此变量的尺寸。参见 第 7.4.4 节，“二进制日志”。

binlog_cache_size 系统变量设置事务缓存的尺寸。

binlog_transaction_compression

启用对写入此服务器上的二进制日志文件的交易进行压缩。 OFF 为默认值。使用 binlog_transaction_compression_level_zstd 系统变量设置用于压缩的 zstd 算法的级别。

设置 binlog_transaction_compression 不会立即生效，而是适用于所有后续的 START REPLICA 语句。

当启用二进制日志事务压缩时，事务有效负载会被压缩，然后作为单个事件（Transaction_payload_event）写入二进制日志文件。压缩后的事务有效负载在通过复制流发送到副本、其他组复制组成员或客户端（如 mysqlbinlog）时仍保持压缩状态，并且以压缩状态写入中继日志。因此，二进制日志事务压缩在交易的起源者和接收者（及其备份）上都节省了存储空间，并且在交易在服务器实例之间发送时节省了网络带宽。

为了使 binlog_transaction_compression=ON 直接生效，必须在服务器上启用二进制日志记录。当 MySQL 9.0 服务器实例没有二进制日志时，它可以接收、处理和显示压缩后的事务有效负载，而无论其 binlog_transaction_compression 的值如何。此类服务器实例接收到的压缩后的事务有效负载以压缩状态写入中继日志，因此它们间接受益于复制拓扑中其他服务器执行的压缩。

此系统变量不能在事务的上下文中更改。设置此系统变量的会话值是一个受限操作。会话用户必须具有足够的权限来设置受限的会话变量。参见 第 7.1.9.1 节，“系统变量权限”。

有关二进制日志事务压缩的更多信息，包括哪些事件被压缩以及哪些事件未被压缩的详细信息，以及在使用事务压缩时行为的变化，请参见 第 7.4.4.5 节，“二进制日志事务压缩”。

可以使用 ndb_log_transaction_compression 系统变量为 NDB 启用此功能。此外，在命令行或 my.cnf 文件中设置 --binlog-transaction-compression=ON 会导致在服务器启动时启用 ndb_log_transaction_compression。有关更多信息，请参见该变量的说明。

binlog_transaction_compression_level_zstd

设置此服务器上二进制日志事务压缩的压缩级别，该压缩由 binlog_transaction_compression 系统变量启用。该值为一个整数，它确定压缩工作量，从 1（最低工作量）到 22（最高工作量）。如果未指定此系统变量，则压缩级别设置为 3。

设置 binlog_transaction_compression_level_zstd 不会立即生效，而是适用于所有后续的 START REPLICA 语句。

随着压缩级别的提高，数据压缩率也会提高，从而减少了事务有效负载所需的存储空间和网络带宽。但是，数据压缩所需的工作量也会增加，这会占用起源服务器的时间、CPU 和内存资源。压缩工作量的增加与数据压缩率的增加之间没有线性关系。

此系统变量不能在事务的上下文中更改。设置此系统变量的会话值是一个受限操作。会话用户必须具有足够的权限来设置受限的会话变量。参见 第 7.1.9.1 节，“系统变量权限”。

此变量对 NDB 表上事务的日志记录没有影响；请改用 ndb_log_transaction_compression_level_zstd。

binlog_transaction_dependency_history_size

设置在内存中保留的行哈希数的上限，这些行哈希用于查找最后修改给定行的交易。一旦达到此数量的哈希值，历史记录就会被清除。

log_bin

显示服务器上二进制日志记录的状态，可以是启用（ON）或禁用（OFF）。启用二进制日志记录后，服务器会将所有更改数据的语句记录到二进制日志中，二进制日志用于备份和复制。 ON 表示二进制日志可用，OFF 表示二进制日志未在使用。 --log-bin 选项可用于指定二进制日志的基名和位置。

在早期的 MySQL 版本中，二进制日志记录默认情况下是禁用的，如果指定了 --log-bin 选项，则会启用二进制日志记录。二进制日志记录默认情况下是启用的，log_bin 系统变量设置为 ON，无论是否指定 --log-bin 选项。例外情况是，如果使用 mysqld 通过使用 --initialize 或 --initialize-insecure 选项手动初始化数据目录，在这种情况下，二进制日志记录默认情况下是禁用的。在这种情况下，可以通过指定 --log-bin 选项启用二进制日志记录。

如果在启动时指定了--skip-log-bin 或 --disable-log-bin 选项，则会禁用二进制日志记录，并将log_bin 系统变量设置为OFF。如果同时指定了这两个选项和--log-bin 选项，则最后指定的选项优先。

有关二进制日志的格式和管理的信息，请参阅 第 7.4.4 节“二进制日志”。

log_bin_basename

保存二进制日志文件的基名称和路径，可以通过--log-bin 服务器选项设置。最大变量长度为 256。在 MySQL 9.0 中，如果未提供--log-bin 选项，则默认基名称为binlog。为了与 MySQL 5.7 保持兼容性，如果在提供--log-bin 选项时未提供任何字符串或提供空字符串，则默认基名称为host_name-bin，使用主机名。默认位置是数据目录。

log_bin_index

保存二进制日志索引文件的基名称和路径，可以通过--log-bin-index 服务器选项设置。最大变量长度为 256。

log_bin_trust_function_creators

此变量在启用二进制日志记录时适用。它控制是否可以信任存储函数创建者不会创建可能导致将不安全事件写入二进制日志的存储函数。如果设置为 0（默认值），则不允许用户创建或更改存储函数，除非他们除了CREATE ROUTINE 或 ALTER ROUTINE 权限外还具有SUPER 权限。设置为 0 还会强制执行以下限制：函数必须用DETERMINISTIC 特性声明，或者用READS SQL DATA 或 NO SQL 特性声明。如果变量设置为 1，MySQL 不会强制执行对存储函数创建的这些限制。此变量也适用于触发器创建。参见第 27.8 节，“存储程序二进制日志记录”.

log_replica_updates

log_replica_updates 指定副本服务器是否应该将从复制源服务器接收到的更新记录到副本自己的二进制日志中。

启用此变量会导致副本将从源接收到的更新（由复制 SQL 线程执行）写入副本自己的二进制日志中。二进制日志记录由--log-bin 选项控制，默认情况下处于启用状态，也必须在副本上启用，才能记录更新。参见第 19.1.6 节，“复制和二进制日志记录选项和变量”。log_replica_updates 默认情况下处于启用状态，除非您指定--skip-log-bin 来禁用二进制日志记录，在这种情况下，MySQL 默认情况下还会禁用副本更新日志记录。如果您需要在启用二进制日志记录时禁用副本更新日志记录，请在副本服务器启动时指定--log-replica-updates=OFF。

启用log_replica_updates 使得可以将复制服务器链接起来。例如，您可能希望使用以下安排设置复制服务器

A -> B -> C

这里，A 充当副本B 的源，B 充当副本C 的源。为了使这能够正常工作，B 必须同时是源和副本。在启用二进制日志记录并启用log_replica_updates 的情况下（这是默认设置），从A 接收到的更新由B 记录到其二进制日志中，因此可以传递到C。

log_slave_updates

log_replica_updates 的弃用别名。

log_statements_unsafe_for_binlog

如果遇到错误 1592，则控制是否将生成的警告添加到错误日志中。

master_verify_checksum

source_verify_checksum 的弃用别名。

max_binlog_cache_size

如果事务需要超过此字节数，服务器会生成Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage 错误。当gtid_mode 不为ON 时，建议的最大值为 4GB，因为在这种情况下，MySQL 无法使用大于 4GB 的二进制日志位置；当gtid_mode 为ON 时，此限制不适用，并且服务器可以使用任意大小的二进制日志位置。

如果由于gtid_mode 不为ON 或由于其他原因，您需要确保二进制日志不超过给定大小maxsize，则应根据此处显示的公式设置此变量

max_binlog_cache_size < 
  (((maxsize - max_binlog_size) / max_connections) - 1000) / 1.2

此计算考虑了以下条件

max_binlog_cache_size 仅设置事务缓存的大小；语句缓存的上限由max_binlog_stmt_cache_size 系统变量控制。

max_binlog_cache_size 对会话的可见性与binlog_cache_size 系统变量相同；换句话说，更改其值只会影响在更改值后启动的新会话。

max_binlog_size

如果写入二进制日志导致当前日志文件大小超过此变量的值，服务器会轮换二进制日志（关闭当前文件并打开下一个文件）。最小值为 4096 字节。最大值和默认值为 1GB。加密的二进制日志文件具有额外的 512 字节标头，该标头包含在max_binlog_size 中。

事务以一个块的形式写入二进制日志，因此不会被拆分到多个二进制日志中。因此，如果您有大型事务，您可能会看到二进制日志文件的大小大于max_binlog_size。

如果max_relay_log_size 为 0，则max_binlog_size 的值也适用于中继日志。

在服务器上使用 GTID 时，当达到max_binlog_size 时，如果无法访问系统表mysql.gtid_executed 来写入当前二进制日志文件中的 GTID，则无法轮换二进制日志。在这种情况下，服务器将根据其binlog_error_action 设置进行响应。如果设置了IGNORE_ERROR，则会将错误记录到服务器上，并停止二进制日志记录；或者，如果设置了ABORT_SERVER，则服务器会关闭。

max_binlog_stmt_cache_size

如果事务中的非事务性语句需要超过此字节数的内存，服务器会生成错误。最小值为 4096。最大值和默认值在 32 位平台上为 4GB，在 64 位平台上为 16EB（艾字节）。

max_binlog_stmt_cache_size 仅设置语句缓存的大小；事务缓存的上限完全由max_binlog_cache_size 系统变量控制。

original_commit_timestamp

用于复制的内部使用。在副本上重新执行事务时，将其设置为事务在原始源上提交的时间，以自纪元以来的微秒数衡量。这允许将原始提交时间戳传播到整个复制拓扑中。

设置此系统变量的会话值是一个受限操作。会话用户必须具有REPLICATION_APPLIER 权限（参见第 19.3.3 节，“复制权限检查”），或者具有足够的权限来设置受限会话变量（参见第 7.1.9.1 节，“系统变量权限”）。但是，请注意，此变量并非供用户设置；它由复制基础设施自动设置。

source_verify_checksum

启用source_verify_checksum 会导致源通过检查校验和来验证从二进制日志中读取的事件，并在发生不匹配时停止并报错。source_verify_checksum 默认情况下处于禁用状态；在这种情况下，源使用二进制日志中的事件长度来验证事件，以便只从二进制日志中读取完整的事件。

sql_log_bin

此变量控制当前会话是否启用写入二进制日志（假设二进制日志本身已启用）。默认值为 ON。要禁用或启用当前会话的二进制日志记录，请将会话 sql_log_bin 变量设置为 OFF 或 ON。

将此变量设置为 OFF 以使会话暂时禁用二进制日志记录，以便在对不想复制到副本的源进行更改时进行操作。

设置此系统变量的会话值是一个受限制的操作。会话用户必须拥有足够的权限来设置受限制的会话变量。参见 第 7.1.9.1 节，“系统变量权限”。

无法在事务或子查询中设置 sql_log_bin 的会话值。

将此变量设置为 OFF 将阻止二进制日志中事务分配 GTID。如果您使用 GTID 进行复制，这意味着即使稍后再次启用二进制日志记录，从此时写入日志的 GTID 也不包括在此期间发生的任何事务，因此实际上这些事务将丢失。

sync_binlog

控制 MySQL 服务器将二进制日志同步到磁盘的频率。

对于使用 InnoDB 和事务的复制设置，要获得最大的耐久性和一致性，请使用以下设置