17.1.4.4 Binary Log Options and Variables

• 二进制记录使用的启动选项
• 二进制日志记录使用的系统变量
您可以使用本节中描述的mysqld选项和系统变量来影响二进制日志的操作以及控制将哪些语句写入二进制日志。有关二进制日志的更多信息，请参见第5.4.4节“二进制日志”。有关使用MySQL服务器选项和系统变量的更多信息，请参见第5.1.6节“服务器命令选项”和 第5.1.7节“服务器系统变量”。

1. 二进制记录使用的启动选项
   下表描述了用于启用和配置二进制日志的启动选项。本节稍后将讨论与二进制日志记录一起使用的系统变量。
   • --binlog-row-event-max-size=N
   属性 值
   命令行格式 --binlog-row-event-max-size=#
   类型 整数
   默认值 8192
   最低值 256
   最大值（64位平台） 18446744073709551615
   最大值（32位平台） 4294967295
   • 指定基于行的二进制日志事件的最大大小，以字节为单位。如果可能，将行分组为小于此大小的事件。该值应为256的倍数。请参见 第17.1.2节“复制格式”。
   • --log-bin[=base_name]
   属性 值
   命令行格式 --log-bin=file_name
   类型 文件名
   • 启用二进制日志记录。启用二进制日志记录后，服务器会将所有更改数据的语句记录到二进制日志中，该日志用于备份和复制。二进制日志是具有基本名称和数字扩展名的文件序列。有关二进制日志的格式和管理的信息，请参见第5.4.4节“二进制日志”。
   • 选项值（如果给出）是日志序列的基本名称。服务器通过在基本名称中添加数字后缀来依次创建二进制日志文件。建议您指定基本名称（原因请参见 第B.4.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-index[=file_name]
   属性 值
   命令行格式 --log-bin-index=file_name
   系统变量 log_bin_index

范围 全局
动态 没有
类型 文件名
• 二进制日志索引文件的名称，其中包含二进制日志文件的名称。默认情况下，它的位置和基本名称与使用–log-bin 选项加扩展名为二进制日志文件指定的值相同.index。如果未指定–log-bin，则默认的二进制日志索引文件名为 binlog.index。如果您省略文件名并且不使用来指定文件名 --log-bin，则默认二进制日志索引文件名是 host_name-bin.index，使用主机名。
• 有关二进制日志的格式和管理的信息，请参见第5.4.4节“二进制日志”。
语句选择选项。 下表中的选项影响哪些语句被写入二进制日志，并因此由复制主服务器发送到其从属服务器。从服务器还有一些选项，用于控制应执行或忽略从主服务器接收的哪些语句。有关详细信息，请参见 第17.1.4.3节“复制从站选项和变量”。
• --binlog-do-db=db_name
属性 值
命令行格式 --binlog-do-db=name
类型 串
• 此选项以类似于–replicate-do-db影响复制的方式影响二进制日志记录 。
• 此选项的效果取决于使用的是基于语句的记录格式还是基于行的日志记录格式，就像 --replicate-do-db依赖于使用的是基于语句的复制还是基于行的复制一样。您应该记住，用于记录给定语句的格式不一定与的值所表示的格式相同 binlog_format。例如，DDL语句（例如CREATE TABLE和）ALTER TABLE始终作为语句记录，而不考虑有效的记录格式，因此以下基于语句的规则–binlog-do-db 始终适用于确定是否记录该语句。
• 基于语句的日志记录。 只有那些语句被写入二进制日志，其中默认的数据库（也就是一个由选定的 USE）是 db_name。要指定多个数据库，请多次使用此选项，每个数据库一次；但是，这样做 不会导致跨数据库语句，例如在选择其他数据库（或未选择数据库）时记录跨数据库语句。 UPDATE some_db.some_table SET foo=‘bar’
• 警告
• 要指定多个数据库，您 必须使用此选项的多个实例。因为数据库名称可以包含逗号，所以如果提供逗号分隔的列表，则该列表将被视为单个数据库的名称。
• 使用基于语句的日志记录时，可能无法正常工作的示例：如果服务器启动时 --binlog-do-db=sales发出以下语句，UPDATE则不会记录该 语句 ：
• USE prices;
• UPDATE sales.january SET amount=amount+1000;
• 这种“ 仅检查默认数据库 ”行为的主要原因是，仅凭语句很难知道是否应复制它（例如，如果您使用的是多表 DELETE语句或UPDATE 跨多个表起作用的多表语句）数据库）。如果不需要，仅检查默认数据库而不是所有数据库也更快。
• 即使在设置选项时未指定给定数据库，复制给定数据库时也会发生另一种不言而喻的情况。如果服务器启动时–binlog-do-db=sales，UPDATE即使prices设置时未包含以下语句，也会记录以下 语句–binlog-do-db：
• USE sales;
• UPDATE prices.discounts SET percentage = percentage + 10;
• 因为sales是UPDATE发出该语句时的默认数据库，所以UPDATE会记录该数据库。
• 基于行的日志记录。 记录仅限于数据库 db_name。仅db_name记录对属于的表的更改；默认数据库对此没有影响。假设服务器从启动， --binlog-do-db=sales并且基于行的日志记录生效，然后执行以下语句：
• 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 SET col1 = 10, db2.table2 SET col2 = 20;
• 如果使用的是基于语句的日志记录，则两个表的更新都将写入二进制日志。但是，当使用基于行的格式时，仅table1记录对的更改；否则，将记录更改 。 table2在另一个数据库中，因此不会被更改UPDATE。现在，假设已使用USE db1 一条USE db4语句代替该语句：
• USE db4;
• UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
• 在这种情况下，UPDATE 使用基于语句的日志记录时，不会将该语句写入二进制日志。但是，在使用基于行的日志记录时，将记录对的更改table1，而不记录对的更改，table2换句话说，仅–binlog-do-db记录对名为的数据库中表的更改 ，并且默认数据库的选择对此行为没有影响。
• --binlog-ignore-db=db_name
属性 值
命令行格式 --binlog-ignore-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 为了二进制日志记录而忽略的数据库。
• 要指定多个要忽略的数据库，请多次使用此选项，每个数据库一次。因为数据库名称可以包含逗号，所以如果提供逗号分隔的列表，则该列表将被视为单个数据库的名称。
• 如果您正在使用跨数据库更新，并且您不想记录这些更新，则不应使用此选项。
校验和选项。 MySQL支持读写二进制日志校验和。使用此处列出的两个选项可以启用这些功能：
• --binlog-checksum={NONE|CRC32}
属性 值
命令行格式 --binlog-checksum=type
类型 串
默认值 CRC32
有效值 NONE
CRC32
• 启用此选项会使主服务器为写入二进制日志的事件写入校验和。设置为NONE禁用，或者设置为 用于生成校验和的算法的名称；目前仅支持CRC32校验和。
要控制从属设备（从中继日志中）读取校验和，请使用该 --slave-sql-verify-checksum 选项。
测试和调试选项。 以下二进制日志选项用于复制测试和调试。它们不适合在正常操作中使用。
• --max-binlog-dump-events=N
属性 值
命令行格式 --max-binlog-dump-events=#
类型 整数
默认值 0
• MySQL测试套件在内部使用此选项进行复制测试和调试。
• --sporadic-binlog-dump-fail
属性 值
命令行格式 --sporadic-binlog-dump-fail[={OFF|ON}]
类型 布尔型
默认值 OFF
• MySQL测试套件在内部使用此选项进行复制测试和调试。
2. 二进制日志记录使用的系统变量
下表描述了用于控制二进制日志记录的系统变量。可以在服务器启动时设置它们，其中一些可以在运行时使用进行更改 SET。本节前面列出了用于控制二进制日志记录的服务器选项。
• binlog_cache_size
属性 值
命令行格式 --binlog-cache-size=#
系统变量 binlog_cache_size

范围 全局
动态 是
类型 整数
默认值 32768
最低值 4096
最大值（64位平台） 18446744073709551615
最大值（32位平台） 4294967295
• 在事务期间，用于保存对二进制日志的更改的缓存的大小。如果服务器支持任何事务存储引擎，并且服务器启用了二进制日志（–log-bin选项），则为每个客户端分配一个二进制日志缓存。如果您经常使用大型事务，则可以增加此缓存的大小以获得更好的性能。在 Binlog_cache_use与 Binlog_cache_disk_use 状态变量可以用于调整该变量的大小是有用的。请参见第5.4.4节“二进制日志”。
• binlog_cache_size设置仅事务高速缓存的大小；语句缓存的大小由 binlog_stmt_cache_size 系统变量控制。
• binlog_checksum
属性 值
命令行格式 --binlog-checksum=name
系统变量 binlog_checksum

范围 全局
动态 是
类型 串
默认值 CRC32
有效值 NONE
CRC32
• 启用后，此变量使主服务器在二进制日志中为每个事件写入一个校验和。 binlog_checksum支持值 NONE（禁用）和 CRC32。默认值为 CRC32。
• 当binlog_checksum被禁用（值 NONE），服务器验证它是只写写和检查每个事件的事件长度（而不是校验）完整的事件二进制日志。
• 更改此变量的值会导致二进制日志被轮换。校验和总是写入整个二进制日志文件，而不是仅写入其中一部分。
• 将主服务器上的此变量设置为从服务器无法识别的值会导致从服务器将其自身的binlog_checksum值设置 为 NONE，并由于错误而停止复制。（缺陷号＃13553750，错误号＃61096）如果考虑到与较早的从站的向后兼容性，则可能需要将该值显式设置为NONE。
• binlog_direct_non_transactional_updates
属性 值
命令行格式 --binlog-direct-non-transactional-updates[={OFF|ON}]
系统变量 binlog_direct_non_transactional_updates

范围 全局会议
动态 是
类型 布尔型
默认值 OFF
• 由于并发问题，当事务同时包含对事务表和非事务表的更新时，从站可能会变得不一致。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且使用基于行的格式复制给定的语句时，此变量无效 。
• 重要
• 在启用此变量之前，必须确保事务表和非事务表之间没有依赖关系。这种依赖的一个例子就是声明INSERT INTO myisam_table SELECT * FROM innodb_table。否则，这样的陈述很可能导致从机偏离主机。
• 在MySQL 5.6中，当二进制日志格式为ROW或 时，此变量无效MIXED。错误＃51291）
• binlog_error_action
属性 值
命令行格式 --binlog-error-action[=value]
介绍了 5.6.22
系统变量 binlog_error_action

范围 全局
动态 是
类型 列举
默认值 IGNORE_ERROR
有效值 IGNORE_ERROR
ABORT_SERVER
• 控制当服务器遇到诸如无法写入，刷新或同步二进制日志之类的错误时发生的情况，该错误可能导致主服务器的二进制日志变得不一致，并且复制从服务器失去同步。
• 在MySQL 5.6中，此变量默认为 IGNORE_ERROR。如果服务器遇到此类错误，它将继续进行中的事务，记录该错误然后停止记录，并继续执行更新。要恢复二进制记录，log_bin必须再次启用二进制记录 ，这需要重新启动服务器。此设置提供了与旧版本MySQL的向后兼容性。
• 将此变量设置为ABORT_SERVER 使服务器在遇到二进制日志中的此类错误时就停止日志记录并关闭。重新启动后，恢复将继续进行，就像服务器意外中止一样（请参见第17.3.2节“处理复制从属的意外中止 ”）。这是建议的设置，尤其是在复杂的复制环境中。
• 在以前的版本中，此变量名为 binlogging_impossible_mode。
• binlog_format
属性 值
命令行格式 --binlog-format=format
系统变量 binlog_format

范围 全局会议
动态 是
类型 列举
默认值（> = 5.6.10-ndb-7.3.1） MIXED
默认值 STATEMENT
有效值 ROW
STATEMENT
MIXED
• 此变量设置二进制日志格式，并且可以是任何一个STATEMENT，ROW或MIXED。请参见 第17.1.2节“复制格式”。
• binlog_format 可以在启动时或运行时进行设置，除了在某些情况下，无法在运行时更改此变量或导致复制失败（如后面所述）。
• 在MySQL 5.6中，默认格式为 STATEMENT。 例外：在MySQL NDB Cluster 7.3和更高版本中，默认值为MIXED; NDB群集不支持基于语句的复制。
• 设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。请参见 第5.1.8.1节“系统变量特权”。
• 控制何时对该变量进行更改以及该效果持续多长时间的规则与其他MySQL服务器系统变量相同。有关更多信息，请参见第13.7.4.1节“变量分配的SET语法”。
• 当MIXED指定，基于语句的复制时，除了仅基于行的复制是保证导致正确的结果的情况。例如，当语句包含用户定义的函数（UDF）或该UUID() 函数时，就会发生这种情况。
• 有关设置每种二进制日志记录格式时如何处理存储程序（存储过程和函数，触发器和事件）的详细信息，请参见 第20.7节“存储程序二进制日志记录”。
• 当您无法在运行时切换复制格式时，会有一些例外情况：
o 从存储的函数或触发器中。
o 会话当前处于基于行的复制模式并且具有打开的临时表。
o 从交易内部。
在这种情况下尝试切换格式会导致错误。
更改复制主服务器上的日志记录格式不会导致复制从属服务器更改其日志记录格式以匹配。如果复制从属服务器启用了二进制日志记录，则在复制进行过程中切换复制格式可能会导致问题，并且更改会导致从属服务器在使用 STATEMENT主服务器时使用 格式日志记录ROW或MIXED格式日志记录。复制从设备无法将以ROW 日志记录格式接收的二进制日志条目STATEMENT转换为在其自己的二进制日志中使用的格式，因此这种情况可能导致复制失败。有关更多信息，请参见 第5.4.4.2节“设置二进制日志格式”。
二进制日志格式会影响以下服务器选项的行为：
o --replicate-do-db
o --replicate-ignore-db
o --binlog-do-db
o --binlog-ignore-db
这些效果将在各个选项的说明中详细讨论。
• binlogging_impossible_mode
属性 值
命令行格式 --binlogging-impossible-mode[=value]
介绍了 5.6.20
不推荐使用 5.6.22
系统变量 binlogging_impossible_mode

范围 全局会议
动态 是
类型 列举
默认值 IGNORE_ERROR
有效值 IGNORE_ERROR
ABORT_SERVER
• 该选项已被弃用，并将在以后的MySQL版本中删除。使用重命名 binlog_error_action来控制服务器无法写入二进制日志时发生的情况。
• binlog_max_flush_queue_time
属性 值
命令行格式 --binlog-max-flush-queue-time=#
系统变量 binlog_max_flush_queue_time

范围 全局
动态 是
类型 整数
默认值 0
最低值 0
最大值 100000
• 在继续进行组提交之前（如果sync_binlog大于0 ，则将日志同步到磁盘），要保持从刷新队列中读取事务的时间（以毫秒为单位 ）。如果值为0（默认值），则没有超时，并且服务器将继续读取新事务，直到队列为空。
• 通常， binlog_max_flush_queue_time 可以保持设置为0。如果服务器处理大量连接（例如100个或更多），并且许多低延迟要求的短事务，则将值设置为大于0以强制更频繁地使用可能会很有用。刷新到磁盘。
• binlog_order_commits
属性 值
命令行格式 --binlog-order-commits[={OFF|ON}]
系统变量 binlog_order_commits

范围 全局
动态 是
类型 布尔型
默认值 ON
• 在复制主数据库上启用此变量（默认设置）后，发给存储引擎的事务提交指令将在单个线程上序列化，因此事务始终以与写入二进制日志相同的顺序提交。禁用此变量将允许使用多个线程发出事务提交指令。与二进制日志组提交结合使用，这可以防止单个事务的提交率成为吞吐量的瓶颈，因此可能会提高性能。
• 当所有涉及的存储引擎已确认准备提交事务时，将事务写入二进制日志。然后，二进制日志组提交逻辑将在二进制日志写操作完成后提交一组事务。什么时候 binlog_order_commits禁用此选项，因为此过程使用了多个线程，所以提交组中的事务可能以与二进制日志中的顺序不同的顺序提交。（来自单个客户端的事务始终按时间顺序提交。）在许多情况下，这无关紧要，因为在单独的事务中执行的操作应产生一致的结果，如果不是这样，则应改用单个事务。
• binlog_row_image
属性 值
命令行格式 --binlog-row-image=image_type
系统变量 binlog_row_image

范围 全局会议
动态 是
类型 列举
默认值 full
有效值 full （记录所有列）
minimal （仅记录更改的列以及标识行所需的列）
noblob （记录所有列，但不需要的BLOB和TEXT列除外）
• 对于MySQL基于行的复制，此变量确定如何将行图像写入二进制日志。
• 在MySQL基于行的复制中，每个行更改事件均包含两个图像：一个“ before ”图像，在搜索要更新的行时其列与之匹配；一个“ after ”图像包含更改。通常，MySQL会记录前后映像的完整行（即所有列）。但是，并不一定要在两个映像中都包括每一列，并且通过记录仅实际需要的那些列，我们通常可以节省磁盘，内存和网络使用量。
• 注意
• 删除行时，仅记录前映像，因为没有更改的值可在删除后传播。插入行时，由于没有现有行要匹配，因此仅记录后映像。仅当更新一行时，才需要前后图像，并且都将其写入二进制日志。
• 对于前一个映像，仅需要记录唯一标识行所需的最小列集。如果包含行的表具有主键，则仅将一个或多个主键列写入二进制日志。否则，如果表具有一个唯一键，其所有列均为NOT NULL，则仅需要记录唯一键中的列。（如果表既没有主键又没有任何NULL列的唯一键 ，那么所有列都必须在前映像中使用并记录。）在后映像中，仅需要记录实际已更改的列。
• 您可以使用binlog_row_image系统变量使服务器记录完整或最少的行。该变量实际上采用三个可能值之一，如以下列表所示：
o full：记录前映像和后映像中的所有列。
o minimal：仅记录前映像中标识要更改的行所需的那些列；仅记录后映像中由SQL语句指定值或由自动增量生成的值的那些列。
o noblob：记录所有列（与相同 full），除了 BLOB和 TEXT不需要标识行或未更改的列。
注意
NDB群集不支持该变量。设置它对NDB表的日志记录没有影响 。（错误＃16316828）
默认值为full。
使用minimal或时 noblob，如果且仅当源表和目标表都满足以下条件时，才能确保删除和更新对于给定表正确运行：
o 所有列都必须以相同顺序出现。每列必须使用与另一张表中相同的数据类型。
o 这些表必须具有相同的主键定义。
（换句话说，这些表必须相同，但可能不属于表主键的索引除外）。
如果不满足这些条件，则目标表中的主键列值可能证明不足以为删除或更新提供唯一匹配。在这种情况下，不会发出警告或错误；主机和从机无声地分开，从而破坏了一致性。
当二进制日志记录格式为时，设置此变量无效STATEMENT。当 binlog_format为时 MIXED，的设置 binlog_row_image将应用于使用基于行的格式记录的更改，但是此设置对记录为语句的更改无效。
binlog_row_image在全局或会话级别进行 设置不会导致隐式提交。这意味着可以在进行交易时更改此变量，而不会影响交易。
• binlog_rows_query_log_events
属性 值
命令行格式 --binlog-rows-query-log-events[={OFF|ON}]
系统变量 binlog_rows_query_log_events

范围 全局会议
动态 是
类型 布尔型
默认值 OFF
• 此系统变量仅影响基于行的日志记录。启用后，它将导致服务器将诸如行查询日志事件之类的信息日志事件写入其二进制日志中。此信息可用于调试和相关目的，例如，当无法从行更新中重建原始查询时，获取原始查询。
• 这些信息事件通常被读取二进制日志的MySQL程序忽略，因此从备份复制或还原时不会引起任何问题。要查看它们，请通过–verbose两次使用mysqlbinlog的选项as -vv或来增加详细级别 --verbose --verbose。
• binlog_stmt_cache_size
属性 值
命令行格式 --binlog-stmt-cache-size=#
系统变量 binlog_stmt_cache_size

范围 全局
动态 是
类型 整数
默认值 32768
最低值 4096
最大值（64位平台） 18446744073709551615
最大值（32位平台） 4294967295
• 此变量确定二进制日志的高速缓存大小，以保存事务期间发出的非事务性语句。如果服务器支持任何事务性存储引擎，并且服务器启用了二进制日志（–log-bin 选项），则为每个客户端分配单独的二进制日志事务和语句缓存。如果您在事务期间经常使用大型非事务性语句，则可以增加此缓存的大小以获得更好的性能。在 Binlog_stmt_cache_use与 Binlog_stmt_cache_disk_use 状态变量可以用于调整该变量的大小是有用的。请参见第5.4.4节“二进制日志”。
• 该binlog_cache_size 系统变量设置为事务高速缓存的大小。
• expire_logs_days
属性 值
命令行格式 --expire-logs-days=#
系统变量 expire_logs_days

范围 全局
动态 是
类型 整数
默认值 0
最低值 0
最大值 99
• 自动二进制日志文件删除的天数。默认值为0，表示“ 不自动删除。”可能会在启动时以及清除二进制日志时进行删除。如第5.4节“ MySQL服务器日志”中所述，发生日志刷新。
• 要手动删除二进制日志文件，请使用以下 PURGE BINARY LOGS语句。请参见第13.4.1.1节“ PURGE BINARY LOGS语句”。
• log_bin
属性 值
系统变量 log_bin

范围 全局
动态 没有
类型 布尔型
• 是否启用了二进制日志。如果使用该 --log-bin选项，则此变量的值为ON; 否则是OFF。此变量仅报告二进制日志记录的状态（启用或禁用）；它实际上不报告设置的值 --log-bin。
• 请参见第5.4.4节“二进制日志”。
• log_bin_basename
属性 值
系统变量 log_bin_basename

范围 全局
动态 没有
类型 文件名
• 保留二进制日志文件的基本名称和路径，可以使用–log-bin server选项设置。在MySQL 5.6中，默认的基本名称是带有后缀的进程ID文件的名称 -bin。可以使用该 --pid-file选项设置该名称，并且默认为主机的名称。二进制日志文件的默认位置是数据目录。
• log_bin_index
属性 值
命令行格式 --log-bin-index=file_name
系统变量 log_bin_index

范围 全局
动态 没有
类型 文件名
• 保留二进制日志索引文件的基本名称和路径，可以使用–log-bin-indexserver选项设置 。
• log_bin_trust_function_creators
属性 值
命令行格式 --log-bin-trust-function-creators[={OFF|ON}]
系统变量 log_bin_trust_function_creators

范围 全局
动态 是
类型 布尔型
默认值 OFF
• 启用二进制日志记录时，此变量适用。它控制着是否可以信任存储函数创建者，而不创建那些导致不安全事件写入二进制日志的存储函数。如果设置为0（默认值），用户不允许创建或更改存储功能，除非他们有SUPER 特权，除了CREATE ROUTINE或ALTER ROUTINE特权。设置为0也强制执行的功能必须与被宣布为限制 DETERMINISTIC特性，或与 READS SQL DATA或NO SQL特性。如果变量设置为1，MySQL不会在创建存储函数时强制执行这些限制。此变量也适用于触发器创建。请参见第20.7节“存储的程序二进制日志记录”。
• log_bin_use_v1_row_events
属性 值
命令行格式 --log-bin-use-v1-row-events[={OFF|ON}]
系统变量 log_bin_use_v1_row_events

范围 全局
动态 没有
类型 布尔型
默认值 OFF
• 是否正在使用版本2二进制日志记录。如果此变量为0（默认为禁用），则使用版本2二进制日志事件。如果此变量为1（启用），则服务器使用版本1日志记录事件（先前版本中使用的唯一版本的二进制日志事件）写入二进制日志，从而生成可由较旧的从属读取的二进制日志。
• MySQL 5.6默认使用版本2二进制日志行事件。但是，MySQL 5.6.6之前的MySQL Server版本无法读取第2版事件。启用将 log_bin_use_v1_row_events 导致mysqld使用版本1日志事件写入二进制日志。
• 该变量在运行时为只读。要在版本1和版本2二进制事件二进制日志记录之间切换，必须log_bin_use_v1_row_events 在服务器启动时进行设置 。
• 除了执行NDB群集复制的升级外， log_bin_use_v1_row_events 在设置复制冲突检测和解决方案（ NDB$EPOCH_TRANS()用作冲突检测功能）时（将需要版本2二进制日志行事件）主要是要关注的。因此，此变量 --ndb-log-transaction-id与之不兼容。
• 注意
• MySQL NDB Cluster 7.3和更高版本默认使用版本2二进制日志行事件。在计划升级或降级以及使用NDB群集复制的设置时，您应该记住这一点。
• 有关更多信息，请参见 第18.6.11节“ NDB群集复制冲突解决”。
• log_slave_updates
属性 值
命令行格式 --log-slave-updates[={OFF|ON}]
系统变量 log_slave_updates

范围 全局
动态 没有
类型 布尔型
默认值 OFF
• 从服务器从主服务器收到的更新是否应记录到从服务器自己的二进制日志中。
• 通常，从服务器不会将从主服务器收到的任何更新记录到自己的二进制日志中。启用此变量将导致从属服务器将其SQL线程执行的更新写入其自己的二进制日志。为了使该选项生效，从站也必须–log-bin以启用二进制日志记录的选项启动。请参见 第17.1.4节“复制和二进制日志记录选项和变量”。如果启用log_slave_updates该–log-bin选项，但未同时使用该选项启动服务器， 则会发出警告 。
• log_slave_updates要链接复制服务器时启用。例如，您可能要使用以下安排来设置复制服务器：
• A -> B -> C
• 在这里，A充当从属主机B，并B充当从属主机C。为了使其正常工作，B必须既是主机 又是从机。你必须同时启动 A，并B与 --log-bin以启用二进制日志，并B与 log_slave_updates启用，以便从收到的更新A通过登录B到它的二进制日志。
• master_verify_checksum
属性 值
命令行格式 --master-verify-checksum[={OFF|ON}]
系统变量 master_verify_checksum

范围 全局
动态 是
类型 布尔型
默认值 OFF
• 启用此变量将使主服务器通过检查校验和来验证从二进制日志读取的事件，并在不匹配的情况下因错误而停止。 master_verify_checksum默认情况下处于禁用状态；在这种情况下，主服务器使用二进制日志中的事件长度来验证事件，以便仅从二进制日志中读取完整的事件。
• max_binlog_cache_size
属性 值
命令行格式 --max-binlog-cache-size=#
系统变量 max_binlog_cache_size

范围 全局
动态 是
类型 整数
默认值 18446744073709551615
最低值 4096
最大值 18446744073709551615
• 如果事务需要的内存字节数超过此数量，则服务器将生成多语句事务，而该语句需要的存储错误数超过“ max_binlog_cache_size”字节。最小值为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
属性 值
命令行格式 --max-binlog-size=#
系统变量 max_binlog_size

范围 全局
动态 是
类型 整数
默认值 1073741824
最低值 4096
最大值 1073741824
• 如果对二进制日志的写入导致当前日志文件的大小超过此变量的值，则服务器将旋转二进制日志（关闭当前文件并打开下一个日志）。最小值为4096字节。最大值和默认值为1GB。
• 事务以一个块的形式写入二进制日志，因此永远不会在多个二进制日志之间进行拆分。因此，如果您的交易量很大，您可能会看到二进制日志文件大于 max_binlog_size。
• 如果max_relay_log_size为0，则值也 max_binlog_size适用于中继日志。
• max_binlog_stmt_cache_size
属性 值
命令行格式 --max-binlog-stmt-cache-size=#
系统变量 max_binlog_stmt_cache_size

范围 全局
动态 是
类型 整数
默认值 18446744073709547520
最低值 4096
最大值 18446744073709547520
• 如果事务中的非事务性语句需要的内存量超过此字节数，则服务器将生成错误。最小值为4096。在32位平台上，最大值和默认值为4GB；在64位平台上，最大值和默认值为16EB（艾字节）。
• max_binlog_stmt_cache_size设置仅用于语句缓存的大小；事务缓存的上限仅由 max_binlog_cache_size 系统变量控制。
• sql_log_bin
属性 值
系统变量 sql_log_bin

范围 届会
动态 是
类型 布尔型
默认值 ON
• 此变量控制是否为当前会话启用到二进制日志的日志记录（假设二进制日志本身已启用）。默认值为 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全局设置时，以前运行的任何会话均不会受到影响 。
• 警告
• sql_log_bin在全局范围内 使用不正确 意味着在一个正在运行的会话中进行的任何更改仍将记录到二进制日志中并因此被复制。sql_log_bin 在全局范围内使用时要格外小心，因为上述情况可能导致意外结果，包括复制失败。
• sync_binlog
属性 值
命令行格式 --sync-binlog=#
系统变量 sync_binlog

范围 全局
动态 是
类型 整数
默认值 0
最低值 0
最大值 4294967295
• 控制MySQL服务器将二进制日志同步到磁盘的频率。
o sync_binlog=0：禁用MySQL服务器将二进制日志同步到磁盘的功能。取而代之的是，MySQL服务器依靠操作系统不时地将二进制日志刷新到磁盘上，就像处理其他任何文件一样。此设置提供最佳性能，但是在电源故障或操作系统崩溃的情况下，服务器可能提交了尚未同步到二进制日志的事务。
o sync_binlog=1：启用在提交事务之前将二进制日志同步到磁盘。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。如果出现电源故障或操作系统崩溃，二进制日志中缺少的事务将仅处于准备状态。这允许自动恢复例程回滚事务，从而保证二进制日志中不会丢失任何事务。
o sync_binlog=N，其中N的值不是0或1：是N二进制日志提交组已收集之后，二进制日志将同步到磁盘 。在电源故障或操作系统崩溃的情况下，服务器可能提交了尚未刷新到二进制日志的事务。由于磁盘写入次数的增加，此设置可能会对性能产生负面影响。较高的值可以提高性能，但会增加数据丢失的风险。
为了在InnoDB与事务一起使用的复制设置中获得最大的持久性和一致性，请使用以下设置：
o sync_binlog=1。
o innodb_flush_log_at_trx_commit=1。
警告
许多操作系统和某些磁盘硬件使“刷新磁盘”操作变得愚蠢。他们可能告诉 mysqld刷新已经发生，即使没有发生。在这种情况下，即使使用建议的设置也无法保证事务的持久性，并且在最坏的情况下，停电可能会破坏InnoDB数据。在SCSI磁盘控制器或磁盘本身中使用电池供电的磁盘缓存可以加快文件刷新的速度，并使操作更安全。您也可以尝试禁用硬件高速缓存中磁盘写入的高速缓存。