--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 8.4 中，无论您是否指定 --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 启动服务器，则即使在设置 --binlog-do-db 时未包含 prices，也会记录以下 UPDATE 语句

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

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

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

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

sales 数据库中 february 表的更改将根据 UPDATE 语句记录；无论是否发出了 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 8.4 中的组复制支持校验和，因此组成员可以使用默认设置。

更改 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 服务器的密钥环服务。有关执行此操作的说明，请参阅 第 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 8.4 中，默认情况下启用二进制日志记录，并且默认情况下使用基于行的格式。

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

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

设置此系统变量的会话值是受限操作。会话用户必须具有足够的权限才能设置受限的会话变量。请参阅 第 7.1.9.1 节“系统变量权限”。

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

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

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

在某些情况下，您无法在运行时切换复制格式

尝试在上述任何情况下切换复制格式（或尝试设置当前复制格式）都会导致错误。但是，您可以使用 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 基于行的复制中，每个行更改事件都包含两个映像：一个在搜索要更新的行时与其列匹配的“之前”映像，以及一个包含更改的“之后”映像。通常，MySQL 会为之前和之后映像记录完整行（即所有列）。但是，并非必须在两个映像中都包含所有列，而且我们通常可以通过仅记录实际需要的列来节省磁盘、内存和网络使用量。

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

您可以使用 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 输出包含使用 BINLOG 语句编码为 base-64 字符串的事件形式的部分 JSON 更新。如果指定了 --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 8.4 服务器实例没有二进制日志时，无论其 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 8.4 中，如果没有提供 --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.7 节“存储程序二进制日志记录”。

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（默认设置）的情况下，B 会将其从 A 接收到的更新记录到其二进制日志中，因此可以传递到 C。

log_slave_updates

log_replica_updates 的已弃用别名。

log_statements_unsafe_for_binlog

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

master_verify_checksum

source_verify_checksum 的已弃用别名。

max_binlog_cache_size

如果某个事务需要超过此数量的字节，则服务器会生成 多语句事务需要的存储空间超过“max_binlog_cache_size”字节 错误。当 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 和事务的复制设置中获得最大可能的持久性和一致性，请使用以下设置