您可以使用本节中描述的mysqld选项和系统变量来影响二进制日志的操作以及控制将哪些语句写入二进制日志。有关二进制日志的更多信息，请参阅第 5.4.4 节，“二进制日志”。有关使用 MySQL 服务器选项和系统变量的其他信息，请参阅第 5.1.7 节，“服务器命令选项”和 第 5.1.8 节，“服务器系统变量”。
与二进制日志记录一起使用的启动选项
以下列表描述了用于启用和配置二进制日志的启动选项。本节稍后将讨论与二进制日志记录一起使用的系统变量。
-
--binlog-row-event-max-size=*N*命令行格式 --binlog-row-event-max-size=#系统变量 (≥ 8.0.14) binlog_row_event_max_size范围（≥8.0.14） 全局 动态（≥ 8.0.14） 不 SET_VAR提示适用 (≥ 8.0.14)不 类型 整数 默认值 8192最小值 256最大值（64 位平台） 18446744073709551615最大值（32 位平台） 4294967295单元 字节 当使用基于行的二进制日志时，此设置是对基于行的二进制日志事件的最大大小的软限制，以字节为单位。在可能的情况下，存储在二进制日志中的行被分组为大小不超过此设置值的事件。如果无法拆分事件，则可以超出最大大小。该值必须是（否则会向下舍入）256 的倍数。默认值为 8192 字节。
-
命令行格式 --log-bin=file_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通过使用--initializeor--initialize-insecure选项手动初始化数据目录，则默认情况下禁用二进制日志记录。在这种情况下，可以通过指定--log-bin选项来启用二进制日志记录。启用二进制日志记录后，log_bin显示服务器上二进制日志状态的系统变量设置为 ON。要禁用二进制日志记录，您可以在启动时指定
--skip-log-binor--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-binMySQL 在指定或 时默认禁用这些选项--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=file_name系统变量 log_bin_index范围 全局 动态的 不 SET_VAR提示适用不 类型 文件名 二进制日志索引文件的名称，其中包含二进制日志文件的名称。默认情况下，它具有与使用该
--log-bin选项为二进制日志文件指定的值相同的位置和基本名称，加上扩展名.index. 如果不指定--log-bin，默认的二进制日志索引文件名为binlog.index. 如果您指定--log-bin不带字符串或空字符串的选项，则默认二进制日志索引文件名称为*host_name*-bin.index，使用主机名称。有关二进制日志的格式和管理的信息，请参阅第 5.4.4 节，“二进制日志”。
语句选择选项。 以下列表中的选项影响将哪些语句写入二进制日志，从而由复制源服务器发送到其副本。副本还有一些选项可以控制从源接收到的哪些语句应该被执行或忽略。有关详细信息，请参阅 第 17.1.6.3 节，“副本服务器选项和变量”。
-
命令行格式 --binlog-do-db=name类型 细绳 此选项以类似于
--replicate-do-db影响复制的方式影响二进制日志记录。此选项的效果取决于使用的是基于语句还是基于行的日志记录格式，其效果
--replicate-do-db取决于使用的是基于语句还是基于行的复制。您应该记住，用于记录给定语句的格式不一定与 的值所指示的格式相同binlog_format。例如，诸如CREATE TABLEand之类的 DDL 语句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-dbUSE 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由以下内容所做的更改：UPDATEUSE 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会记录对 to 的更改，而不是对 to的table2更改——换句话说，只--binlog-do-db记录对名为 by 的数据库中的表的更改，并且选择默认数据库对此行为没有影响。 -
命令行格式 --binlog-ignore-db=name类型 细绳 此选项以类似于
--replicate-ignore-db影响复制的方式影响二进制日志记录。此选项的效果取决于使用的是基于语句还是基于行的日志记录格式，其效果
--replicate-ignore-db取决于使用的是基于语句还是基于行的复制。您应该记住，用于记录给定语句的格式不一定与 的值所指示的格式相同binlog_format。例如，诸如CREATE TABLEand之类的 DDL 语句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-dbUSEsalesUPDATEsales.january--binlog-ignore-db=salessales出于二进制日志记录目的而忽略的数据库。要指定多个要忽略的数据库，请多次使用此选项，每个数据库一次。因为数据库名称可以包含逗号，所以如果您提供逗号分隔的列表，则该列表将被视为单个数据库的名称。
如果您使用跨数据库更新并且不希望记录这些更新，则不应使用此选项。
校验和选项。 MySQL 支持二进制日志校验和的读写。这些是使用此处列出的两个选项启用的：
-
--binlog-checksum={NONE|CRC32}命令行格式 --binlog-checksum=type类型 细绳 默认值 CRC32有效值 NONE``CRC32启用此选项会导致源为写入二进制日志的事件写入校验和。设置为
NONE禁用，或用于生成校验和的算法的名称；目前，仅支持 CRC32 校验和，CRC32 为默认值。您不能在事务中更改此选项的设置。
要控制副本读取校验和（来自中继日志），请使用该 --slave-sql-verify-checksum 选项。
测试和调试选项。 以下二进制日志选项用于复制测试和调试。它们不适用于正常操作。
-
命令行格式 --max-binlog-dump-events=#类型 整数 默认值 0MySQL 测试套件在内部使用此选项进行复制测试和调试。
-
命令行格式 --sporadic-binlog-dump-fail[={OFF|ON}]类型 布尔值 默认值 OFFMySQL 测试套件在内部使用此选项进行复制测试和调试。
与二进制日志记录一起使用的系统变量
以下列表描述了用于控制二进制日志记录的系统变量。它们可以在服务器启动时设置，其中一些可以在运行时使用 SET. 本节前面列出了用于控制二进制日志记录的服务器选项。
-
命令行格式 --binlog-cache-size=#系统变量 binlog_cache_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 32768最小值 4096最大值（64 位平台） 18446744073709547520最大值（32 位平台） 4294963200单元 字节 块大小 4096在事务期间保存二进制日志更改的内存缓冲区的大小。
块大小是 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小的精确倍数的值向下舍入到块大小的下一个较低倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
在服务器上启用二进制日志记录（
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=name系统变量 binlog_checksum范围 全局 动态的 是的 SET_VAR提示适用不 类型 细绳 默认值 CRC32有效值 NONE``CRC32启用后，此变量会导致源为二进制日志中的每个事件写入校验和。
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命令行格式 --binlog-direct-non-transactional-updates[={OFF|ON}]系统变量 binlog_direct_non_transactional_updates范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF由于并发问题，当事务包含对事务表和非事务表的更新时，副本可能会变得不一致。MySQL 试图通过将非事务性语句写入事务缓存中来保持这些语句之间的因果关系，该事务缓存在提交时被刷新。但是，当代表事务对非事务表所做的修改对其他连接立即可见时，就会出现问题，因为这些更改可能不会立即写入二进制日志。
该
binlog_direct_non_transactional_updates变量为此问题提供了一种可能的解决方法。默认情况下，此变量被禁用。启用binlog_direct_non_transactional_updates会导致对非事务表的更新直接写入二进制日志，而不是写入事务缓存。从 MySQL 8.0.14 开始，设置此系统变量的会话值是一项受限操作。会话用户必须具有足以设置受限会话变量的权限。请参见第 5.1.9.1 节，“系统变量权限”。
binlog_direct_non_transactional_updates仅适用于使用基于语句的二进制日志记录格式复制的语句；也就是说，它仅在 is 的值binlog_format，STATEMENT或者当binlog_formatisMIXED和给定语句使用基于语句的格式复制时才有效。当二进制日志格式为 时，此变量无效ROW，或者何时binlog_format设置为MIXED并且使用基于行的格式复制给定语句。重要的
在启用此变量之前，您必须确保事务表和非事务表之间没有依赖关系；这种依赖关系的一个例子是语句
INSERT INTO myisam_table SELECT * FROM innodb_table。否则，这样的语句很可能会导致副本偏离源。ROW当二进制日志格式为或 时，此变量无效MIXED。 -
命令行格式 --binlog-encryption[={OFF|ON}]介绍 8.0.14 系统变量 binlog_encryption范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF启用此服务器上的二进制日志文件和中继日志文件的加密。
OFF是默认值。ON为二进制日志文件和中继日志文件设置加密。不需要在服务器上启用二进制日志来启用加密，因此您可以在没有二进制日志的副本上加密中继日志文件。要使用加密，必须安装和配置密钥环插件以提供 MySQL 服务器的密钥环服务。有关执行此操作的说明，请参阅第 6.4.4 节，“MySQL 密钥环”。任何受支持的密钥环插件都可用于存储二进制日志加密密钥。首次启动启用二进制日志加密的服务器时，会在初始化二进制日志和中继日志之前生成一个新的二进制日志加密密钥。此密钥用于加密每个二进制日志文件（如果服务器启用了二进制日志记录）和中继日志文件（如果服务器具有复制通道）的文件密码，并且从文件密码生成的进一步密钥用于加密数据在文件中。中继日志文件为所有通道加密，包括组复制应用程序通道和激活加密后创建的新通道。二进制日志索引文件和中继日志索引文件从不加密。
如果您在服务器运行时激活加密，则此时会生成一个新的二进制日志加密密钥。例外情况是，如果加密之前在服务器上处于活动状态，然后被禁用，在这种情况下，之前使用的二进制日志加密密钥会再次使用。二进制日志文件和中继日志文件立即轮换，新文件的文件密码以及所有后续二进制日志文件和中继日志文件都使用此二进制日志加密密钥进行加密。仍然存在于服务器上的现有二进制日志文件和中继日志文件不会自动加密，但如果不再需要它们，您可以清除它们。
如果您通过将
binlog_encryption系统变量更改为 来停用加密OFF，则二进制日志文件和中继日志文件将立即轮换，并且所有后续日志记录均未加密。以前加密的文件不会自动解密，但服务器仍然可以读取它们。在服务器运行时激活或停用加密需要该BINLOG_ENCRYPTION_ADMIN权限（或已弃用的 权限）。SUPER组复制应用程序通道不包含在中继日志轮换请求中，因此这些通道的未加密日志记录在其日志在正常使用中轮换之前不会启动。有关二进制日志文件和中继日志文件加密的更多信息，请参阅 第 17.3.2 节，“加密二进制日志文件和中继日志文件”。
-
命令行格式 --binlog-error-action[=value]系统变量 binlog_error_action范围 全局 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 ABORT_SERVER有效值 IGNORE_ERROR``ABORT_SERVER控制当服务器遇到错误时会发生什么，例如无法写入、刷新或同步二进制日志，这可能导致源的二进制日志变得不一致，副本失去同步。
此变量默认为
ABORT_SERVER，这会使服务器在遇到二进制日志的此类错误时停止日志记录并关闭。重新启动时，恢复会像服务器意外停止一样继续进行（请参阅 第 17.4.2 节，“处理副本的意外停止”）。当
binlog_error_action设置为 时IGNORE_ERROR，如果服务器遇到此类错误，它将继续进行中的事务，记录错误，然后停止记录，并继续执行更新。要恢复二进制日志log_bin，必须再次启用，这需要重新启动服务器。此设置提供与旧版本 MySQL 的向后兼容性。 -
命令行格式 --binlog-expire-logs-seconds=#系统变量 binlog_expire_logs_seconds范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 2592000最小值 0最大值 4294967295单元 秒 以秒为单位设置二进制日志过期时间。在它们的有效期结束后，二进制日志文件可以被自动删除。可能的删除发生在启动和刷新二进制日志时。日志刷新发生在第 5.4 节，“MySQL 服务器日志”中。
默认二进制日志有效期为 2592000 秒，即 30 天（302460*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_seconds或expire_logs_days为非零值。由于 的默认值为binlog_expire_logs_seconds非零，因此您必须先明确设置binlog_expire_logs_seconds为零，然后才能设置或更改 的值expire_logs_days。从 MySQL 8.0.29 开始，可以通过将
binlog_expire_logs_auto_purge系统变量设置为OFF. 这优先于 的任何设置binlog_expire_logs_seconds。在 MySQL 8.0.28 及更早版本中，要禁用二进制日志的自动清除，请为 显式指定值 0
binlog_expire_logs_seconds，并且不要为 指定值expire_logs_days。为了与早期版本兼容，如果您明确指定值 0expire_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}介绍 8.0.29 系统变量 binlog_expire_logs_auto_purge范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 ON启用或禁用二进制日志文件的自动清除。将此变量设置为
ON（默认值）启用自动清除；将其设置为OFF禁用自动清除。清除前等待的时间间隔由binlog_expire_logs_seconds和控制expire_logs_days。笔记
即使
binlog_expire_logs_auto_purge是ON，也设置binlog_expire_logs_seconds和expire_logs_days以0停止发生自动清除。此变量对 没有影响
PURGE BINARY LOGS。 -
命令行格式 --binlog-format=format系统变量 binlog_format范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 ROW有效值 MIXED``STATEMENT``ROW此系统变量设置二进制日志记录格式，可以是
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 节，“存储程序二进制日志记录”。
当您无法在运行时切换复制格式时有例外：
- 无法从存储的函数或触发器中更改复制格式。
- 如果会话具有打开的临时表，则无法更改会话的复制格式 (
SET @@SESSION.binlog_format)。 - 如果任何复制通道具有打开的临时表，则无法全局更改复制格式（
SET @@GLOBAL.binlog_format或SET @@PERSIST.binlog_format）。 - 如果当前正在运行任何复制通道应用程序线程，则无法全局更改复制格式（
SET @@GLOBAL.binlog_format或SET @@PERSIST.binlog_format）。
在任何这些情况下尝试切换复制格式（或尝试设置当前复制格式）都会导致错误。但是，您可以随时使用
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=#系统变量 binlog_group_commit_sync_delay范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 0最小值 0最大值 1000000单元 微秒 控制二进制日志提交在将二进制日志文件同步到磁盘之前等待多少微秒。默认
binlog_group_commit_sync_delay设置为 0，表示没有延迟。设置binlog_group_commit_sync_delay为微秒延迟可以使更多事务一次同步到磁盘，从而减少提交一组事务的总时间，因为较大的组需要较少的时间单位。sync_binlog=0设置或 时 ，在同步之前（或在 的情况下，在继续之前）对每个二进制日志提交组应用sync_binlog=1指定的延迟 。当 设置为大于 1的值n时，在每**n 个二进制日志提交组之后应用延迟。binlog_group_commit_sync_delaysync_binlog=0sync_binlog设置
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-no-delay-count=#系统变量 binlog_group_commit_sync_no_delay_count范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 0最小值 0最大值 100000中止当前延迟之前等待的最大事务数，由 指定
binlog_group_commit_sync_delay。如果binlog_group_commit_sync_delay设置为 0，则此选项无效。 -
命令行格式 --binlog-max-flush-queue-time=#已弃用 是的 系统变量 binlog_max_flush_queue_time范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 0最小值 0最大值 100000单元 微秒 binlog_max_flush_queue_time已弃用，并标记为在未来的 MySQL 版本中最终删除。以前，此系统变量以微秒为单位控制在继续进行组提交之前继续从刷新队列中读取事务的时间。它不再有任何作用。 -
命令行格式 --binlog-order-commits[={OFF|ON}]系统变量 binlog_order_commits范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 ON当在复制源服务器上启用此变量时（这是默认设置），发送到存储引擎的事务提交指令在单个线程上进行序列化，以便事务始终以与写入二进制日志相同的顺序提交。禁用此变量允许使用多个线程发出事务提交指令。与二进制日志组提交结合使用，可以防止单个事务的提交率成为吞吐量的瓶颈，因此可能会提高性能。
当所有涉及的存储引擎都确认事务已准备好提交时，事务将写入二进制日志。然后二进制日志组提交逻辑在其二进制日志写入发生后提交一组事务。什么时候
binlog_order_commits被禁用，因为这个进程使用了多个线程，提交组中的事务可能会以与它们在二进制日志中的顺序不同的顺序提交。（来自单个客户端的事务总是按时间顺序提交。）在许多情况下，这并不重要，因为在不同事务中执行的操作应该产生一致的结果，如果不是这种情况，则应该使用单个事务。如果要确保源和多线程副本上的事务历史记录保持相同，
slave_preserve_commit_order=1请在副本上设置。 -
binlog_rotate_encryption_master_key_at_startup命令行格式 --binlog-rotate-encryption-master-key-at-startup[={OFF|ON}]介绍 8.0.14 系统变量 binlog_rotate_encryption_master_key_at_startup范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 默认值 OFF指定二进制日志主密钥是否在服务器启动时轮换。二进制日志主密钥是二进制日志加密密钥，用于加密服务器上二进制日志文件和中继日志文件的文件密码。在启用二进制日志加密 ( ) 的情况下首次启动服务器时，
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=#系统变量 (≥ 8.0.14) binlog_row_event_max_size范围（≥8.0.14） 全局 动态（≥ 8.0.14） 不 SET_VAR提示适用 (≥ 8.0.14)不 类型 整数 默认值 8192最小值 256最大值（64 位平台） 18446744073709551615最大值（32 位平台） 4294967295单元 字节 当使用基于行的二进制日志时，此设置是对基于行的二进制日志事件的最大大小的软限制，以字节为单位。在可能的情况下，存储在二进制日志中的行被分组为大小不超过此设置值的事件。如果无法拆分事件，则可以超出最大大小。默认值为 8192 字节。
块大小为 256。在存储系统变量的值之前，MySQL 服务器会向下舍入到块大小的下一个较低倍数的值，而不是块大小的精确倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
这个全局系统变量是只读的，只能在服务器启动时设置。因此，它的值只能通过在语句中 使用
PERSIST_ONLY关键字或@@persist_only限定符 来修改。SET -
命令行格式 --binlog-row-image=image_type系统变量 binlog_row_image范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 full有效值 full（记录所有列）minimal（仅记录更改的列，以及标识行所需的列）noblob（记录所有列，不需要的 BLOB 和 TEXT 列除外）对于 MySQL 基于行的复制，此变量确定如何将行图像写入二进制日志。
设置此系统变量的会话值是一项受限操作。会话用户必须具有足以设置受限会话变量的权限。请参见 第 5.1.9.1 节，“系统变量权限”。
在 MySQL 基于行的复制中，每个行更改事件包含两个图像，一个“ before ”图像，其列在搜索要更新的行时匹配，一个“ after ”图像包含更改。通常，MySQL 记录前后图像的完整行（即所有列）。但是，并非绝对需要在两个图像中都包含每一列，而且我们通常可以通过仅记录实际需要的列来节省磁盘、内存和网络使用量。
笔记
删除行时，仅记录之前的图像，因为删除后没有要传播的更改值。插入行时，仅记录后图像，因为没有要匹配的现有行。只有在更新一行时才需要前后图像，并且都写入二进制日志。
对于之前的图像，只需要记录唯一标识行所需的最小列集。如果包含该行的表具有主键，则只有主键列或列被写入二进制日志。否则，如果表有一个唯一键，其所有列都是
NOT NULL，则只需要记录唯一键中的列。（如果表既没有主键也没有唯一键，没有任何NULL列，那么所有列都必须在前映像中使用并记录。）在后映像中，只需记录实际更改的列。binlog_row_image您可以使用系统变量 使服务器记录完整或最少的行。此变量实际上采用三个可能值之一，如下表所示：full：记录前映像和后映像中的所有列。minimal：只记录之前图像中需要识别要更改的行的列；仅记录后映像中由 SQL 语句指定值或通过自动增量生成的那些列。noblob：记录所有列（与 相同full），除了 不需要标识行或未更改的列。BLOBTEXT
笔记
NDB Cluster 不支持此变量；设置它对
NDB表的日志记录没有影响。默认值为
full。使用
minimalornoblob时，当且仅当源表和目标表都满足以下条件时，才能保证删除和更新对给定表正确工作：- 所有列必须存在且顺序相同；每列必须使用与其在另一个表中对应的数据类型相同的数据类型。
- 这些表必须具有相同的主键定义。
（换句话说，除了不属于表主键的索引之外，表必须相同。）
如果不满足这些条件，则可能证明目标表中的主键列值不足以为删除或更新提供唯一匹配。在这种情况下，不会发出警告或错误；源和副本默默地发散，从而破坏了一致性。
当二进制日志记录格式为 时，设置此变量无效
STATEMENT。当binlog_formatisMIXED时，设置binlog_row_image适用于使用基于行的格式记录的更改，但此设置对记录为语句的更改没有影响。在全局或会话级别上设置
binlog_row_image不会导致隐式提交；这意味着可以在事务进行时更改此变量，而不会影响事务。 -
命令行格式 --binlog-row-metadata=metadata_type系统变量 binlog_row_metadata范围 全局 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 MINIMAL有效值 FULL（包括所有元数据）MINIMAL（限制包含的元数据）配置使用基于行的日志记录时添加到二进制日志的表元数据量。默认设置为
MINIMAL时，仅SIGNED记录与标志、列字符集和几何类型相关的元数据。当设置为FULL完整时，记录表的元数据，例如列名ENUM或SET字符串值、PRIMARY KEY信息等。扩展元数据用于以下目的：
- 当表结构与源表结构不同时，副本使用元数据传输数据。
- 外部软件可以使用元数据来解码行事件并将数据存储到外部数据库中，例如数据仓库。
-
命令行格式 --binlog-row-value-options=#系统变量 binlog_row_value_options范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 放 默认值 `` 有效值 PARTIAL_JSON当设置为 时
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 文档存储在前映像中，而部分更新仅存储在后映像中。mysqlbinlog
BINLOG输出包括使用语句编码为 base-64 字符串的事件形式的部分 JSON 更新如果--verbose指定了该选项， mysqlbinlog使用伪 SQL 语句将部分 JSON 更新显示为可读 JSON。如果无法将修改应用于副本上的 JSON 文档，MySQL 复制会生成错误。这包括找不到路径。请注意，即使进行了此安全检查和其他安全检查，如果副本上的 JSON 文档与源上的文档有所不同，并且应用了部分更新，理论上仍然可以在副本上生成有效但意外的 JSON 文档。
-
binlog_rows_query_log_events命令行格式 --binlog-rows-query-log-events[={OFF|ON}]系统变量 binlog_rows_query_log_events范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF此系统变量仅影响基于行的日志记录。启用后，它会导致服务器将信息日志事件（例如行查询日志事件）写入其二进制日志。此信息可用于调试和相关目的，例如当无法从行更新中重建时，获取在源上发出的原始查询。
设置此系统变量的会话值是一项受限操作。会话用户必须具有足以设置受限会话变量的权限。请参见 第 5.1.9.1 节，“系统变量权限”。
这些信息事件通常会被读取二进制日志的 MySQL 程序忽略，因此在从备份复制或恢复时不会出现问题。
--verbose要查看它们，请使用 mysqlbinlog 的选项两次来增加详细级别 ，无论是 as-vv还是--verbose --verbose. -
命令行格式 --binlog-stmt-cache-size=#系统变量 binlog_stmt_cache_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 32768最小值 4096最大值（64 位平台） 18446744073709547520最大值（32 位平台） 4294963200单元 字节 块大小 4096二进制日志用于保存事务期间发出的非事务语句的内存缓冲区的大小。
块大小是 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小的精确倍数的值向下舍入到块大小的下一个较低倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
在服务器上启用二进制日志记录时（使用
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命令行格式 --binlog-transaction-compression[={OFF|ON}]介绍 8.0.20 系统变量 binlog_transaction_compression范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF为写入此服务器上的二进制日志文件的事务启用压缩。
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 之前，此变量对记录
NDBCLUSTER表上的事务没有影响。在 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-level-zstd=#介绍 8.0.20 系统变量 binlog_transaction_compression_level_zstd范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 3最小值 1最大值 22设置此服务器上二进制日志事务压缩的压缩级别，由
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命令行格式 --binlog-transaction-dependency-tracking=value系统变量 binlog_transaction_dependency_tracking范围 全局 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 COMMIT_ORDER有效值 COMMIT_ORDER``WRITESET``WRITESET_SESSION对于具有多线程副本（
replica_parallel_workers或slave_parallel_workers大于0的副本）的复制源服务器，binlog_transaction_dependency_tracking指定源mysqld如何生成它写入二进制日志中的依赖信息，以帮助副本确定哪些事务可以并行执行。复制源写入的依赖信息使用逻辑时间戳表示。（因此，设置此变量需要
replica_parallel_type或slave_parallel_type已经设置为LOGICAL_CLOCK。）这里列出了每个事务的两个逻辑时间戳：sequence_number：对于给定二进制日志中的第一个事务，这是 1，对于第二个事务，这是 2，依此类推。编号从每个二进制日志文件中的 1 重新开始。last_committed：这是指sequence_number最近提交的事务与当前事务的冲突。该值始终小于sequence_number。
binlog_transaction_dependency_tracking控制用于计算这些逻辑时间戳的方案的选择。此处列出了可用的选项：-
COMMIT_ORDER：如果第一个事务的提交时间窗口与第二个事务的提交时间窗口重叠，则认为两个事务是独立的。这是默认值。提交时间窗口在事务的最后一条语句执行后立即开始，并在存储引擎提交结束后立即结束。由于事务在这两个时间点之间持有所有行锁，我们知道它们不能更新相同的行。
-
WRITESET：逻辑时间戳是基于COMMIT_ORDER结合基于事务写入集的第二种方案计算的。事务中的每一行将一组一个或多个散列添加到事务的写入集，行中的每个唯一键之一。（如果没有唯一的、不可为空的键，则使用该行的哈希。）这包括已删除和插入的行；对于更新的行，还包括旧行和新行。如果两个事务的写入集重叠，则认为两个事务发生冲突——也就是说，如果两个事务的写入集中出现了一些数字（哈希）。另外，由于写集的计算方式，存在周期性的序列化点，使得写集计算过程将序列化点之后的每个事务与序列化点之前的每个事务视为冲突。序列化点仅影响由
WRITESET算法; 序列化点两侧的事务可能具有重叠的提交时间窗口，因此尽管如此，仍可以在副本上并行化。序列化点出现在 DDL 语句、更新具有外键的表的事务以及会话值transaction_write_set_extraction与全局值不同的事务中。如果自上一个序列化点以来提交的事务已经生成了至少binlog_transaction_dependency_history_size唯一的哈希值，那么也会施加一个序列化点。 -
WRITESET_SESSION：如果以下任一陈述为真，则认为两个事务是相互依赖的：- 事务依赖于
WRITESET。 - 事务在同一个用户会话中提交。
- 事务依赖于
在
WRITESETorWRITESET_SESSION模式下，源用于COMMIT_ORDER为具有空或部分写入集的事务、更新没有主键或唯一键的表的事务以及更新外键关系中的父表的事务生成依赖关系信息。要设置
binlog_transaction_dependency_tracking为WRITESET或WRITESET_SESSION，transaction_write_set_extraction必须设置为OFF;以外的值 默认值 (XXHASH64) 就足够了。 无论何时是 或transaction_write_set_extraction的值都不能更改 。直到副本停止并使用and 重新启动后，该值的任何更改才会对复制的事务生效 。binlog_transaction_dependency_tracking``WRITESET``WRITESET_SESSIONSTOP REPLICASTART REPLICA要保留和检查是否已更改给定行的最新事务的行哈希数由 的值确定
binlog_transaction_dependency_history_size。当从中继日志应用事务时，组复制在认证后执行自己的并行化，独立于为 设置的任何值
binlog_transaction_dependency_tracking，但此变量确实会影响事务如何写入组复制成员上的二进制日志。这些日志中的依赖信息用于协助从捐赠者的二进制日志进行状态转移以进行分布式恢复，每当成员加入或重新加入组时，就会发生这种情况。对于该过程，设置binlog_transaction_dependency_tracking为WRITESET可以提高组成员的性能，具体取决于组的工作负载。 -
binlog_transaction_dependency_history_size命令行格式 --binlog-transaction-dependency-history-size=#系统变量 binlog_transaction_dependency_history_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 25000最小值 1最大值 1000000设置保存在内存中并用于查找最后修改给定行的事务的行哈希数的上限。一旦达到这个哈希值，历史就会被清除。
-
命令行格式 --expire-logs-days=#已弃用 是的 系统变量 expire_logs_days范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 0最小值 0最大值 99单元 天 指定自动删除二进制日志文件之前的天数。
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或expire_logs_days为非零值。由于 的默认值为binlog_expire_logs_seconds非零，因此您必须先明确设置binlog_expire_logs_seconds为零，然后才能设置或更改 的值expire_logs_days。要禁用二进制日志的自动清除，请为 显式指定值 0
binlog_expire_logs_seconds，并且不要为 指定值expire_logs_days。为了与早期版本兼容，如果您明确指定值 0expire_logs_days并且不指定 值， 也会禁用自动清除binlog_expire_logs_seconds。在这种情况下，binlog_expire_logs_seconds不应用默认值。要手动删除二进制日志文件，请使用该
PURGE BINARY LOGS语句。请参阅第 13.4.1.1 节，“PURGE BINARY LOGS 语句”。 -
系统变量 log_bin范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 显示服务器上二进制日志的状态，启用 (
ON) 或禁用 (OFF)。启用二进制日志后，服务器会将所有更改数据的语句记录到二进制日志中，用于备份和复制。ON表示二进制日志可用，OFF表示未使用。该--log-bin选项可用于指定二进制日志的基本名称和位置。在早期的 MySQL 版本中，默认情况下禁用二进制日志记录，如果您指定了该选项，则会启用该
--log-bin选项。从 MySQL 8.0 开始，二进制日志默认启用，log_bin系统变量设置为ON，无论您是否指定该--log-bin选项。例外情况是，如果您使用mysqld通过使用--initializeor--initialize-insecure选项手动初始化数据目录，则默认情况下禁用二进制日志记录。在这种情况下，可以通过指定--log-bin选项来启用二进制日志记录。如果在启动时指定了
--skip-log-binor--disable-log-bin选项，则二进制日志记录被禁用，log_bin系统变量设置为OFF. 如果指定并且--log-bin还指定了这些选项中的任何一个，则后面指定的选项优先。有关二进制日志的格式和管理的信息，请参阅第 5.4.4 节，“二进制日志”。
-
系统变量 log_bin_basename范围 全局 动态的 不 SET_VAR提示适用不 类型 文件名 保存二进制日志文件的基本名称和路径，可以使用
--log-binserver 选项进行设置。最大变量长度为 256。在 MySQL 8.0 中，如果--log-bin未提供该选项，则默认基本名称为binlog. 为了与 MySQL 5.7 兼容，如果--log-bin提供的选项没有字符串或空字符串，则默认基本名称是*host_name*-bin，使用主机名。默认位置是数据目录。 -
命令行格式 --log-bin-index=file_name系统变量 log_bin_index范围 全局 动态的 不 SET_VAR提示适用不 类型 文件名 保存二进制日志索引文件的基本名称和路径，可以使用
--log-bin-indexserver 选项进行设置。最大可变长度为 256。 -
log_bin_trust_function_creators命令行格式 --log-bin-trust-function-creators[={OFF|ON}]系统变量 log_bin_trust_function_creators范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF此变量在启用二进制日志记录时适用。它控制是否可以信任存储函数创建者不会创建可能导致不安全事件写入二进制日志的存储函数。如果设置为 0（默认值），则不允许用户创建或更改存储的函数，除非他们具有
SUPER除CREATE ROUTINEor权限之外的ALTER ROUTINE权限。DETERMINISTIC设置为 0 还强制执行必须使用特征或使用READS SQL DATAor声明函数的限制NO SQL特征。如果变量设置为 1，MySQL 不会对存储函数的创建实施这些限制。此变量也适用于触发器创建。请参阅第 25.7 节，“存储程序二进制日志记录”。 -
命令行格式 --log-bin-use-v1-row-events[={OFF|ON}]已弃用 8.0.18 系统变量 log_bin_use_v1_row_events范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF此只读系统变量已弃用。将系统变量设置为
ON在服务器启动时启用基于行的复制，通过使用版本 1 二进制日志行事件写入二进制日志，而不是 MySQL 5.6 的默认版本 2 二进制日志行事件，使用运行 MySQL Server 5.5 和更早版本的副本. -
命令行格式 --log-replica-updates[={OFF|ON}]介绍 8.0.26 系统变量 log_replica_updates范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 默认值 ON从 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[={OFF|ON}]已弃用 8.0.26 系统变量 log_slave_updates范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 默认值 ON从 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命令行格式 --log-statements-unsafe-for-binlog[={OFF|ON}]系统变量 log_statements_unsafe_for_binlog范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 ON如果遇到错误 1592，控制是否将生成的警告添加到错误日志中。
-
命令行格式 --master-verify-checksum[={OFF|ON}]已弃用 8.0.26 系统变量 master_verify_checksum范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF从 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=#系统变量 max_binlog_cache_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 18446744073709547520最小值 4096最大值 18446744073709547520单元 字节 块大小 4096如果一个事务需要超过这么多字节的内存，服务器会生成一个多语句事务需要超过 ‘max_binlog_cache_size’ 字节的存储错误。最小值为 4096。可能的最大值为 16EiB（exbibytes）。最大推荐值为4GB；这是因为 MySQL 目前无法处理大于 4GB 的二进制日志位置。
块大小是 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小的精确倍数的值向下舍入到块大小的下一个较低倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
max_binlog_cache_size仅设置事务缓存的大小；语句缓存的上限由max_binlog_stmt_cache_size系统变量控制。会话的可见性
max_binlog_cache_size匹配binlog_cache_size系统变量的可见性；换句话说，更改其值只会影响更改值后启动的新会话。 -
命令行格式 --max-binlog-size=#系统变量 max_binlog_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 1073741824最小值 4096最大值 1073741824单元 字节 块大小 4096如果写入二进制日志导致当前日志文件大小超过此变量的值，则服务器轮换二进制日志（关闭当前文件并打开下一个文件）。最小值为 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=#系统变量 max_binlog_stmt_cache_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 18446744073709547520最小值 4096最大值 18446744073709547520单元 字节 块大小 4096如果事务中的非事务语句需要超过这么多字节的内存，则服务器会生成错误。最小值为 4096。最大值和默认值在 32 位平台上为 4GB，在 64 位平台上为 16EB（艾字节）。
块大小是 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小的精确倍数的值向下舍入到块大小的下一个较低倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
max_binlog_stmt_cache_size仅设置语句缓存的大小；事务缓存的上限完全由max_binlog_cache_size系统变量控制。 -
系统变量 original_commit_timestamp范围 会议 动态的 是的 SET_VAR提示适用不 类型 数字 供复制内部使用。在副本上重新执行事务时，这将设置为事务在原始源上提交的时间，以自纪元以来的微秒为单位。这允许原始提交时间戳在整个复制拓扑中传播。
设置此系统变量的会话值是一项受限操作。会话用户必须具有
REPLICATION_APPLIER特权（请参阅第 17.3.3 节，“复制特权检查”）或足以设置受限会话变量的特权（请参阅第 5.1.9.1 节，“系统变量特权”）。但是请注意，该变量不是供用户设置的；它由复制基础设施自动设置。 -
命令行格式 --source-verify-checksum[={OFF|ON}]介绍 8.0.26 系统变量 source_verify_checksum范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF从 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范围 会议 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 ON此变量控制是否为当前会话启用日志记录到二进制日志（假设二进制日志本身已启用）。默认值为
ON。要为当前会话禁用或启用二进制日志记录，请将会话sql_log_bin变量设置为OFF或ON。将此变量设置
OFF为会话以暂时禁用二进制日志记录，同时对不希望复制到副本的源进行更改。设置此系统变量的会话值是一项受限操作。会话用户必须具有足以设置受限会话变量的权限。请参见 第 5.1.9.1 节，“系统变量权限”。
无法
sql_log_bin在事务或子查询中设置会话值。设置此变量以
OFF防止将 GTID 分配给二进制日志中的事务。如果您使用 GTID 进行复制，这意味着即使稍后再次启用二进制日志记录，从此时写入日志的 GTID 也不会考虑同时发生的任何事务，因此实际上这些事务会丢失。 -
命令行格式 --sync-binlog=#系统变量 sync_binlog范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 1最小值 0最大值 4294967295控制 MySQL 服务器将二进制日志同步到磁盘的频率。
sync_binlog=0：禁用 MySQL 服务器将二进制日志同步到磁盘。相反，MySQL 服务器依赖操作系统不时将二进制日志刷新到磁盘，就像它对任何其他文件所做的那样。此设置提供了最佳性能，但如果发生电源故障或操作系统崩溃，服务器可能已提交尚未同步到二进制日志的事务。sync_binlog=1：在提交事务之前启用二进制日志到磁盘的同步。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。在电源故障或操作系统崩溃的情况下，二进制日志中丢失的事务仅处于准备状态。这允许自动恢复例程回滚事务，从而保证不会从二进制日志中丢失事务。sync_binlog=*N*, 其中是 0 或 1 以外的值：在收集到二进制日志提交组*N*后，将二进制日志同步到磁盘 。N在电源故障或操作系统崩溃的情况下，服务器可能已经提交了尚未刷新到二进制日志的事务。由于磁盘写入次数增加，此设置可能会对性能产生负面影响。较高的值会提高性能，但会增加数据丢失的风险。
InnoDB为了在与事务一起使用 的复制设置中获得最大可能的持久性和一致性，请使用以下设置：警告
许多操作系统和一些磁盘硬件欺骗了刷新到磁盘操作。他们可能会告诉 mysqld已经发生了刷新，即使它还没有发生。在这种情况下，即使使用推荐的设置也无法保证事务的持久性，在最坏的情况下，断电可能会损坏
InnoDB数据。在 SCSI 磁盘控制器或磁盘本身中使用电池支持的磁盘缓存可加快文件刷新速度，并使操作更安全。您还可以尝试禁用硬件缓存中磁盘写入的缓存。 -
transaction_write_set_extraction命令行格式 --transaction-write-set-extraction[=value]已弃用 8.0.26 系统变量 transaction_write_set_extraction范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 XXHASH64有效值 OFF``MURMUR32``XXHASH64此系统变量指定用于散列事务期间提取的写入的算法。默认值为
XXHASH64.OFF表示不收集写入集。transaction_write_set_extraction自 MySQL 8.0.26 起已弃用；期望它在未来的 MySQL 版本中被删除。组复制需要该
XXHASH64设置，其中从事务中提取写入的过程用于对所有组成员进行冲突检测和认证（请参阅 第 18.3.1 节，“组复制要求”）。对于具有多线程副本的复制源服务器（副本，其replica_parallel_workersorslave_parallel_workers设置为大于 0 的值），其中binlog_transaction_dependency_tracking设置为WRITESETorWRITESET_SESSION，transaction_write_set_extraction不得为OFF。而当前值binlog_transaction_dependency_trackingisWRITESET或WRITESET_SESSION，您无法更改 的值transaction_write_set_extraction。从 MySQL 8.0.14 开始，设置这个系统变量的 session 值是一个受限操作；会话用户必须具有足够的权限来设置受限会话变量（请参阅 第 5.1.9.1 节，“系统变量权限”）。
binlog_format必须设置为ROW更改 的值transaction_write_set_extraction。如果您更改该值，则新值不会对复制的事务生效，直到使用STOP REPLICA和停止并重新启动副本之后START REPLICA。#### 7.1.6.4 二进制日志选项和变量
您可以使用本节中描述的mysqld选项和系统变量来影响二进制日志的操作以及控制将哪些语句写入二进制日志。有关二进制日志的更多信息，请参阅第 5.4.4 节，“二进制日志”。有关使用 MySQL 服务器选项和系统变量的其他信息，请参阅第 5.1.7 节，“服务器命令选项”和 第 5.1.8 节，“服务器系统变量”。
与二进制日志记录一起使用的启动选项
以下列表描述了用于启用和配置二进制日志的启动选项。本节稍后将讨论与二进制日志记录一起使用的系统变量。
-
--binlog-row-event-max-size=*N*命令行格式 --binlog-row-event-max-size=#系统变量 (≥ 8.0.14) binlog_row_event_max_size范围（≥8.0.14） 全局 动态（≥ 8.0.14） 不 SET_VAR提示适用 (≥ 8.0.14)不 类型 整数 默认值 8192最小值 256最大值（64 位平台） 18446744073709551615最大值（32 位平台） 4294967295单元 字节 当使用基于行的二进制日志时，此设置是对基于行的二进制日志事件的最大大小的软限制，以字节为单位。在可能的情况下，存储在二进制日志中的行被分组为大小不超过此设置值的事件。如果无法拆分事件，则可以超出最大大小。该值必须是（否则会向下舍入）256 的倍数。默认值为 8192 字节。
-
命令行格式 --log-bin=file_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通过使用--initializeor--initialize-insecure选项手动初始化数据目录，则默认情况下禁用二进制日志记录。在这种情况下，可以通过指定--log-bin选项来启用二进制日志记录。启用二进制日志记录后，log_bin显示服务器上二进制日志状态的系统变量设置为 ON。要禁用二进制日志记录，您可以在启动时指定
--skip-log-binor--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-binMySQL 在指定或 时默认禁用这些选项--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=file_name系统变量 log_bin_index范围 全局 动态的 不 SET_VAR提示适用不 类型 文件名 二进制日志索引文件的名称，其中包含二进制日志文件的名称。默认情况下，它具有与使用该
--log-bin选项为二进制日志文件指定的值相同的位置和基本名称，加上扩展名.index. 如果不指定--log-bin，默认的二进制日志索引文件名为binlog.index. 如果您指定--log-bin不带字符串或空字符串的选项，则默认二进制日志索引文件名称为*host_name*-bin.index，使用主机名称。有关二进制日志的格式和管理的信息，请参阅第 5.4.4 节，“二进制日志”。
语句选择选项。 以下列表中的选项影响将哪些语句写入二进制日志，从而由复制源服务器发送到其副本。副本还有一些选项可以控制从源接收到的哪些语句应该被执行或忽略。有关详细信息，请参阅 第 17.1.6.3 节，“副本服务器选项和变量”。
-
命令行格式 --binlog-do-db=name类型 细绳 此选项以类似于
--replicate-do-db影响复制的方式影响二进制日志记录。此选项的效果取决于使用的是基于语句还是基于行的日志记录格式，其效果
--replicate-do-db取决于使用的是基于语句还是基于行的复制。您应该记住，用于记录给定语句的格式不一定与 的值所指示的格式相同binlog_format。例如，诸如CREATE TABLEand之类的 DDL 语句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-dbUSE 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由以下内容所做的更改：UPDATEUSE 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会记录对 to 的更改，而不是对 to的table2更改——换句话说，只--binlog-do-db记录对名为 by 的数据库中的表的更改，并且选择默认数据库对此行为没有影响。 -
命令行格式 --binlog-ignore-db=name类型 细绳 此选项以类似于
--replicate-ignore-db影响复制的方式影响二进制日志记录。此选项的效果取决于使用的是基于语句还是基于行的日志记录格式，其效果
--replicate-ignore-db取决于使用的是基于语句还是基于行的复制。您应该记住，用于记录给定语句的格式不一定与 的值所指示的格式相同binlog_format。例如，诸如CREATE TABLEand之类的 DDL 语句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-dbUSEsalesUPDATEsales.january--binlog-ignore-db=salessales出于二进制日志记录目的而忽略的数据库。要指定多个要忽略的数据库，请多次使用此选项，每个数据库一次。因为数据库名称可以包含逗号，所以如果您提供逗号分隔的列表，则该列表将被视为单个数据库的名称。
如果您使用跨数据库更新并且不希望记录这些更新，则不应使用此选项。
校验和选项。 MySQL 支持二进制日志校验和的读写。这些是使用此处列出的两个选项启用的：
-
--binlog-checksum={NONE|CRC32}命令行格式 --binlog-checksum=type类型 细绳 默认值 CRC32有效值 NONE``CRC32启用此选项会导致源为写入二进制日志的事件写入校验和。设置为
NONE禁用，或用于生成校验和的算法的名称；目前，仅支持 CRC32 校验和，CRC32 为默认值。您不能在事务中更改此选项的设置。
要控制副本读取校验和（来自中继日志），请使用该 --slave-sql-verify-checksum 选项。
测试和调试选项。 以下二进制日志选项用于复制测试和调试。它们不适用于正常操作。
-
命令行格式 --max-binlog-dump-events=#类型 整数 默认值 0MySQL 测试套件在内部使用此选项进行复制测试和调试。
-
命令行格式 --sporadic-binlog-dump-fail[={OFF|ON}]类型 布尔值 默认值 OFFMySQL 测试套件在内部使用此选项进行复制测试和调试。
与二进制日志记录一起使用的系统变量
以下列表描述了用于控制二进制日志记录的系统变量。它们可以在服务器启动时设置，其中一些可以在运行时使用 SET. 本节前面列出了用于控制二进制日志记录的服务器选项。
-
命令行格式 --binlog-cache-size=#系统变量 binlog_cache_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 32768最小值 4096最大值（64 位平台） 18446744073709547520最大值（32 位平台） 4294963200单元 字节 块大小 4096在事务期间保存二进制日志更改的内存缓冲区的大小。
块大小是 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小的精确倍数的值向下舍入到块大小的下一个较低倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
在服务器上启用二进制日志记录（
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=name系统变量 binlog_checksum范围 全局 动态的 是的 SET_VAR提示适用不 类型 细绳 默认值 CRC32有效值 NONE``CRC32启用后，此变量会导致源为二进制日志中的每个事件写入校验和。
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命令行格式 --binlog-direct-non-transactional-updates[={OFF|ON}]系统变量 binlog_direct_non_transactional_updates范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF由于并发问题，当事务包含对事务表和非事务表的更新时，副本可能会变得不一致。MySQL 试图通过将非事务性语句写入事务缓存中来保持这些语句之间的因果关系，该事务缓存在提交时被刷新。但是，当代表事务对非事务表所做的修改对其他连接立即可见时，就会出现问题，因为这些更改可能不会立即写入二进制日志。
该
binlog_direct_non_transactional_updates变量为此问题提供了一种可能的解决方法。默认情况下，此变量被禁用。启用binlog_direct_non_transactional_updates会导致对非事务表的更新直接写入二进制日志，而不是写入事务缓存。从 MySQL 8.0.14 开始，设置此系统变量的会话值是一项受限操作。会话用户必须具有足以设置受限会话变量的权限。请参见第 5.1.9.1 节，“系统变量权限”。
binlog_direct_non_transactional_updates仅适用于使用基于语句的二进制日志记录格式复制的语句；也就是说，它仅在 is 的值binlog_format，STATEMENT或者当binlog_formatisMIXED和给定语句使用基于语句的格式复制时才有效。当二进制日志格式为 时，此变量无效ROW，或者何时binlog_format设置为MIXED并且使用基于行的格式复制给定语句。重要的
在启用此变量之前，您必须确保事务表和非事务表之间没有依赖关系；这种依赖关系的一个例子是语句
INSERT INTO myisam_table SELECT * FROM innodb_table。否则，这样的语句很可能会导致副本偏离源。ROW当二进制日志格式为或 时，此变量无效MIXED。 -
命令行格式 --binlog-encryption[={OFF|ON}]介绍 8.0.14 系统变量 binlog_encryption范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF启用此服务器上的二进制日志文件和中继日志文件的加密。
OFF是默认值。ON为二进制日志文件和中继日志文件设置加密。不需要在服务器上启用二进制日志来启用加密，因此您可以在没有二进制日志的副本上加密中继日志文件。要使用加密，必须安装和配置密钥环插件以提供 MySQL 服务器的密钥环服务。有关执行此操作的说明，请参阅第 6.4.4 节，“MySQL 密钥环”。任何受支持的密钥环插件都可用于存储二进制日志加密密钥。首次启动启用二进制日志加密的服务器时，会在初始化二进制日志和中继日志之前生成一个新的二进制日志加密密钥。此密钥用于加密每个二进制日志文件（如果服务器启用了二进制日志记录）和中继日志文件（如果服务器具有复制通道）的文件密码，并且从文件密码生成的进一步密钥用于加密数据在文件中。中继日志文件为所有通道加密，包括组复制应用程序通道和激活加密后创建的新通道。二进制日志索引文件和中继日志索引文件从不加密。
如果您在服务器运行时激活加密，则此时会生成一个新的二进制日志加密密钥。例外情况是，如果加密之前在服务器上处于活动状态，然后被禁用，在这种情况下，之前使用的二进制日志加密密钥会再次使用。二进制日志文件和中继日志文件立即轮换，新文件的文件密码以及所有后续二进制日志文件和中继日志文件都使用此二进制日志加密密钥进行加密。仍然存在于服务器上的现有二进制日志文件和中继日志文件不会自动加密，但如果不再需要它们，您可以清除它们。
如果您通过将
binlog_encryption系统变量更改为 来停用加密OFF，则二进制日志文件和中继日志文件将立即轮换，并且所有后续日志记录均未加密。以前加密的文件不会自动解密，但服务器仍然可以读取它们。在服务器运行时激活或停用加密需要该BINLOG_ENCRYPTION_ADMIN权限（或已弃用的 权限）。SUPER组复制应用程序通道不包含在中继日志轮换请求中，因此这些通道的未加密日志记录在其日志在正常使用中轮换之前不会启动。有关二进制日志文件和中继日志文件加密的更多信息，请参阅 第 17.3.2 节，“加密二进制日志文件和中继日志文件”。
-
命令行格式 --binlog-error-action[=value]系统变量 binlog_error_action范围 全局 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 ABORT_SERVER有效值 IGNORE_ERROR``ABORT_SERVER控制当服务器遇到错误时会发生什么，例如无法写入、刷新或同步二进制日志，这可能导致源的二进制日志变得不一致，副本失去同步。
此变量默认为
ABORT_SERVER，这会使服务器在遇到二进制日志的此类错误时停止日志记录并关闭。重新启动时，恢复会像服务器意外停止一样继续进行（请参阅 第 17.4.2 节，“处理副本的意外停止”）。当
binlog_error_action设置为 时IGNORE_ERROR，如果服务器遇到此类错误，它将继续进行中的事务，记录错误，然后停止记录，并继续执行更新。要恢复二进制日志log_bin，必须再次启用，这需要重新启动服务器。此设置提供与旧版本 MySQL 的向后兼容性。 -
命令行格式 --binlog-expire-logs-seconds=#系统变量 binlog_expire_logs_seconds范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 2592000最小值 0最大值 4294967295单元 秒 以秒为单位设置二进制日志过期时间。在它们的有效期结束后，二进制日志文件可以被自动删除。可能的删除发生在启动和刷新二进制日志时。日志刷新发生在第 5.4 节，“MySQL 服务器日志”中。
默认二进制日志有效期为 2592000 秒，即 30 天（302460*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_seconds或expire_logs_days为非零值。由于 的默认值为binlog_expire_logs_seconds非零，因此您必须先明确设置binlog_expire_logs_seconds为零，然后才能设置或更改 的值expire_logs_days。从 MySQL 8.0.29 开始，可以通过将
binlog_expire_logs_auto_purge系统变量设置为OFF. 这优先于 的任何设置binlog_expire_logs_seconds。在 MySQL 8.0.28 及更早版本中，要禁用二进制日志的自动清除，请为 显式指定值 0
binlog_expire_logs_seconds，并且不要为 指定值expire_logs_days。为了与早期版本兼容，如果您明确指定值 0expire_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}介绍 8.0.29 系统变量 binlog_expire_logs_auto_purge范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 ON启用或禁用二进制日志文件的自动清除。将此变量设置为
ON（默认值）启用自动清除；将其设置为OFF禁用自动清除。清除前等待的时间间隔由binlog_expire_logs_seconds和控制expire_logs_days。笔记
即使
binlog_expire_logs_auto_purge是ON，也设置binlog_expire_logs_seconds和expire_logs_days以0停止发生自动清除。此变量对 没有影响
PURGE BINARY LOGS。 -
命令行格式 --binlog-format=format系统变量 binlog_format范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 ROW有效值 MIXED``STATEMENT``ROW此系统变量设置二进制日志记录格式，可以是
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 节，“存储程序二进制日志记录”。
当您无法在运行时切换复制格式时有例外：
- 无法从存储的函数或触发器中更改复制格式。
- 如果会话具有打开的临时表，则无法更改会话的复制格式 (
SET @@SESSION.binlog_format)。 - 如果任何复制通道具有打开的临时表，则无法全局更改复制格式（
SET @@GLOBAL.binlog_format或SET @@PERSIST.binlog_format）。 - 如果当前正在运行任何复制通道应用程序线程，则无法全局更改复制格式（
SET @@GLOBAL.binlog_format或SET @@PERSIST.binlog_format）。
在任何这些情况下尝试切换复制格式（或尝试设置当前复制格式）都会导致错误。但是，您可以随时使用
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=#系统变量 binlog_group_commit_sync_delay范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 0最小值 0最大值 1000000单元 微秒 控制二进制日志提交在将二进制日志文件同步到磁盘之前等待多少微秒。默认
binlog_group_commit_sync_delay设置为 0，表示没有延迟。设置binlog_group_commit_sync_delay为微秒延迟可以使更多事务一次同步到磁盘，从而减少提交一组事务的总时间，因为较大的组需要较少的时间单位。sync_binlog=0设置或 时 ，在同步之前（或在 的情况下，在继续之前）对每个二进制日志提交组应用sync_binlog=1指定的延迟 。当 设置为大于 1的值n时，在每**n 个二进制日志提交组之后应用延迟。binlog_group_commit_sync_delaysync_binlog=0sync_binlog设置
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-no-delay-count=#系统变量 binlog_group_commit_sync_no_delay_count范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 0最小值 0最大值 100000中止当前延迟之前等待的最大事务数，由 指定
binlog_group_commit_sync_delay。如果binlog_group_commit_sync_delay设置为 0，则此选项无效。 -
命令行格式 --binlog-max-flush-queue-time=#已弃用 是的 系统变量 binlog_max_flush_queue_time范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 0最小值 0最大值 100000单元 微秒 binlog_max_flush_queue_time已弃用，并标记为在未来的 MySQL 版本中最终删除。以前，此系统变量以微秒为单位控制在继续进行组提交之前继续从刷新队列中读取事务的时间。它不再有任何作用。 -
命令行格式 --binlog-order-commits[={OFF|ON}]系统变量 binlog_order_commits范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 ON当在复制源服务器上启用此变量时（这是默认设置），发送到存储引擎的事务提交指令在单个线程上进行序列化，以便事务始终以与写入二进制日志相同的顺序提交。禁用此变量允许使用多个线程发出事务提交指令。与二进制日志组提交结合使用，可以防止单个事务的提交率成为吞吐量的瓶颈，因此可能会提高性能。
当所有涉及的存储引擎都确认事务已准备好提交时，事务将写入二进制日志。然后二进制日志组提交逻辑在其二进制日志写入发生后提交一组事务。什么时候
binlog_order_commits被禁用，因为这个进程使用了多个线程，提交组中的事务可能会以与它们在二进制日志中的顺序不同的顺序提交。（来自单个客户端的事务总是按时间顺序提交。）在许多情况下，这并不重要，因为在不同事务中执行的操作应该产生一致的结果，如果不是这种情况，则应该使用单个事务。如果要确保源和多线程副本上的事务历史记录保持相同，
slave_preserve_commit_order=1请在副本上设置。 -
binlog_rotate_encryption_master_key_at_startup命令行格式 --binlog-rotate-encryption-master-key-at-startup[={OFF|ON}]介绍 8.0.14 系统变量 binlog_rotate_encryption_master_key_at_startup范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 默认值 OFF指定二进制日志主密钥是否在服务器启动时轮换。二进制日志主密钥是二进制日志加密密钥，用于加密服务器上二进制日志文件和中继日志文件的文件密码。在启用二进制日志加密 ( ) 的情况下首次启动服务器时，
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=#系统变量 (≥ 8.0.14) binlog_row_event_max_size范围（≥8.0.14） 全局 动态（≥ 8.0.14） 不 SET_VAR提示适用 (≥ 8.0.14)不 类型 整数 默认值 8192最小值 256最大值（64 位平台） 18446744073709551615最大值（32 位平台） 4294967295单元 字节 当使用基于行的二进制日志时，此设置是对基于行的二进制日志事件的最大大小的软限制，以字节为单位。在可能的情况下，存储在二进制日志中的行被分组为大小不超过此设置值的事件。如果无法拆分事件，则可以超出最大大小。默认值为 8192 字节。
块大小为 256。在存储系统变量的值之前，MySQL 服务器会向下舍入到块大小的下一个较低倍数的值，而不是块大小的精确倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
这个全局系统变量是只读的，只能在服务器启动时设置。因此，它的值只能通过在语句中 使用
PERSIST_ONLY关键字或@@persist_only限定符 来修改。SET -
命令行格式 --binlog-row-image=image_type系统变量 binlog_row_image范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 full有效值 full（记录所有列）minimal（仅记录更改的列，以及标识行所需的列）noblob（记录所有列，不需要的 BLOB 和 TEXT 列除外）对于 MySQL 基于行的复制，此变量确定如何将行图像写入二进制日志。
设置此系统变量的会话值是一项受限操作。会话用户必须具有足以设置受限会话变量的权限。请参见 第 5.1.9.1 节，“系统变量权限”。
在 MySQL 基于行的复制中，每个行更改事件包含两个图像，一个“ before ”图像，其列在搜索要更新的行时匹配，一个“ after ”图像包含更改。通常，MySQL 记录前后图像的完整行（即所有列）。但是，并非绝对需要在两个图像中都包含每一列，而且我们通常可以通过仅记录实际需要的列来节省磁盘、内存和网络使用量。
笔记
删除行时，仅记录之前的图像，因为删除后没有要传播的更改值。插入行时，仅记录后图像，因为没有要匹配的现有行。只有在更新一行时才需要前后图像，并且都写入二进制日志。
对于之前的图像，只需要记录唯一标识行所需的最小列集。如果包含该行的表具有主键，则只有主键列或列被写入二进制日志。否则，如果表有一个唯一键，其所有列都是
NOT NULL，则只需要记录唯一键中的列。（如果表既没有主键也没有唯一键，没有任何NULL列，那么所有列都必须在前映像中使用并记录。）在后映像中，只需记录实际更改的列。binlog_row_image您可以使用系统变量 使服务器记录完整或最少的行。此变量实际上采用三个可能值之一，如下表所示：full：记录前映像和后映像中的所有列。minimal：只记录之前图像中需要识别要更改的行的列；仅记录后映像中由 SQL 语句指定值或通过自动增量生成的那些列。noblob：记录所有列（与 相同full），除了 不需要标识行或未更改的列。BLOBTEXT
笔记
NDB Cluster 不支持此变量；设置它对
NDB表的日志记录没有影响。默认值为
full。使用
minimalornoblob时，当且仅当源表和目标表都满足以下条件时，才能保证删除和更新对给定表正确工作：- 所有列必须存在且顺序相同；每列必须使用与其在另一个表中对应的数据类型相同的数据类型。
- 这些表必须具有相同的主键定义。
（换句话说，除了不属于表主键的索引之外，表必须相同。）
如果不满足这些条件，则可能证明目标表中的主键列值不足以为删除或更新提供唯一匹配。在这种情况下，不会发出警告或错误；源和副本默默地发散，从而破坏了一致性。
当二进制日志记录格式为 时，设置此变量无效
STATEMENT。当binlog_formatisMIXED时，设置binlog_row_image适用于使用基于行的格式记录的更改，但此设置对记录为语句的更改没有影响。在全局或会话级别上设置
binlog_row_image不会导致隐式提交；这意味着可以在事务进行时更改此变量，而不会影响事务。 -
命令行格式 --binlog-row-metadata=metadata_type系统变量 binlog_row_metadata范围 全局 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 MINIMAL有效值 FULL（包括所有元数据）MINIMAL（限制包含的元数据）配置使用基于行的日志记录时添加到二进制日志的表元数据量。默认设置为
MINIMAL时，仅SIGNED记录与标志、列字符集和几何类型相关的元数据。当设置为FULL完整时，记录表的元数据，例如列名ENUM或SET字符串值、PRIMARY KEY信息等。扩展元数据用于以下目的：
- 当表结构与源表结构不同时，副本使用元数据传输数据。
- 外部软件可以使用元数据来解码行事件并将数据存储到外部数据库中，例如数据仓库。
-
命令行格式 --binlog-row-value-options=#系统变量 binlog_row_value_options范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 放 默认值 `` 有效值 PARTIAL_JSON当设置为 时
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 文档存储在前映像中，而部分更新仅存储在后映像中。mysqlbinlog
BINLOG输出包括使用语句编码为 base-64 字符串的事件形式的部分 JSON 更新如果--verbose指定了该选项， mysqlbinlog使用伪 SQL 语句将部分 JSON 更新显示为可读 JSON。如果无法将修改应用于副本上的 JSON 文档，MySQL 复制会生成错误。这包括找不到路径。请注意，即使进行了此安全检查和其他安全检查，如果副本上的 JSON 文档与源上的文档有所不同，并且应用了部分更新，理论上仍然可以在副本上生成有效但意外的 JSON 文档。
-
binlog_rows_query_log_events命令行格式 --binlog-rows-query-log-events[={OFF|ON}]系统变量 binlog_rows_query_log_events范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF此系统变量仅影响基于行的日志记录。启用后，它会导致服务器将信息日志事件（例如行查询日志事件）写入其二进制日志。此信息可用于调试和相关目的，例如当无法从行更新中重建时，获取在源上发出的原始查询。
设置此系统变量的会话值是一项受限操作。会话用户必须具有足以设置受限会话变量的权限。请参见 第 5.1.9.1 节，“系统变量权限”。
这些信息事件通常会被读取二进制日志的 MySQL 程序忽略，因此在从备份复制或恢复时不会出现问题。
--verbose要查看它们，请使用 mysqlbinlog 的选项两次来增加详细级别 ，无论是 as-vv还是--verbose --verbose. -
命令行格式 --binlog-stmt-cache-size=#系统变量 binlog_stmt_cache_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 32768最小值 4096最大值（64 位平台） 18446744073709547520最大值（32 位平台） 4294963200单元 字节 块大小 4096二进制日志用于保存事务期间发出的非事务语句的内存缓冲区的大小。
块大小是 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小的精确倍数的值向下舍入到块大小的下一个较低倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
在服务器上启用二进制日志记录时（使用
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命令行格式 --binlog-transaction-compression[={OFF|ON}]介绍 8.0.20 系统变量 binlog_transaction_compression范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF为写入此服务器上的二进制日志文件的事务启用压缩。
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 之前，此变量对记录
NDBCLUSTER表上的事务没有影响。在 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-level-zstd=#介绍 8.0.20 系统变量 binlog_transaction_compression_level_zstd范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 3最小值 1最大值 22设置此服务器上二进制日志事务压缩的压缩级别，由
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命令行格式 --binlog-transaction-dependency-tracking=value系统变量 binlog_transaction_dependency_tracking范围 全局 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 COMMIT_ORDER有效值 COMMIT_ORDER``WRITESET``WRITESET_SESSION对于具有多线程副本（
replica_parallel_workers或slave_parallel_workers大于0的副本）的复制源服务器，binlog_transaction_dependency_tracking指定源mysqld如何生成它写入二进制日志中的依赖信息，以帮助副本确定哪些事务可以并行执行。复制源写入的依赖信息使用逻辑时间戳表示。（因此，设置此变量需要
replica_parallel_type或slave_parallel_type已经设置为LOGICAL_CLOCK。）这里列出了每个事务的两个逻辑时间戳：sequence_number：对于给定二进制日志中的第一个事务，这是 1，对于第二个事务，这是 2，依此类推。编号从每个二进制日志文件中的 1 重新开始。last_committed：这是指sequence_number最近提交的事务与当前事务的冲突。该值始终小于sequence_number。
binlog_transaction_dependency_tracking控制用于计算这些逻辑时间戳的方案的选择。此处列出了可用的选项：-
COMMIT_ORDER：如果第一个事务的提交时间窗口与第二个事务的提交时间窗口重叠，则认为两个事务是独立的。这是默认值。提交时间窗口在事务的最后一条语句执行后立即开始，并在存储引擎提交结束后立即结束。由于事务在这两个时间点之间持有所有行锁，我们知道它们不能更新相同的行。
-
WRITESET：逻辑时间戳是基于COMMIT_ORDER结合基于事务写入集的第二种方案计算的。事务中的每一行将一组一个或多个散列添加到事务的写入集，行中的每个唯一键之一。（如果没有唯一的、不可为空的键，则使用该行的哈希。）这包括已删除和插入的行；对于更新的行，还包括旧行和新行。如果两个事务的写入集重叠，则认为两个事务发生冲突——也就是说，如果两个事务的写入集中出现了一些数字（哈希）。另外，由于写集的计算方式，存在周期性的序列化点，使得写集计算过程将序列化点之后的每个事务与序列化点之前的每个事务视为冲突。序列化点仅影响由
WRITESET算法; 序列化点两侧的事务可能具有重叠的提交时间窗口，因此尽管如此，仍可以在副本上并行化。序列化点出现在 DDL 语句、更新具有外键的表的事务以及会话值transaction_write_set_extraction与全局值不同的事务中。如果自上一个序列化点以来提交的事务已经生成了至少binlog_transaction_dependency_history_size唯一的哈希值，那么也会施加一个序列化点。 -
WRITESET_SESSION：如果以下任一陈述为真，则认为两个事务是相互依赖的：- 事务依赖于
WRITESET。 - 事务在同一个用户会话中提交。
- 事务依赖于
在
WRITESETorWRITESET_SESSION模式下，源用于COMMIT_ORDER为具有空或部分写入集的事务、更新没有主键或唯一键的表的事务以及更新外键关系中的父表的事务生成依赖关系信息。要设置
binlog_transaction_dependency_tracking为WRITESET或WRITESET_SESSION，transaction_write_set_extraction必须设置为OFF;以外的值 默认值 (XXHASH64) 就足够了。 无论何时是 或transaction_write_set_extraction的值都不能更改 。直到副本停止并使用and 重新启动后，该值的任何更改才会对复制的事务生效 。binlog_transaction_dependency_tracking``WRITESET``WRITESET_SESSIONSTOP REPLICASTART REPLICA要保留和检查是否已更改给定行的最新事务的行哈希数由 的值确定
binlog_transaction_dependency_history_size。当从中继日志应用事务时，组复制在认证后执行自己的并行化，独立于为 设置的任何值
binlog_transaction_dependency_tracking，但此变量确实会影响事务如何写入组复制成员上的二进制日志。这些日志中的依赖信息用于协助从捐赠者的二进制日志进行状态转移以进行分布式恢复，每当成员加入或重新加入组时，就会发生这种情况。对于该过程，设置binlog_transaction_dependency_tracking为WRITESET可以提高组成员的性能，具体取决于组的工作负载。 -
binlog_transaction_dependency_history_size命令行格式 --binlog-transaction-dependency-history-size=#系统变量 binlog_transaction_dependency_history_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 25000最小值 1最大值 1000000设置保存在内存中并用于查找最后修改给定行的事务的行哈希数的上限。一旦达到这个哈希值，历史就会被清除。
-
命令行格式 --expire-logs-days=#已弃用 是的 系统变量 expire_logs_days范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 0最小值 0最大值 99单元 天 指定自动删除二进制日志文件之前的天数。
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或expire_logs_days为非零值。由于 的默认值为binlog_expire_logs_seconds非零，因此您必须先明确设置binlog_expire_logs_seconds为零，然后才能设置或更改 的值expire_logs_days。要禁用二进制日志的自动清除，请为 显式指定值 0
binlog_expire_logs_seconds，并且不要为 指定值expire_logs_days。为了与早期版本兼容，如果您明确指定值 0expire_logs_days并且不指定 值， 也会禁用自动清除binlog_expire_logs_seconds。在这种情况下，binlog_expire_logs_seconds不应用默认值。要手动删除二进制日志文件，请使用该
PURGE BINARY LOGS语句。请参阅第 13.4.1.1 节，“PURGE BINARY LOGS 语句”。 -
系统变量 log_bin范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 显示服务器上二进制日志的状态，启用 (
ON) 或禁用 (OFF)。启用二进制日志后，服务器会将所有更改数据的语句记录到二进制日志中，用于备份和复制。ON表示二进制日志可用，OFF表示未使用。该--log-bin选项可用于指定二进制日志的基本名称和位置。在早期的 MySQL 版本中，默认情况下禁用二进制日志记录，如果您指定了该选项，则会启用该
--log-bin选项。从 MySQL 8.0 开始，二进制日志默认启用，log_bin系统变量设置为ON，无论您是否指定该--log-bin选项。例外情况是，如果您使用mysqld通过使用--initializeor--initialize-insecure选项手动初始化数据目录，则默认情况下禁用二进制日志记录。在这种情况下，可以通过指定--log-bin选项来启用二进制日志记录。如果在启动时指定了
--skip-log-binor--disable-log-bin选项，则二进制日志记录被禁用，log_bin系统变量设置为OFF. 如果指定并且--log-bin还指定了这些选项中的任何一个，则后面指定的选项优先。有关二进制日志的格式和管理的信息，请参阅第 5.4.4 节，“二进制日志”。
-
系统变量 log_bin_basename范围 全局 动态的 不 SET_VAR提示适用不 类型 文件名 保存二进制日志文件的基本名称和路径，可以使用
--log-binserver 选项进行设置。最大变量长度为 256。在 MySQL 8.0 中，如果--log-bin未提供该选项，则默认基本名称为binlog. 为了与 MySQL 5.7 兼容，如果--log-bin提供的选项没有字符串或空字符串，则默认基本名称是*host_name*-bin，使用主机名。默认位置是数据目录。 -
命令行格式 --log-bin-index=file_name系统变量 log_bin_index范围 全局 动态的 不 SET_VAR提示适用不 类型 文件名 保存二进制日志索引文件的基本名称和路径，可以使用
--log-bin-indexserver 选项进行设置。最大可变长度为 256。 -
log_bin_trust_function_creators命令行格式 --log-bin-trust-function-creators[={OFF|ON}]系统变量 log_bin_trust_function_creators范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF此变量在启用二进制日志记录时适用。它控制是否可以信任存储函数创建者不会创建可能导致不安全事件写入二进制日志的存储函数。如果设置为 0（默认值），则不允许用户创建或更改存储的函数，除非他们具有
SUPER除CREATE ROUTINEor权限之外的ALTER ROUTINE权限。DETERMINISTIC设置为 0 还强制执行必须使用特征或使用READS SQL DATAor声明函数的限制NO SQL特征。如果变量设置为 1，MySQL 不会对存储函数的创建实施这些限制。此变量也适用于触发器创建。请参阅第 25.7 节，“存储程序二进制日志记录”。 -
命令行格式 --log-bin-use-v1-row-events[={OFF|ON}]已弃用 8.0.18 系统变量 log_bin_use_v1_row_events范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF此只读系统变量已弃用。将系统变量设置为
ON在服务器启动时启用基于行的复制，通过使用版本 1 二进制日志行事件写入二进制日志，而不是 MySQL 5.6 的默认版本 2 二进制日志行事件，使用运行 MySQL Server 5.5 和更早版本的副本. -
命令行格式 --log-replica-updates[={OFF|ON}]介绍 8.0.26 系统变量 log_replica_updates范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 默认值 ON从 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[={OFF|ON}]已弃用 8.0.26 系统变量 log_slave_updates范围 全局 动态的 不 SET_VAR提示适用不 类型 布尔值 默认值 ON从 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命令行格式 --log-statements-unsafe-for-binlog[={OFF|ON}]系统变量 log_statements_unsafe_for_binlog范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 ON如果遇到错误 1592，控制是否将生成的警告添加到错误日志中。
-
命令行格式 --master-verify-checksum[={OFF|ON}]已弃用 8.0.26 系统变量 master_verify_checksum范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF从 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=#系统变量 max_binlog_cache_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 18446744073709547520最小值 4096最大值 18446744073709547520单元 字节 块大小 4096如果一个事务需要超过这么多字节的内存，服务器会生成一个多语句事务需要超过 ‘max_binlog_cache_size’ 字节的存储错误。最小值为 4096。可能的最大值为 16EiB（exbibytes）。最大推荐值为4GB；这是因为 MySQL 目前无法处理大于 4GB 的二进制日志位置。
块大小是 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小的精确倍数的值向下舍入到块大小的下一个较低倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
max_binlog_cache_size仅设置事务缓存的大小；语句缓存的上限由max_binlog_stmt_cache_size系统变量控制。会话的可见性
max_binlog_cache_size匹配binlog_cache_size系统变量的可见性；换句话说，更改其值只会影响更改值后启动的新会话。 -
命令行格式 --max-binlog-size=#系统变量 max_binlog_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 1073741824最小值 4096最大值 1073741824单元 字节 块大小 4096如果写入二进制日志导致当前日志文件大小超过此变量的值，则服务器轮换二进制日志（关闭当前文件并打开下一个文件）。最小值为 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=#系统变量 max_binlog_stmt_cache_size范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 18446744073709547520最小值 4096最大值 18446744073709547520单元 字节 块大小 4096如果事务中的非事务语句需要超过这么多字节的内存，则服务器会生成错误。最小值为 4096。最大值和默认值在 32 位平台上为 4GB，在 64 位平台上为 16EB（艾字节）。
块大小是 4096。在存储系统变量的值之前，MySQL 服务器会将不是块大小的精确倍数的值向下舍入到块大小的下一个较低倍数。解析器允许平台的最大无符号整数值（4294967295 或 2 32 -1 用于 32 位系统，18446744073709551615 或 2 64 -1 用于 64 位系统），但实际最大值比块大小小.
max_binlog_stmt_cache_size仅设置语句缓存的大小；事务缓存的上限完全由max_binlog_cache_size系统变量控制。 -
系统变量 original_commit_timestamp范围 会议 动态的 是的 SET_VAR提示适用不 类型 数字 供复制内部使用。在副本上重新执行事务时，这将设置为事务在原始源上提交的时间，以自纪元以来的微秒为单位。这允许原始提交时间戳在整个复制拓扑中传播。
设置此系统变量的会话值是一项受限操作。会话用户必须具有
REPLICATION_APPLIER特权（请参阅第 17.3.3 节，“复制特权检查”）或足以设置受限会话变量的特权（请参阅第 5.1.9.1 节，“系统变量特权”）。但是请注意，该变量不是供用户设置的；它由复制基础设施自动设置。 -
命令行格式 --source-verify-checksum[={OFF|ON}]介绍 8.0.26 系统变量 source_verify_checksum范围 全局 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 OFF从 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范围 会议 动态的 是的 SET_VAR提示适用不 类型 布尔值 默认值 ON此变量控制是否为当前会话启用日志记录到二进制日志（假设二进制日志本身已启用）。默认值为
ON。要为当前会话禁用或启用二进制日志记录，请将会话sql_log_bin变量设置为OFF或ON。将此变量设置
OFF为会话以暂时禁用二进制日志记录，同时对不希望复制到副本的源进行更改。设置此系统变量的会话值是一项受限操作。会话用户必须具有足以设置受限会话变量的权限。请参见 第 5.1.9.1 节，“系统变量权限”。
无法
sql_log_bin在事务或子查询中设置会话值。设置此变量以
OFF防止将 GTID 分配给二进制日志中的事务。如果您使用 GTID 进行复制，这意味着即使稍后再次启用二进制日志记录，从此时写入日志的 GTID 也不会考虑同时发生的任何事务，因此实际上这些事务会丢失。 -
命令行格式 --sync-binlog=#系统变量 sync_binlog范围 全局 动态的 是的 SET_VAR提示适用不 类型 整数 默认值 1最小值 0最大值 4294967295控制 MySQL 服务器将二进制日志同步到磁盘的频率。
sync_binlog=0：禁用 MySQL 服务器将二进制日志同步到磁盘。相反，MySQL 服务器依赖操作系统不时将二进制日志刷新到磁盘，就像它对任何其他文件所做的那样。此设置提供了最佳性能，但如果发生电源故障或操作系统崩溃，服务器可能已提交尚未同步到二进制日志的事务。sync_binlog=1：在提交事务之前启用二进制日志到磁盘的同步。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。在电源故障或操作系统崩溃的情况下，二进制日志中丢失的事务仅处于准备状态。这允许自动恢复例程回滚事务，从而保证不会从二进制日志中丢失事务。sync_binlog=*N*, 其中是 0 或 1 以外的值：在收集到二进制日志提交组*N*后，将二进制日志同步到磁盘 。N在电源故障或操作系统崩溃的情况下，服务器可能已经提交了尚未刷新到二进制日志的事务。由于磁盘写入次数增加，此设置可能会对性能产生负面影响。较高的值会提高性能，但会增加数据丢失的风险。
InnoDB为了在与事务一起使用 的复制设置中获得最大可能的持久性和一致性，请使用以下设置：警告
许多操作系统和一些磁盘硬件欺骗了刷新到磁盘操作。他们可能会告诉 mysqld已经发生了刷新，即使它还没有发生。在这种情况下，即使使用推荐的设置也无法保证事务的持久性，在最坏的情况下，断电可能会损坏
InnoDB数据。在 SCSI 磁盘控制器或磁盘本身中使用电池支持的磁盘缓存可加快文件刷新速度，并使操作更安全。您还可以尝试禁用硬件缓存中磁盘写入的缓存。 -
transaction_write_set_extraction命令行格式 --transaction-write-set-extraction[=value]已弃用 8.0.26 系统变量 transaction_write_set_extraction范围 全局, 会话 动态的 是的 SET_VAR提示适用不 类型 枚举 默认值 XXHASH64有效值 OFF``MURMUR32``XXHASH64此系统变量指定用于散列事务期间提取的写入的算法。默认值为
XXHASH64.OFF表示不收集写入集。transaction_write_set_extraction自 MySQL 8.0.26 起已弃用；期望它在未来的 MySQL 版本中被删除。组复制需要该
XXHASH64设置，其中从事务中提取写入的过程用于对所有组成员进行冲突检测和认证（请参阅 第 18.3.1 节，“组复制要求”）。对于具有多线程副本的复制源服务器（副本，其replica_parallel_workersorslave_parallel_workers设置为大于 0 的值），其中binlog_transaction_dependency_tracking设置为WRITESETorWRITESET_SESSION，transaction_write_set_extraction不得为OFF。而当前值binlog_transaction_dependency_trackingisWRITESET或WRITESET_SESSION，您无法更改 的值transaction_write_set_extraction。从 MySQL 8.0.14 开始，设置这个系统变量的 session 值是一个受限操作；会话用户必须具有足够的权限来设置受限会话变量（请参阅 第 5.1.9.1 节，“系统变量权限”）。
binlog_format必须设置为ROW更改 的值transaction_write_set_extraction。如果您更改该值，则新值不会对复制的事务生效，直到使用STOP REPLICA和停止并重新启动副本之后START REPLICA。粗体
