--binlog-row-event-max-size=N

指定基于行的二进制日志事件的最大大小（以字节为单位）。如果可能，行被分组为小于此大小的事件。该值应该是 256 的倍数。默认值为 8192。请参阅第 16.2.1 节，“复制格式”。

--log-bin[=base_name]

启用二进制日志记录。启用二进制日志记录后，服务器会将所有更改数据的语句记录到二进制日志中，用于备份和复制。二进制日志是一系列具有基本名称和数字扩展名的文件。有关二进制日志的格式和管理的信息，请参阅第 5.4.4 节，“二进制日志”。

如果您为该--log-bin 选项提供一个值，该值将用作日志序列的基本名称。服务器通过向基本名称添加数字后缀来按顺序创建二进制日志文件。在 MySQL 5.7 中，基本名称默认为 host_name-bin，使用主机名。建议您指定一个基本名称，以便您可以继续使用相同的二进制日志文件名称，而不管默认名称是否发生变化。

二进制日志文件的默认位置是数据目录。您可以使用该--log-bin选项指定替代位置，方法是将前导绝对​​路径名添加到基本名称以指定不同的目录。当服务器从二进制日志索引文件中读取一个条目时，它会跟踪已使用的二进制日志文件，它会检查该条目是否包含相对路径。如果是，则路径的相对部分将替换为使用 --log-bin选项。二进制日志索引文件中记录的绝对路径保持不变；在这种情况下，必须手动编辑索引文件以启用一个或多个新路径。（在旧版本的 MySQL 中，每当重新定位二进制日志或中继日志文件时都需要手动干预。）（错误 #11745230，错误 #12133）

设置此选项会导致 log_bin系统变量被设置为ON（或1），而不是基本名称。二进制日志文件基本名称和任何指定路径都可用作 log_bin_basename系统变量。

如果您指定--log-bin选项而未同时指定 server_id系统变量，则不允许服务器启动。（错误#11763963，错误#56739）

服务器在使用GTID时，如果异常关机后重启服务器时没有开启binary logging，很可能会丢失部分GTID，导致复制失败。在正常关机中，当前二进制日志文件中的一组 GTID 保存在 mysql.gtid_executed桌子。在未发生这种情况的异常关闭之后，如果二进制日志记录仍处于启用状态，则在恢复过程中，GTID 会从二进制日志文件添加到表中。如果为服务器重启禁用了二进制日志记录，则服务器无法访问二进制日志文件来恢复 GTID，因此无法启动复制。正常关闭后可以安全地禁用二进制日志记录。

如果要在服务器启动时禁用二进制日志记录但保持--log-bin设置不变，则可以在启动时指定 --skip-log-bin 或 --disable-log-bin 选项。在选项之后指定 --log-bin选项，使其优先。禁用二进制日志记录时， log_bin系统变量设置为 OFF。

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

在 MySQL 5.7.2 之前，如果没有指定默认数据库（即 返回 时），此选项会导致不记录任何包含完全限定表名的语句。在 MySQL 5.7.2 及更高版本中，当没有默认数据库时，不 应用任何选项，并且始终记录此类语句。（缺陷 #11829838，缺陷 #60188） SELECT DATABASE()NULL--binlog-ignore-db

基于行的格式。  告诉服务器不要记录对数据库中任何表的更新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选项），则会为每个客户端分配一个二进制日志缓存。如果您经常使用大型事务，则可以增加此缓存大小以获得更好的性能。和 Binlog_cache_use状态 Binlog_cache_disk_use 变量可用于调整此变量的大小。请参阅第 5.4.4 节，“二进制日志”。

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

binlog_checksum

启用后，此变量会导致源为二进制日志中的每个事件写入校验和。 binlog_checksum支持值 NONE(disabled) 和 CRC32. 默认值为 CRC32。您不能更改 binlog_checksum事务内的值。

禁用时binlog_checksum（值 NONE），服务器通过写入和检查每个事件的事件长度（而不是校验和）来验证它是否只将完整的事件写入二进制日志。

更改此变量的值会导致二进制日志轮转；校验和总是写入整个二进制日志文件，而绝不会只写入其中的一部分。

将源上的此变量设置为副本无法识别的值会导致副本将其自己的 binlog_checksum值设置为 NONE，并因错误而停止复制。（Bug #13553750，Bug #61096）如果担心与旧副本的向后兼容性，您可能希望将该值明确设置为NONE.

binlog_direct_non_transactional_updates

由于并发问题，当事务包含对事务和非事务表的更新时，副本可能会变得不一致。MySQL 试图通过将非事务性语句写入事务缓存来保持这些语句之间的因果关系，事务缓存在提交时被刷新。但是，当代表事务对非事务表所做的修改立即对其他连接可见时，就会出现问题，因为这些更改可能不会立即写入二进制日志。

该 binlog_direct_non_transactional_updates 变量为该问题提供了一种可能的解决方法。默认情况下，此变量是禁用的。启用 binlog_direct_non_transactional_updates 会导致对非事务表的更新直接写入二进制日志，而不是事务缓存。

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

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

binlog_error_action

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

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

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

在以前的版本中，此变量被命名为 binlogging_impossible_mode.

binlog_format

该系统变量设置二进制日志记录格式，可以是STATEMENT、 ROW或中的任何一个MIXED。请参阅 第 16.2.1 节，“复制格式”。该设置在服务器上启用二进制日志记录时生效，即 log_bin系统变量设置为时的情况ON。在 MySQL 5.7 中，默认情况下不启用二进制日志记录，您可以使用该 --log-bin选项启用它。

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

在 MySQL 5.7.7 之前，默认格式是 STATEMENT. 在 MySQL 5.7.7 及更高版本中，默认值为ROW. 例外：在 NDB Cluster 中，默认为MIXED；NDB Cluster 不支持基于语句的复制。

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

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

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

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

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

在这些情况下尝试切换格式会导致错误。

更改复制源服务器上的日志记录格式不会导致副本更改其日志记录格式以匹配。如果副本启用了二进制日志记录，则在复制进行时切换复制格式可能会导致问题，并且更改会导致副本 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 可以增加任何具有（或在故障转移后可能具有）副本的服务器上的并行提交事务的数量，因此可以增加副本上的并行执行。要从这种效果中获益，副本服务器必须已 设置，并且当 还设置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

以前，这控制了以微秒为单位的时间，以便在继续进行组提交之前继续从刷新队列中读取事务。在 MySQL 5.7 中，这个变量不再有任何作用。

binlog_max_flush_queue_time从 MySQL 5.7.9 开始弃用，并标记为在未来的 MySQL 版本中最终删除。

binlog_order_commits

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

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

如果要确保源和多线程副本上的事务历史记录保持相同， slave_preserve_commit_order=1 请在副本上设置。

binlog_row_image

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

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

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

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

默认值为full。

使用minimalor noblob时，当且仅当源表和目标表都满足以下条件时，删除和更新才能保证对给定表正常工作：

（换句话说，这些表必须与不属于表主键的索引可能的例外相同。）

如果不满足这些条件，则可能证明目标表中的主键列值不足以为删除或更新提供唯一匹配。在这种情况下，不会发出警告或错误；源和副本默默地发散，从而破坏了一致性。

当二进制日志记录格式为STATEMENT. 当 binlog_format是 时MIXED， 的设置 binlog_row_image应用于使用基于行的格式记录的更改，但此设置对记录为语句的更改没有影响。

在全局或会话级别上设置binlog_row_image不会导致隐式提交；这意味着该变量可以在交易进行时更改，而不会影响交易。

binlog_rows_query_log_events

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

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

binlog_stmt_cache_size

此变量确定二进制日志的缓存大小，以保存在事务期间发出的非事务性语句。

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

如果服务器支持任何事务存储引擎并且服务器启用了二进制日志（--log-bin 选项），则为每个客户端分配单独的二进制日志事务和语句缓存。如果您经常在事务期间使用大型非事务性语句，则可以增加此缓存大小以获得更好的性能。和 Binlog_stmt_cache_use状态 Binlog_stmt_cache_disk_use 变量可用于调整此变量的大小。请参阅第 5.4.4 节，“二进制日志”。

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

binlog_transaction_dependency_tracking

源使用的依赖信息源来确定副本的多线程应用程序可以并行执行哪些事务。此变量可以采用以下列表中描述的三个值之一：

在WRITESETor WRITESET_SESSION模式下，事务可以乱序提交，除非你也设置 slave_preserve_commit_order=1.

对于某些事务，WRITESET和 WRITESET_SESSION模式无法改善本应在 COMMIT_ORDER模式 中返回的结果。对于具有空或部分写集的事务、更新没有主键或唯一键的表的事务以及更新外键关系中的父表的事务都是这种情况。在这些情况下，源使用COMMIT_ORDER模式来生成依赖信息。

此变量的值不能设置为COMMIT_ORDERif transaction_write_set_extraction is以外的任何值OFF。您还应注意，如果 的当前值为 或 ，则 不能 transaction_write_set_extraction 更改 的值 。如果更改该值，则新值不会对副本生效，直到副本已停止并使用 and 语句重新启动后。 binlog_transaction_dependency_trackingWRITESETWRITESET_SESSIONSTOP SLAVESTART SLAVE

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

binlog_transaction_dependency_history_size

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

expire_logs_days

自动删除二进制日志文件的天数。默认值为 0，表示“不自动删除。”可能的删除发生在启动时和刷新二进制日志时。日志刷新发生在第 5.4 节，“MySQL 服务器日志”中。

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

log_bin

是否启用二进制日志。如果 --log-bin使用该选项，则此变量的值为ON；否则就是OFF。此变量仅报告二进制日志记录的状态（启用或禁用）；它实际上并不报告 --log-bin设置的值。

请参阅第 5.4.4 节，“二进制日志”。

log_bin_basename

保存二进制日志文件的基本名称和路径，可以使用--log-bin 服务器选项进行设置。最大可变长度为 256。在 MySQL 5.7 中，默认的基本名称是带有后缀的主机名称-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 不会对存储函数的创建强制执行这些限制。此变量也适用于触发器创建。请参阅第 23.7 节，“存储程序二进制日志记录”。

log_bin_use_v1_row_events

是否正在使用版本 2 二进制日志记录。如果此变量为 0（禁用，默认值），则使用版本 2 二进制日志事件。如果此变量为 1（启用），则服务器使用版本 1 日志记录事件（以前版本中使用的二进制日志事件的唯一版本）写入二进制日志，从而生成可由旧副本读取的二进制日志。

MySQL 5.7 默认使用版本 2 二进制日志行事件。但是，MySQL 5.6.6 之前的 MySQL 服务器版本无法读取版本 2 事件。启用 log_bin_use_v1_row_events 会导致mysqld使用版本 1 日志记录事件写入二进制日志。

该变量在运行时是只读的。要在版本 1 和版本 2 二进制事件二进制日志之间切换，需要 log_bin_use_v1_row_events 在服务器启动时设置。

除了执行 NDB Cluster Replication 的升级之外，在 log_bin_use_v1_row_events 使用冲突检测功能设置复制冲突检测和解决时主要感兴趣 NDB$EPOCH_TRANS()，这需要版本 2 二进制日志行事件。因此，这个变量和 --ndb-log-transaction-id是不兼容的。

有关更多信息，请参阅 第 21.7.11 节，“NDB Cluster 复制冲突解决”。

log_builtin_as_identified_by_password

此变量影响用户管理语句的二进制日志记录。启用后，该变量具有以下作用：

启用此变量可确保更好地兼容 5.6 和 5.7.6 之前的副本的跨版本复制，以及希望在二进制日志中使用此语法的应用程序。

log_slave_updates

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

通常，副本不会将从源服务器接收到的任何更新记录到自己的二进制日志中。启用此变量会导致副本将其复制 SQL 线程执行的更新写入其自己的二进制日志。要使此选项生效，还必须使用 --log-bin启用二进制日志记录的选项启动副本。请参阅第 16.1.6 节，“复制和二进制日志记录选项和变量”。

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

A -> B -> C

在这里，A作为副本的来源B，并B 作为副本的来源C。为此，B必须既是来源 又是副本。您必须同时启动 A和Bwith --log-bin以启用二进制日志记录，并启用Bwith log_slave_updates以便从中接收的更新A记录B到其二进制日志中。

log_statements_unsafe_for_binlog

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

master_verify_checksum

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

max_binlog_cache_size

如果一个事务需要超过这个字节数的内存，服务器会生成一个Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage错误。最小值为 4096。最大可能值为 16EB（艾字节）。最大推荐值为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。

事务以一个块的形式写入二进制日志，因此它永远不会在多个二进制日志之间拆分。因此，如果您有大事务，您可能会看到大于 max_binlog_size.

如果max_relay_log_size为 0，则值也 max_binlog_size适用于中继日志。

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 系统变量控制。

sql_log_bin

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

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

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

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

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

全局sql_log_bin 变量是只读的，不能修改。全局范围已弃用；希望在未来的 MySQL 版本中将其删除。

sync_binlog

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

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

transaction_write_set_extraction

定义用于生成哈希值的算法，该哈希值标识与事务关联的写入。如果您正在使用 Group Replication，则哈希值用于分布式冲突检测和处理。在运行 Group Replication 的 64 位系统上，我们建议将此设置 XXHASH64为以避免不必要的散列冲突导致认证失败和用户事务回滚。请参阅 第 17.3.1 节，“组复制要求”。 binlog_format必须设置为ROW更改此变量的值。如果更改该值，则新值不会对副本生效，直到副本已停止并使用STOP SLAVEandSTART SLAVE语句重新启动后。