--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 版本中，二进制日志记录在默认情况下是禁用的，如果您指定了该 --log-bin选项，则会启用。从 MySQL 8.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-slave-updates选项 --slave-preserve-commit-order 需要二进制日志记录。如果禁用二进制日志记录，请忽略这些选项，或指定 --log-slave-updates=OFFand --skip-slave-preserve-commit-order。 指定--skip-log-bin 或 时，MySQL 默认禁用这些选项 。--disable-log-bin如果您将 or 与 or 一起指定 ， --log-slave-updates则会 --slave-preserve-commit-order 发出 警告或错误消息。 --skip-log-bin--disable-log-bin

在 MySQL 5.7 中，启用二进制日志记录时必须指定服务器 ID，否则服务器将无法启动。在 MySQL 8.0 中， server_id系统变量默认设置为 1。现在可以在启用二进制日志记录时使用此默认服务器 ID 启动服务器，但如果您未通过设置 server_id系统变量明确指定服务器 ID，则会发出一条信息性消息。对于复制拓扑中使用的服务器，您必须为每个服务器指定一个唯一的非零服务器 ID。

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

--log-bin-index[=file_name]

二进制日志索引文件的名称，其中包含二进制日志文件的名称。默认情况下，它具有与使用该--log-bin 选项为二进制日志文件指定的值相同的位置和基本名称，加上扩展名.index. 如果不指定--log-bin，默认二进制日志索引文件名为 binlog.index. 如果指定 --log-bin没有字符串或空字符串的选项，则默认二进制日志索引文件名为 host_name-bin.index，使用主机名。

有关二进制日志的格式和管理的信息，请参阅第 5.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以下 语句，也会记录以下语句： UPDATEprices--binlog-do-db

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

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

基于行的日志记录。  日志记录仅限于数据库 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. 现在假设使用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

事务期间用于保存二进制日志更改的内存缓冲区的大小。

块大小为 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小精确倍数的值向下舍入为块大小的下一个较低倍数。解析器允许值最大为平台的最大无符号整数值（对于 32 位系统为 4294967295 或 2 ³² -1，对于 64 位系统为 18446744073709551615 或 2 ⁶⁴ -1），但实际最大值比块大小小.

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

如果您经常使用大型事务，则可以通过减少或消除写入临时文件的需要来增加此缓存大小以获得更好的性能。和 Binlog_cache_use状态 Binlog_cache_disk_use 变量可用于调整此变量的大小。请参阅第 5.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.0.20 之前，Group Replication 无法使用校验和，也不支持它们存在于二进制日志中，因此您必须 binlog_checksum=NONE在配置服务器实例时设置为组成员。从 MySQL 8.0.21 开始，Group Replication 支持校验和，因此组成员可以使用默认设置。

更改 的值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 会导致对非事务表的更新直接写入二进制日志，而不是事务缓存。

从 MySQL 8.0.14 开始，设置这个系统变量的会话值是一个受限操作。会话用户必须具有足以设置受限会话变量的权限。请参阅第 5.1.9.1 节，“系统变量权限”。

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

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

binlog_encryption

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

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

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

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

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

binlog_error_action

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

此变量默认为ABORT_SERVER，这使得服务器在遇到此类二进制日志错误时停止记录并关闭。重新启动时，恢复会像服务器意外停止的情况一样进行（请参阅 第 17.4.2 节，“处理副本的意外停止”）。

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

binlog_expire_logs_seconds

以秒为单位设置二进制日志过期时间。在它们的有效期结束后，二进制日志文件可以自动删除。可能的删除发生在启动时和刷新二进制日志时。日志刷新发生在第 5.4 节，“MySQL 服务器日志”中。

默认的二进制日志有效期为 2592000 秒，即 30 天（30*24*60*60 秒）。binlog_expire_logs_seconds如果已弃用的系统变量都没有 expire_logs_days在启动时设置值，则应用默认 值。如果其中一个变量的非零值binlog_expire_logs_seconds或 expire_logs_days在启动时设置，则此值将用作二进制日志有效期。如果在启动时为这两个变量设置了非零值，则该值 binlog_expire_logs_seconds将用作二进制日志有效期，并且将 expire_logs_days忽略该值并显示一条警告消息。

在运行时，如果另一个当前设置为非零值，则不能将 binlog_expire_logs_secondsor expire_logs_days设置为非零值。因为 的默认值 不为零，所以在设置或更改 的值之前 binlog_expire_logs_seconds必须明确设置 为零。 binlog_expire_logs_secondsexpire_logs_days

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

在 MySQL 8.0.28 及更早版本中，要禁用二进制日志的自动清除，请为 明确指定值 0 binlog_expire_logs_seconds，并且不要为 指定值expire_logs_days。为了与早期版本兼容，如果您明确指定值 0 expire_logs_days而未指定值，则自动清除也会被禁用binlog_expire_logs_seconds。在这种情况下， binlog_expire_logs_seconds不应用默认值。

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

binlog_expire_logs_auto_purge

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

该变量对PURGE BINARY LOGS.

binlog_format

该系统变量设置二进制日志记录格式，可以是STATEMENT、 ROW或中的任何一个MIXED。请参阅 第 17.2.1 节，“复制格式”。该设置在服务器上启用二进制日志记录时生效，即 log_bin系统变量设置为时的情况ON。从 MySQL 8.0 开始，默认启用二进制日志记录。

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

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

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

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

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

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

当您无法在运行时切换复制格式时会有例外情况：

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

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

更改复制源服务器上的日志记录格式不会导致副本更改其日志记录格式以匹配。如果副本启用了二进制日志记录，则在复制进行时切换复制格式可能会导致问题，并且更改会导致副本 STATEMENT在源正在使用格式日志记录时使用格式日志记录ROW或MIXED 格式日志记录。副本无法将以ROW日志记录格式 接收的二进制日志条目转换STATEMENT为在其自己的二进制日志中使用的格式，因此这种情况会导致复制失败。有关详细信息，请参阅 第 5.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 （从 MySQL 8.0.26 开始）或 设置，并且当 还设置slave_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 版本中最终删除。以前，此系统变量以微秒为单位控制时间，以便在继续进行组提交之前继续从刷新队列中读取事务。它不再有任何作用。

binlog_order_commits

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

当所有涉及的存储引擎都确认事务已准备好提交时，事务将写入二进制日志。二进制日志组提交逻辑然后在二进制日志写入发生后提交一组事务。什么时候 binlog_order_commits被禁用，因为这个过程使用了多个线程，提交组中的事务可能以不同于它们在二进制日志中的顺序提交。（来自单个客户端的事务总是按时间顺序提交。）在许多情况下这并不重要，因为在单独的事务中执行的操作应该产生一致的结果，如果不是这种情况，则应该使用单个事务来代替。

如果要确保源和多线程副本上的事务历史记录保持相同， slave_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默认值，则在服务器重新启动后将再次使用现有的二进制日志主密钥。有关二进制日志加密密钥和二进制日志主密钥的更多信息，请参阅第 17.3.2 节，“加密二进制日志文件和中继日志文件”。

binlog_row_event_max_size

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

块大小为 256。在存储系统变量的值之前，MySQL 服务器会将不是块大小精确倍数的值向下舍入为块大小的下一个较低倍数。解析器允许值最大为平台的最大无符号整数值（对于 32 位系统为 4294967295 或 2 ³² -1，对于 64 位系统为 18446744073709551615 或 2 ⁶⁴ -1），但实际最大值比块大小小.

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

binlog_row_image

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

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

在 MySQL 基于行的复制中，每个行更改事件都包含两个图像，一个是在搜索要更新的行时匹配列的“之前”图像，另一个是包含更改的“之后”图像。通常，MySQL 会记录前后图像的完整行（即所有列）。然而，并不是绝对有必要在两个图像中都包括每一列，我们通常可以通过仅记录那些实际需要的列来节省磁盘、内存和网络使用。

对于之前的图像，只需要记录唯一标识行所需的最小列集。如果包含行的表有主键，则只有主键列或列被写入二进制日志。否则，如果表有一个唯一键，其所有列都是NOT NULL，则只需要记录唯一键中的列。（如果表既没有主键也没有没有任何 NULL列的唯一键，那么所有列都必须在前映像中使用，并记录下来。）在后映像中，只需要记录实际发生变化的列。

binlog_row_image您可以使用系统变量 使服务器记录完整或最少的行。该变量实际上采用三个可能值之一，如下表所示：

默认值为full。

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

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

设置这个系统变量的会话值是一个受限的操作。会话用户必须具有足以设置受限会话变量的权限。请参阅 第 5.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 文档存储在前映像中，而部分更新仅存储在后映像中。

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

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

binlog_rows_query_log_events

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

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

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

binlog_stmt_cache_size

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

块大小为 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小精确倍数的值向下舍入为块大小的下一个较低倍数。解析器允许值最大为平台的最大无符号整数值（对于 32 位系统为 4294967295 或 2 ³² -1，对于 64 位系统为 18446744073709551615 或 2 ⁶⁴ -1），但实际最大值比块大小小.

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

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

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

binlog_transaction_compression

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

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

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

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

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

在 NDB 8.0.31 之前NDB：在服务器运行时设置此变量对表上的事务记录没有影响NDB可以通过在命令行或选项文件中启动 MySQL 来为表启用二进制日志事务压缩， --binlog-transaction-compression=ON 但不能在服务器运行时启用或禁用。

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

binlog_transaction_compression_level_zstd

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

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

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

该变量对 NDB表上的事务记录没有影响；在 NDB Cluster 8.0.31 及更高版本中，您可以 ndb_log_transaction_compression_level_zstd 改用。

binlog_transaction_dependency_tracking

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

复制源写入的依赖信息使用逻辑时间戳表示。（因此，设置此变量需要 replica_parallel_typeor slave_parallel_type已经设置为LOGICAL_CLOCK。）这里列出了每个事务的两个逻辑时间戳：

binlog_transaction_dependency_tracking 控制用于计算这些逻辑时间戳的方案的选择。此处列出了可用的选择：

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

要设置 binlog_transaction_dependency_tracking为 WRITESET或 WRITESET_SESSION， transaction_write_set_extraction 必须设置为 以外的值OFF；默认值 ( XXHASH64) 就足够了。 只要 的值为 或 transaction_write_set_extraction，就不能更改 。在副本停止并使用和 重新启动之前，值的任何更改不会对复制的事务生效 。 binlog_transaction_dependency_trackingWRITESETWRITESET_SESSIONSTOP REPLICASTART REPLICA

为更改给定行的最新事务保留和检查的行哈希数由 的值确定 binlog_transaction_dependency_history_size。

当从中继日志应用事务时，组复制在认证后执行自己的并行化，独立于为 设置的任何值 binlog_transaction_dependency_tracking，但此变量确实影响事务如何写入组复制成员的二进制日志。这些日志中的依赖信息用于协助从捐赠者的二进制日志进行状态传输以进行分布式恢复，每当成员加入或重新加入组时都会发生这种情况。对于该进程，设置 binlog_transaction_dependency_tracking为 WRITESET可以提高组成员的性能，具体取决于组的工作量。

binlog_transaction_dependency_history_size

设置保留在内存中并用于查找最后修改给定行的事务的行哈希数的上限。一旦达到这个哈希数，历史就会被清除。

expire_logs_days

指定自动删除二进制日志文件之前的天数。 expire_logs_days已弃用，您应该期望在未来的版本中将其删除。相反，使用 binlog_expire_logs_seconds，它以秒为单位设置二进制日志有效期。如果您没有为任一系统变量设置值，则默认有效期为 30 天。可能的删除发生在启动时和刷新二进制日志时。日志刷新发生在 第 5.4 节，“MySQL 服务器日志”中。

如果还指定了您在启动时指定的任何非零值， expire_logs_days则将被忽略 binlog_expire_logs_seconds ，并且该值将 binlog_expire_logs_seconds 用作二进制日志有效期。在这种情况下会发出一条警告消息。 如果未指定或指定为 0 ，则非零启动值 expire_logs_days 仅用作二进制日志有效期 。binlog_expire_logs_seconds

在运行时，如果另一个当前设置为非零值，则不能将 binlog_expire_logs_seconds orexpire_logs_days设置为非零值。因为 的默认值 不为零， 所以在设置或更改 的值之前 binlog_expire_logs_seconds 必须明确设置 为零。 binlog_expire_logs_secondsexpire_logs_days

要禁用二进制日志的自动清除，请为 明确指定值 0 binlog_expire_logs_seconds，并且不要为 指定值 expire_logs_days。为了与早期版本兼容，如果您明确指定值 0 expire_logs_days而未指定值 ，则自动清除也会被禁用binlog_expire_logs_seconds。在这种情况下， binlog_expire_logs_seconds 不应用默认值。

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

log_bin

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

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

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

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

log_bin_basename

保存二进制日志文件的基本名称和路径，可以使用--log-bin 服务器选项进行设置。最大变量长度为 256。在 MySQL 8.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（默认值），则不允许用户创建或更改存储的函数，除非他们拥有SUPER 除CREATE ROUTINE或权限之外的ALTER ROUTINE权限。设置为 0 还会强制执行以下限制，即函数必须使用 DETERMINISTIC特征声明，或者使用 READS SQL DATAorNO SQL特征。如果该变量设置为 1，则 MySQL 不会对存储函数的创建强制执行这些限制。此变量也适用于触发器创建。请参阅第 25.7 节，“存储程序二进制日志记录”。

log_bin_use_v1_row_events

此只读系统变量已弃用。将系统变量设置为ONat at server startup 通过使用版本 1 二进制日志行事件而不是 MySQL 5.6 默认的版本 2 二进制日志行事件写入二进制日志，启用运行 MySQL Server 5.5 和更早版本的副本的基于行的复制.

log_replica_updates

从 MySQL 8.0.26 开始，使用 log_replica_updates代替log_slave_updates，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 log_slave_updates.

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

启用此变量会导致副本将从源接收并由复制 SQL 线程执行的更新写入副本自己的二进制日志。由 --log-bin选项控制并默认启用的二进制日志记录也必须在副本上启用以记录更新。请参阅 第 17.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

从 MySQL 8.0.26 开始， 已弃用，应改用log_slave_updates别名 。log_replica_updates在 MySQL 8.0.26 之前的版本中，使用 log_slave_updates.

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

启用此变量会导致副本将从源接收并由复制 SQL 线程执行的更新写入副本自己的二进制日志。由 --log-bin选项控制并默认启用的二进制日志记录也必须在副本上启用以记录更新。请参阅 第 17.1.6 节，“复制和二进制日志记录选项和变量”。 log_slave_updates默认情况下启用，除非您指定 --skip-log-bin 禁用二进制日志记录，在这种情况下，MySQL 默认也会禁用副本更新日志记录。如果您需要在启用二进制日志记录时禁用副本更新日志记录，请 --log-slave-updates=OFF在副本服务器启动时指定。

启用log_slave_updates 可以链接复制服务器。例如，您可能希望使用这种安排来设置复制服务器：

A -> B -> C

在这里，A作为副本的来源B，并B 作为副本的来源C。为此，B必须既是来源 又是副本。在启用和 log_slave_updates启用二进制日志记录（这是默认设置）的情况下，从 接收到 A的更新记录B到其二进制日志中，因此可以传递到 C.

log_statements_unsafe_for_binlog

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

master_verify_checksum

从 MySQL 8.0.26 开始， 已弃用， 应改用master_verify_checksum别名 。source_verify_checksum在 MySQL 8.0.26 之前的版本中，使用 master_verify_checksum.

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

max_binlog_cache_size

如果一个事务需要超过这个字节数的内存，服务器会生成一个Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage错误。最小值为 4096。最大可能值为 16EiB (exbibytes)。最大推荐值为4GB；这是因为 MySQL 当前无法处理大于 4GB 的二进制日志位置。

块大小为 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小精确倍数的值向下舍入为块大小的下一个较低倍数。解析器允许值最大为平台的最大无符号整数值（对于 32 位系统为 4294967295 或 2 ³² -1，对于 64 位系统为 18446744073709551615 或 2 ⁶⁴ -1），但实际最大值比块大小小.

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系统表以从当前二进制日志文件写入 GTID，则无法轮换二进制日志。mysql.gtid_executed在这种情况下，服务器根据其 binlog_error_action 设置进行响应。如果IGNORE_ERROR设置，则在服务器上记录错误并停止二进制日志记录，或者如果 ABORT_SERVER设置，则服务器关闭。

max_binlog_stmt_cache_size

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

块大小为 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小精确倍数的值向下舍入为块大小的下一个较低倍数。解析器允许值最大为平台的最大无符号整数值（对于 32 位系统为 4294967295 或 2 ³² -1，对于 64 位系统为 18446744073709551615 或 2 ⁶⁴ -1），但实际最大值比块大小小.

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

original_commit_timestamp

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

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

source_verify_checksum

从 MySQL 8.0.26 开始，使用 source_verify_checksum代替 master_verify_checksum，该版本已弃用。在 MySQL 8.0.26 之前的版本中，使用 master_verify_checksum.

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

sql_log_bin

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

将此变量设置为OFF以便会话在对不希望复制到副本的源进行更改时临时禁用二进制日志记录。

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

不可能 sql_log_bin在事务或子查询中设置会话值。

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

sync_binlog

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

InnoDB为了在与事务一起使用 的复制设置中获得最大可能的持久性和一致性，请使用以下设置：

transaction_write_set_extraction

此系统变量指定用于散列事务期间提取的写入的算法。默认值为 XXHASH64。OFF意味着不收集写集。

transaction_write_set_extraction从 MySQL 8.0.26 开始弃用；希望在未来的 MySQL 版本中将其删除。

该XXHASH64设置是组复制所必需的，其中从事务中提取写入的过程用于对所有组成员进行冲突检测和认证（请参阅 第 18.3.1 节，“组复制要求”）。对于具有多线程副本（ replica_parallel_workers或 slave_parallel_workers设置为大于 0 的值的副本）的复制源服务器，其中 binlog_transaction_dependency_tracking 设置为WRITESET或 WRITESET_SESSION， transaction_write_set_extraction不得为OFF。而当前值 binlog_transaction_dependency_tracking 是WRITESET或 WRITESET_SESSION，您不能更改 的值 transaction_write_set_extraction。

从 MySQL 8.0.14 开始，设置该系统变量的会话值是一个受限操作；会话用户必须具有足够的权限来设置受限会话变量（请参阅 第 5.1.9.1 节，“系统变量权限”）。 binlog_format必须设置为ROW才能更改 的值 transaction_write_set_extraction。如果您更改该值，则新值不会对复制的事务生效，直到副本已停止并使用 和 重新STOP REPLICA启动START REPLICA。