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

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

当 GTIDs 在服务器上使用时，如果您在异常关闭后重新启动服务器时禁用二进制日志记录，一些 GTIDs 可能会丢失，导致复制失败。在正常关闭时，当前二进制日志文件中的 GTID 集将保存在 mysql.gtid_executed 表中。在异常关闭后，服务器无法访问二进制日志文件以恢复 GTIDs，因此无法启动复制。只有在正常关闭后，二进制日志记录才能安全地禁用。

如果您禁用二进制日志记录，--log-replica-updates 和 --replica-preserve-commit-order 选项将被禁用。如果您禁用二进制日志记录，或者指定 --log-replica-updates=OFF 和 --skip-replica-preserve-commit-order。MySQL 在 --skip-log-bin 或 --disable-log-bin 指定时，默认情况下禁用这些选项。如果您同时指定 --log-replica-updates 或 --replica-preserve-commit-order 和 --skip-log-bin 或 --disable-log-bin，将发出警告或错误消息。

在 MySQL 5.7 中，启用二进制日志记录时需要指定服务器 ID，否则服务器将无法启动。在 MySQL 8.3 中，server_id 系统变量默认设置为 1。现在可以在启用二进制日志记录时使用默认服务器 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;

对 february 表在 sales 数据库中的更改将根据 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 更改。现在假设，instead of the 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 总是作为语句记录，而不考虑当前的日志记录格式。

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

当没有默认数据库时，不应用任何 --binlog-ignore-db 选项，这些语句总是被记录。（Bug #11829838, Bug #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.3 中的组复制支持校验和，因此组成员可以使用默认设置。

更改 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.3 中，默认启用二进制日志记录，并使用基于行的格式。

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) 在任何时候更改复制格式，因为这项操作不修改 runtime 全局系统变量值，并且只有在服务器重新启动后生效。

在运行时切换复制格式不建议在存在临时表时，因为临时表仅在使用基于语句的复制时记录，而在使用基于行的复制和混合复制时不记录。

在复制源服务器上更改日志格式不会导致副本更改其日志格式以匹配。切换复制格式时，如果副本启用了二进制日志记录，并且更改导致副本使用 STATEMENT 格式日志记录，而源服务器使用 ROW 或 MIXED 格式日志记录。这可能会导致复制失败。有关更多信息，请参阅 第 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 个二进制日志提交组之后。

设置 binlog_group_commit_sync_delay 可以增加任何服务器（包括可能在故障转移后成为副本的服务器）上的并发提交事务数量，从而增加副本服务器上的并发执行。要受益于这个效果，副本服务器必须设置 replica_parallel_type=LOGICAL_CLOCK，并且当 binlog_transaction_dependency_tracking=COMMIT_ORDER 也被设置时，效果更明显。在调整 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 版本中删除。以前，该系统变量控制了从 flush 队列中读取事务的时间（以微秒为单位），以便继续进行组提交。现在，它不再有任何效果。

binlog_order_commits

当该变量在复制源服务器上启用时（默认情况下），存储引擎的事务提交指令将在单个线程上序列化，以便事务总是按照二进制日志中的顺序提交。禁用该变量允许事务提交指令使用多个线程。这与二进制日志组提交结合使用，可以防止单个事务的提交率成为吞吐量的瓶颈，从而可能提高性能。

事务在二进制日志中写入时，所有存储引擎都确认事务准备提交。然后，二进制日志组提交逻辑提交事务组，事务的二进制日志写入后。当 binlog_order_commits 禁用时，因为多个线程用于此过程，事务组中的事务可能以不同的顺序提交，而不是二进制日志中的顺序。（来自单个客户端的事务总是按chronological顺序提交。）在许多情况下，这并不重要，因为单独的事务应该产生一致的结果，如果不是这样，应该使用单个事务。

如果您想确保源和多线程副本上的事务历史记录保持相同，设置 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 节，“Encrypting Binary Log Files and Relay Log Files”。

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 图像，只需要记录最少的列来唯一标识行。如果表包含主键，则只需记录主键列或列。如果表包含唯一键且所有列均不为空，则只需记录唯一键中的列。（如果表既没有主键也没有唯一键，或者唯一键中有空列，则必须记录所有列。）在 after 图像中，只需记录实际更改的列。

您可以使用 binlog_row_image 系统变量来控制服务器记录完整或最小的行。

默认值是 完整。

使用 最小 或 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 部分更新）。这适用于使用 UPDATE 语句修改 JSON 列时，使用 JSON_SET()、JSON_REPLACE() 和 JSON_REMOVE() 序列。如果服务器无法生成部分更新，则使用完整的文档。

默认值为空字符串，禁用该格式。要取消设置 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 文档存储在 before-image 中，而部分更新仅存储在 after-image 中。

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

MySQL 复制生成错误，如果无法将修改应用于从站的 JSON 文档。这包括无法找到路径的情况。请注意，即使有这些安全检查，如果从站的 JSON 文档与源不同，并且应用了部分更新，仍然可能生成无效的 JSON 文档。

二进制日志行查询日志事件

该系统变量仅影响基于行的日志记录。当启用时，它会导致服务器将信息性日志事件（如行查询日志事件）写入其二进制日志中。这些信息可以用于调试和相关目的，例如在源上无法重构原始查询时获取原始查询。

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

这些信息性事件通常被 MySQL 程序忽略，读取二进制日志时不会引起问题。在复制或从备份还原时也不会引起问题。要查看它们，请使用 mysqlbinlog 的 --verbose 选项两次，或者作为 -vv 或 --verbose --verbose。

二进制日志语句缓存大小

二进制日志中用于保存事务中非事务语句的内存缓冲区大小。

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

如果您经常在事务中使用大型非事务语句，可以通过增加缓冲区大小来提高性能，减少或消除临时文件的使用。 Binlog_stmt_cache_use 和 Binlog_stmt_cache_disk_use 状态变量可以用于调整该变量的大小。见 第 7.4.4 节，“二进制日志”。

binlog_cache_size 系统变量设置事务缓存的大小。

二进制日志事务压缩

启用服务器上二进制日志文件中的事务压缩。OFF 是默认值。使用 binlog_transaction_compression_level_zstd 系统变量设置 zstd 算法的压缩级别。

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

要使binlog_transaction_compression=ON生效，服务器必须启用二进制日志记录。当 MySQL 8.3 服务器实例没有二进制日志时，它可以接收、处理和显示压缩的事务有效负载，不管其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。

随着压缩级别的增加，数据压缩比率增加，从而减少事务有效负载所需的存储空间和网络带宽。然而，数据压缩所需的努力也增加，占用源服务器的时间、CPU 和内存资源。压缩努力的增加与数据压缩比率的增加之间没有线性关系。

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

该变量对NDB表上的事务日志记录没有影响；请使用ndb_log_transaction_compression_level_zstdinstead。

binlog_transaction_dependency_tracking

对于具有多线程副本（副本上 replica_parallel_workers 大于 0）的复制源服务器，binlog_transaction_dependency_tracking 指定源 mysqld 在二进制日志中生成的依赖信息，以帮助副本确定哪些事务可以并行执行。

复制源写入二进制日志中的依赖信息使用逻辑时间戳表示。（因此，设置这个变量需要 replica_parallel_type 已经设置为 LOGICAL_CLOCK。）每个事务有两个逻辑时间戳：

binlog_transaction_dependency_tracking 控制用于计算这些逻辑时间戳的方案。可用的选择如下：

在 WRITESET 或 WRITESET_SESSION 模式下，源使用 COMMIT_ORDER 生成依赖信息，用于事务具有空或部分写入集的事务、更新没有主键或唯一键的表的事务，以及更新外键关系中的父表的事务。

行哈希数的数量，以便在最新的事务中检查给定行的变化是由binlog_transaction_dependency_history_size的值确定的。

组复制在认证后执行自己的并行处理，以应用中继日志中的事务，不管binlog_transaction_dependency_tracking的值如何设置，但该变量会影响组复制成员上的二进制日志的写入。这些日志中的依赖信息用于辅助分布式恢复过程中的状态传输，该过程发生在成员加入或重新加入组时。对于该过程，设置binlog_transaction_dependency_tracking为WRITESET可以根据组的工作负载提高性能。

在 MySQL 8.3 及更高版本中，需要binlog_format=ROW。

binlog_transaction_dependency_history_size

设置在内存中保留的行哈希数的上限，以便查找最后修改给定行的事务。一旦达到这个数字，历史记录将被清除。

log_bin

显示服务器上的二进制日志状态，启用 (ON) 或禁用 (OFF)。启用二进制日志记录时，服务器将所有更改数据的语句记录到二进制日志中，以便备份和复制。ON 表示二进制日志可用，OFF 表示不可用。--log-bin 选项可以指定二进制日志的基本名称和位置。

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

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

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

log_bin_basename

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

log_bin_index

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

log_bin_trust_function_creators

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

log_replica_updates

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

启用该变量将导致复制服务器将从源服务器接收的更新写入到其自己的二进制日志中。二进制日志记录，控制由--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

如果事务需要超过这个字节数，服务器将生成 多语句事务需要超过'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的值也适用于中继日志。

使用GTIDs在服务器上时，当max_binlog_size达到时，如果无法访问系统表mysql.gtid_executed以写入当前二进制日志文件的GTIDs，则无法旋转二进制日志。在这种情况下，服务器根据其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

内部使用，用于复制。 当在副本上重新执行事务时，这将设置为原始源上提交事务的时间，以微秒为单位，自 epoch 开始。这允许原始提交时间戳在复制拓扑结构中传播。

设置会话值的这个系统变量是一个受限的操作。会话用户必须具有 REPLICATION_APPLIER 权限（见 第 19.3.3 节，“复制权限检查”），或足以设置受限会话变量的权限（见 第 7.1.9.1 节，“系统变量权限”）。然而，请注意，变量不打算供用户设置；它是由复制基础设施自动设置的。

source_verify_checksum

启用 source_verify_checksum 导致源检查二进制日志中的事件的校验和，以便在事件不匹配时停止错误。在禁用时，源使用二进制日志中的事件长度来验证事件，以便仅从二进制日志中读取完整的事件。

sql_log_bin

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

将该变量设置为 OFF，以便在源上进行更改时临时禁用二进制日志记录，而不想将其复制到副本。

设置该系统变量的会话值是一个受限的操作。会话用户必须具有足以设置受限会话变量的权限。见 第 7.1.9.1 节，“系统变量权限”。

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

将该变量设置为 OFF 将阻止 GTIDs 被分配给事务二进制日志。如果您使用 GTIDs 进行复制，这意味着，即使后来启用二进制日志记录，GTIDs 也不会记录在日志中，从而导致事务丢失。

sync_binlog

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

要在使用 InnoDB 事务的复制设置中实现最大的持久性和一致性，请使用以下设置：