--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。

当服务器在 abnormal shutdown 后重新启动时，如果禁用二进制日志记录，可能会丢失一些 GTIDs，导致复制失败。在正常关闭时，当前二进制日志文件中的 GTID 集合将被保存在mysql.gtid_executed表中。由于 abnormal shutdown，GTIDs 将从二进制日志文件中添加到表中，假设二进制日志记录仍然启用。如果禁用二进制日志记录，服务器无法访问二进制日志文件来恢复 GTIDs，因此复制无法启动。二进制日志记录可以在正常关闭后安全禁用。

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

服务器可以在启用二进制日志记录时启动，但如果您不指定服务器 ID，服务器将发出信息性消息。对于在复制拓扑结构中使用的服务器，您必须指定每个服务器的唯一非零服务器 ID。

有关二进制日志的格式和管理，请参见第7.4.4节，“The Binary Log”。

--log-bin-index[=file_name]

二进制日志索引文件的名称，该文件包含二进制日志文件的名称。默认情况下，它的位置和名称与使用 --log-bin 选项指定的二进制日志文件相同，后缀为 .index。如果您不指定 --log-bin，默认的二进制日志索引文件名为 binlog.index。如果您指定 --log-bin 选项，但不指定字符串或空字符串，默认的二进制日志索引文件名为 host_name-bin.index，使用主机名称。

有关二进制日志的格式和管理，请参见Section 7.4.4, “The Binary Log”。

--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启动，并且基于行的日志记录在 effect 中，然后执行以下语句：

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的影响。现在假设，代替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选项将被应用，语句总是被记录。 (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 语句的影响不被写入到二进制日志中，这意味着在这个实例中，--binlog-ignore-db=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可以有助于调整该变量的大小。请参阅Section 7.4.4, “The Binary Log”。

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

binlog_checksum

启用时，这个变量会使源节点为每个事件在二进制日志中写入校验和。binlog_checksum支持值NONE(禁用校验和)和CRC32。默认值为CRC32。当binlog_checksum禁用（值为NONE）时，服务器将验证它是否将只写入完整事件到二进制日志中，通过写入和检查每个事件的长度（而不是校验和）来实现。

将这个变量在源节点设置为未识别的值将导致副本节点将其自己的binlog_checksum值设置为NONE，并在错误中停止复制。如果您关心与更老的副本的向后兼容，可以将值设置为NONE。

MySQL 8.4 中的 Group Replication 支持校验和，因此组成员可能使用默认设置。

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

在使用binlog_transaction_compression系统变量启用二进制日志事务压缩时，校验和不会为每个事件在压缩事务 payload 中写入。相反，会写入 GTID 事件的校验和和压缩的Transaction_payload_event的校验和。

binlog_direct_non_transactional_updates

由于并发问题，副本可能在包含更新非事务表的交易中变得不一致。MySQL 尝试通过将非事务语句写入事务缓存中，并在提交时将其flush，以保持语句之间的因果关系。然而，在非事务表上执行的修改可能会立即对其他连接可见，因为这些更改可能不会立即写入到二进制日志中。

The binlog_direct_non_transactional_updates 变量提供了一种解决方案来解决这个问题。默认情况下，这个变量是禁用的。启用 binlog_direct_non_transactional_updates 将使非事务表的更新直接写入到二进制日志中，而不是写入事务缓存中。

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

binlog_direct_non_transactional_updates 只能用于使用语句基于的二进制日志格式;也就是说，它只能在 binlog_format 的值为 STATEMENT 或 MIXED，且在使用语句基于的格式时生效。这变量在 ROW 格式或 binlog_format 设置为 MIXED，且在使用行基于的格式时无效。

这个变量在 ROW 或 MIXED 格式时无效。

binlog_encryption

启用对二进制日志文件和中继日志文件的加密。 OFF 是默认值。 ON 将对二进制日志文件和中继日志文件进行加密。二进制日志不需要在服务器上启用，以便启用加密，您可以在副本上加密中继日志文件。要使用加密，您需要安装和配置密钥ring插件，以供MySQL Server的密钥ring服务使用。有关详细信息，请参阅第8.4.4节，“MySQL密钥ring”。任何支持的密钥ring插件都可以用来存储二进制日志加密密钥。

当您首次启动服务器时，启用了二进制日志加密，会生成一个新的二进制日志加密密钥，然后初始化二进制日志和中继日志。这个密钥用于加密每个二进制日志文件（如果服务器启用了二进制日志记录）和中继日志文件（如果服务器启用了复制通道），并且从文件密码中生成的密钥用于加密文件中的数据。中继日志文件对所有通道进行加密，包括Group Replication applier通道和新创建的通道。二进制日志索引文件和中继日志索引文件从不加密。

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

如果您将binlog_encryption系统变量设置为OFF，二进制日志文件和中继日志文件将立即旋转，并且所有后续的记录将不加密。之前加密的文件不自动解密，但服务器仍然可以读取它们。需要BINLOG_ENCRYPTION_ADMIN特权（或弃用的SUPER特权）来在服务器运行时激活或禁用加密。Group Replication applier通道不包括在中继日志旋转请求中，因此这些通道的加密记录不会立即开始，直到它们在正常使用中旋转。

关于二进制日志文件和中继日志文件加密的更多信息，请见第19.3.2节，“ Encrypting Binary Log Files and Relay Log Files”。

binlog_error_action

控制服务器遇到错误，例如无法写入、刷新或同步二进制日志，这可能会导致源的二进制日志变得不一致，复制服务器失去同步。

该变量默认为 ABORT_SERVER，在遇到二进制日志错误时将使服务器停止记录日志并关闭。重启时，恢复过程与服务器意外关闭时相同（见第19.4.2节，“Handling an Unexpected Halt of a Replica”）。

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

binlog_expire_logs_seconds

设置二进制日志过期期限（以秒为单位）。过期期限结束后，可以自动删除二进制日志文件。可能的删除操作发生在启动时和二进制日志刷新时。日志刷新见第7.4节，“MySQL Server Logs”。

默认二进制日志过期期限为2592000秒，等于30天（30*24*60*60秒）。

可以通过设置binlog_expire_logs_auto_purge系统变量将自动删除二进制日志文件的功能禁用。该设置优先于任何设置binlog_expire_logs_seconds。

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

binlog_expire_logs_auto_purge

启用或禁用自动清除二进制日志文件。将该变量设置为ON(默认)启用自动清除；将其设置为OFF禁用自动清除。清除间隔由binlog_expire_logs_seconds控制。

该变量对PURGE BINARY LOGS无效。

binlog_format

该系统变量设置二进制日志格式，可以是STATEMENT、ROW或MIXED中的任何一个。 (见第19.2.1节，“Replication Formats”。)设置将在服务器启用二进制日志时生效，这是当log_bin系统变量设置为ON时。在 MySQL 8.4 中，二进制日志默认启用，并且默认使用行基于的格式。

binlog_format可以在启动或运行时设置，除非在某些情况下，无法在运行时更改该变量或导致复制失败，后续描述。

默认值为ROW。 Exception：在 NDB 集群中，默认值为MIXED；语句基于的复制不支持 NDB 集群。

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

关于更改该变量的规则和生效时间，以及变量的持久时间，同样适用于MySQL服务器系统变量。更多信息，请见第15.7.6.1节，“SET Syntax for Variable Assignment”。

当指定MIXED时，使用语句级别的复制，除非只有行级别的复制才能确保结果正确。例如，这发生在语句中包含可加载函数或UUID()函数时。

关于存储程序（存储程序、函数、触发器和事件）的处理方式，见第27.7节，“Stored Program Binary Logging”。

有一些情况不能在运行时更改复制格式：

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

在任何临时表存在时，不建议在运行时更改复制格式，因为临时表在使用语句级别的复制时被记录，而在使用行级别复制和混合复制时不被记录。

在复制源服务器更改日志格式时，不会导致副本更改其日志格式以匹配。更改复制格式时，可能会导致副本使用STATEMENT格式日志，而源服务器使用ROW或MIXED格式日志。这可能会导致复制失败。更多信息，请见第7.4.4.2节，“Setting The Binary Log Format”。

日志格式影响以下服务器选项的行为：

这些效果在每个选项的描述中有详细讨论。

binlog_group_commit_sync_delay

控制二进制日志提交等待同步二进制日志文件到磁盘的微秒数。默认情况下，binlog_group_commit_sync_delay 设置为 0，这意味着没有延迟。将 binlog_group_commit_sync_delay 设置为微秒延迟使得更多事务同步到磁盘一起，减少了事务组的总体时间，因为更大的组需要更少的时间单元。

当 sync_binlog=0 或 sync_binlog=1 设置时，指定的延迟将在每个二进制日志提交组之前应用（或在 sync_binlog=0 中，继续执行）。当 sync_binlog 设置为一个值 n 大于 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

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

事务将在所有参与的事务存储引擎确认事务已经准备好提交时写入到二进制日志中。然后，二进制日志组提交逻辑将提交一组事务，事务写入二进制日志后。 cuando 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节，“ 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”图像，只需要记录唯一标识行的最小列集。如果表包含行的主键，那么只记录主键列或列。否则，如果表包含唯一键，其中所有列都不是空的，那么只需要记录唯一键中的列。 (如果表既没有主键也没有唯一键，其中没有空列，那么所有列都需要在“before”图像中记录，并且需要记录。) 在“after”图像中，只需要记录实际更改的列。

您可以使服务器记录完整或最小行使用 binlog_row_image 系统变量。这個变量实际上可以取三个可能的值，如下列表所示：

默认值为 全。

使用 minimal 或 noblob 时，删除和更新操作在给定的表中将正确工作，如果和仅当以下条件在源和目标表中都成立：

(换言之，表必须是完全相同的，除了可能的索引以外，这些索引不属于表的主键。)

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

设置这个变量对在 STATEMENT 格式的二进制日志格式无效。当 binlog_format 是 MIXED 时，这个设置将应用于使用行格式的更改，但这个设置对使用语句格式的更改无效。

设置 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 文档的修改部分， REGARDLESS OF ANY VALUE SET FOR binlog_row_value_options。为了最大限度地节省空间，请使用binlog_row_image=NOBLOB或binlog_row_image=MINIMAL together with this option。binlog_row_image=FULL将保存的空间少于这两个，因为整个 JSON 文档将存储在 before-image 中，而部分更新将存储在 after-image 中。

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

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算法的压缩级别。

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

对于binlog_transaction_compression=ON要生效，必须在服务器上启用二进制日志。MySQL 8.4 服务器实例无二进制日志时，可以接收、处理和显示压缩的事务负载，无论binlog_transaction_compression的值。压缩的事务负载由其他服务器在复制拓扑结构中执行的压缩，写入relay日志中，因此可以间接地受益于压缩。

这个系统变量不能在事务上下文中更改。设置这个系统变量的会话值是一个受限制的操作。会话用户必须具有足够的权限来设置受限制的会话变量。请参阅第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。

随着压缩级别的增加，数据压缩比率增加，减少事务负载的存储空间和网络带宽。然而，压缩努力的增加不一定与数据压缩比率的增加成线性关系。

该系统变量不能在事务上下文中更改。设置会话值的系统变量是受限制的操作。会话用户必须具有足够的权限以设置受限制的会话变量。请见第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手动初始化数据目录时，二进制日志默认禁用。可以在这种情况下启用二进制日志指定--log-bin选项。

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

有关二进制日志的格式和管理，请参阅Section 7.4.4, “The Binary Log”。

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（默认），用户不能创建或更改存储函数，除非拥有SUPER特权，或者拥有CREATE ROUTINE或ALTER ROUTINE特权。设置为1时，MySQL 不会强制执行这些限制对存储函数创建。这个变量也适用于触发器创建。见第27.7节，“Stored Program Binary Logging”。

log_replica_updates

log_replica_updates 指定从replication源服务器接收的更新是否将被写入到replica的二进制日志中。

启用该变量将使replica将从源服务器接收的更新并由replication SQL线程执行，并将其写入到replica的二进制日志中。二进制日志控制由--log-bin选项启用，默认情况下启用。见第19.1.6节，“Replication and Binary Logging Options and Variables”。 log_replica_updates 默认情况下启用，除非您指定--skip-log-bin禁用二进制日志，否则MySQL将默认禁用replica更新日志。如果您需要禁用replica更新日志，而二进制日志启用，请在replica服务器启动时指定--log-replica-updates=OFF。

启用log_replica_updates使replication服务器可以链式连接。例如，您可能想设置replication服务器使用以下安排：

A -> B -> C

在这里，A 作为源服务器为replica B，并且 B 作为源服务器为replica C。为使其工作，B 必须同时是源服务器和replica。启用二进制日志和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不能工作于binary log positions大于4GB的位置；当gtid_mode是ON时，这个限制不适用，服务器可以工作于binary log positions的任意大小。

如果由于gtid_mode不是ON，或其他原因，你需要确保binary log不超过给定的大小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的值也适用于relay日志。

在服务器上使用GTIDs时，当max_binlog_size达到时，如果无法访问系统表mysql.gtid_executed以写入当前二进制日志文件，二进制日志无法旋转。在这种情况下，服务器根据其binlog_error_action设置进行响应。如果设置为IGNORE_ERROR，服务器将记录错误并停止二进制日志记录，如果设置为ABORT_SERVER，服务器将关闭。

max_binlog_stmt_cache_size

如果非事务语句在事务中需要超过这个字节数的内存，服务器将生成错误。最小值是4096。64位平台的最大值是16EB（exabytes），32位平台的最大值是4GB。

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

original_commit_timestamp

用于内部使用的复制。重复执行事务时，在副本上设置该变量，以便在原始源上提交事务的时间，以微秒为单位从(epoch)开始。这使得原始提交时间可以在复制拓扑中传播。

设置会话变量的值是一个受限制的操作。会话用户必须具有REPLICATION_APPLIER特权（见Section 19.3.3, “Replication Privilege Checks”），或具有设置受限制的会话变量的权限（见Section 7.1.9.1, “System Variable Privileges”）。然而，请注意该变量不是用户设置的；它是由复制基础结构自动设置的。

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将防止GTIDs在二进制日志中分配到事务。如果您使用GTIDs进行复制，这意味着当二进制日志记录再次启用时，写入日志的GTIDs将不包括在事务中，这意味着事务将丢失。

sync_binlog

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

在使用 InnoDB 事务 replication 设置中，为了获得最高的可靠性和一致性，请使用以下设置：