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

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

--log-bin[=base_name]

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

选项值（如果给定）是日志序列的基本名称。服务器通过向基本名称添加数字后缀来按顺序创建二进制日志文件。建议您指定一个基本名称（有关原因，请参阅 第 B.3.7 节“MySQL 中的已知问题”）。否则，MySQL 将 host_name-bin 用作基本名称。

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

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

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

如果要在服务器启动时禁用二进制日志记录但保持--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.6.12 之前，如果没有指定默认数据库（即 返回 时），此选项会导致不记录任何包含完全限定表名的语句。在 MySQL 5.6.12 及更高版本中，当没有默认数据库时，不 应用任何选项，并且始终记录此类语句。（缺陷 #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 校验和。

--max-binlog-dump-events=N

MySQL 测试套件在内部使用此选项进行复制测试和调试。

--sporadic-binlog-dump-fail

MySQL 测试套件在内部使用此选项进行复制测试和调试。

binlog_cache_size

缓存的大小，用于在事务期间保存对二进制日志的更改。如果服务器支持任何事务存储引擎并且服务器启用了二进制日志（--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（值 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在 MySQL 5.6 中，当二进制日志格式为或 时，该变量无效MIXED。（漏洞 #51291）

binlog_error_action

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

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

将此变量设置为ABORT_SERVER 使服务器在遇到此类二进制日志错误时停止记录并关闭。重新启动时，恢复会像服务器意外停止的情况一样进行（请参阅 第 17.3.2 节，“处理副本服务器的意外停止”）。这是推荐的设置，尤其是在复杂的复制环境中。

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

binlog_format

此变量设置二进制日志记录格式，可以是STATEMENT、ROW或中的任何一个MIXED。请参阅 第 17.1.2 节，“复制格式”。

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

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

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

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

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

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

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

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

更改复制源服务器上的日志记录格式不会导致副本更改其日志记录格式以匹配。如果副本启用了二进制日志记录，则在复制进行时切换复制格式可能会导致问题，并且更改会导致副本 STATEMENT在源正在使用格式日志记录时使用格式日志记录ROW或MIXED 格式日志记录。副本无法将以ROW日志记录格式 接收的二进制日志条目转换STATEMENT为在其自己的二进制日志中使用的格式，因此这种情况会导致复制失败。有关详细信息，请参阅 第 5.4.4.2 节，“设置二进制日志格式”.

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

这些影响在各个选项的描述中进行了详细讨论。

binlogging_impossible_mode

此选项已弃用；希望在未来的 MySQL 版本中将其删除。使用该 binlog_error_action 变量来控制当服务器无法写入二进制日志时发生的情况。

binlog_max_flush_queue_time

sync_binlog在继续组提交（并将日志同步到磁盘，如果大于 0） 之前，从刷新队列中读取事务的持续时间（以微秒为单位 ）。如果该值为 0（默认值），则没有超时，服务器会一直读取新事务，直到队列为空。

通常， binlog_max_flush_queue_time 可以保持设置为 0。如果服务器处理大量连接（例如，100 个或更多）和许多具有低延迟要求的短事务，将值设置为大于 0 以强制更频繁地执行可能会有用刷新到磁盘。

binlog_order_commits

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

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

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

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

binlog_cache_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.6 中，默认的基本名称是进程 ID 文件的名称，后缀为-bin. 该名称可以使用--pid-file 选项设置，默认为主机名称。二进制日志文件的默认位置是数据目录。

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 不会对存储函数的创建强制执行这些限制。此变量也适用于触发器创建。请参阅第 20.7 节，“存储程序二进制日志记录”。

log_bin_use_v1_row_events

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

MySQL 5.6 默认使用版本 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是不兼容的。

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

log_slave_updates

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

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

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

A -> B -> C

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

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 的二进制日志位置。

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

在 MySQL 5.6 中，会话的可见性 与系统变量的可见性相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（艾字节）。

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 也不会考虑同时发生的任何事务——实际上，这些事务会丢失.

从 MySQL 5.6.22 开始，全局 sql_log_bin变量是只读的，不能修改。全局范围已弃用；希望在未来的 MySQL 版本中将其删除。在 5.6.22 之前， sql_log_bin可以设置为全局或会话变量。sql_log_bin只有在启动新会话时才会检测到全局设置 。sql_log_bin全局 设置时，以前运行的任何会话都不会受到影响 。

sync_binlog

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

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