16.1.6.4 二进制日志记录选项和变量

您可以使用本节中介绍的mysqld选项和系统变量来影响二进制日志的操作以及控制将哪些语句写入二进制日志。有关二进制日志的其他信息,请参见第 5.4.4 节“二进制日志”。有关使用 MySQL 服务器选项和系统变量的其他信息,请参见第 5.1.6 节“服务器命令选项”第 5.1.7 节“服务器系统变量”

二进制记录使用的启动选项

下 table 描述了用于启用和配置二进制日志的启动选项。本节稍后将讨论与二进制日志记录一起使用的系统变量。

PropertyValue
Command-Line Format--binlog-row-event-max-size=#
TypeInteger
Default Value8192
Minimum Value256
最大值(64 位平台)18446744073709551615
最大值(32 位平台)4294967295

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

PropertyValue
Command-Line Format--log-bin=file_name
TypeFile name

启用二进制日志记录。启用二进制日志记录后,服务器会将所有更改数据的语句记录到二进制日志中,该日志用于备份和复制。二进制日志是具有基本名称和数字 extensions 的文件序列。有关二进制日志的格式和 Management 的信息,请参见第 5.4.4 节“二进制日志”

如果为--log-bin选项提供值,则该值将用作日志序列的基本名称。服务器通过在基本名称中添加数字后缀来依次创建二进制日志文件。在 MySQL 5.7 中,基本名称使用主机名默认为host_name-bin。建议您指定基本名称,以便您可以 continue 使用相同的二进制日志文件名,而不管对默认名称的更改如何。

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

设置此选项会使log_bin系统变量设置为ON(或1),而不是基本名称。二进制日志文件的基本名称和任何指定的路径都可以用作log_bin_basename系统变量。

如果指定--log-bin选项而未同时指定server_id系统变量,则不允许启动服务器。 (缺陷#11763963,错误#56739)

在服务器上使用 GTID 时,如果在异常关闭后重新启动服务器时未启用二进制日志记录,则某些 GTID 可能会丢失,从而导致复制失败。在正常关闭状态下,当前二进制日志文件中的 GTID 集将保存在mysql.gtid_executedtable 中。在未发生异常关闭(未发生这种情况)之后,在恢复过程中,只要仍启用了二进制日志记录,GTID 就会从二进制日志文件添加到 table 中。如果在重新启动服务器时禁用了二进制日志记录,则服务器将无法访问二进制日志文件以恢复 GTID,因此无法启动复制。正常关闭后,可以安全地禁用二进制日志记录。

PropertyValue
Command-Line Format--log-bin-index=file_name
System Variablelog_bin_index
ScopeGlobal
DynamicNo
TypeFile name

二进制日志索引文件的名称,其中包含二进制日志文件的名称。默认情况下,它的位置和基本名称与使用--log-bin选项以及 extensions.index为二进制日志文件指定的值相同。如果未指定--log-bin,则默认的二进制日志索引文件名是binlog.index。如果省略文件名并且不使用--log-bin指定一个,则默认二进制日志索引文件名是host_name-bin.index,使用主机名。

有关二进制日志的格式和 Management 的信息,请参见第 5.4.4 节“二进制日志”

语句选择选项. 下 table 中的选项影响将哪些语句写入二进制日志,然后由复制源服务器发送到其副本。副本服务器还有一些选项,用于控制应执行或忽略从源接收的哪些语句。有关详细信息,请参见第 16.1.6.3 节“ Replica 服务器选项和变量”

PropertyValue
Command-Line Format--binlog-do-db=name
TypeString

此选项以类似于--replicate-do-db影响复制的方式影响二进制日志记录。

此选项的效果取决于是否使用基于语句的记录格式或基于行的日志记录格式,就像--replicate-do-db的效果取决于是否使用基于语句的复制或基于行的复制一样。您应该记住,用于记录给定语句的格式不一定与binlog_format值指示的格式相同。例如,诸如CREATE TABLEALTER TABLE之类的 DDL 语句始终作为语句记录,而不考虑有效的记录格式,因此,针对--binlog-do-db的以下基于语句的规则始终适用于确定是否记录该语句。

基于语句的日志记录. 仅将那些语句写入二进制日志,其中默认数据库(即USE选择的数据库)是* db_name 。要指定多个数据库,请多次使用此选项,每个数据库一次;但是,这样做不会*导致在选择其他数据库(或未选择数据库)时记录跨数据库语句(例如UPDATE some_db.some_table SET foo='bar')。

Warning

要指定多个数据库,您必须使用此选项的多个实例。因为数据库名称可以包含逗号,所以如果提供逗号分隔的列 table,则该列 table 将被视为单个数据库的名称。

关于使用基于语句的日志记录时,可能无法正常工作的示例:如果服务器以--binlog-do-db=sales启动,并且发出以下语句,则UPDATE语句为记录:

USE prices;
UPDATE sales.january SET amount=amount+1000;

这种“仅检查默认数据库”行为的主要原因是,仅凭语句很难知道是否应该复制它(例如,如果您使用的是多 tableDELETE语句或多 tableUPDATE语句来执行操作跨多个数据库)。如果不需要,则仅检查默认数据库而不是所有数据库的速度也更快。

即使在设置选项时未指定给定数据库,复制给定数据库时也会发生另一种不言而喻的情况。如果服务器以--binlog-do-db=sales启动,即使设置--binlog-do-db时不包括prices,也会记录以下UPDATE语句:

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

由于sales是发出UPDATE语句时的默认数据库,因此会记录UPDATE

基于行的日志记录. 日志记录仅限于数据库* db_name 。仅记录对属于 db_name *的 table 的更改;默认数据库对此没有影响。假设服务器以--binlog-do-db=sales启动,并且基于行的日志记录生效,然后执行以下语句:

USE prices;
UPDATE sales.february SET amount=amount+100;

根据UPDATE语句记录对sales数据库中februarytable 的更改;无论是否发出USE语句,都会发生这种情况。但是,当使用基于行的日志记录格式和--binlog-do-db=sales时,不会记录以下UPDATE所做的更改:

USE prices;
UPDATE prices.march SET amount=amount-25;

即使USE prices语句更改为USE salesUPDATE语句的效果仍然不会写入二进制日志。

--binlog-do-db处理基于语句的日志记录与基于行的日志记录相比,另一个重要区别在于引用多个数据库的语句。假设服务器以--binlog-do-db=db1启动,并执行以下语句:

USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

如果使用的是基于语句的日志记录,则两个 table 的更新都将写入二进制日志。但是,使用基于行的格式时,仅记录对table1的更改; table2位于另一个数据库中,因此UPDATE不会更改它。现在假设使用USE db4语句代替USE db1语句:

USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;

在这种情况下,使用基于语句的日志记录时不会将UPDATE语句写入二进制日志。但是,在使用基于行的日志记录时,将记录对table1的更改,但不会记录对table2的更改-换句话说,仅记录对由--binlog-do-db命名的数据库中的 table 的更改,并且默认数据库的选择对此没有影响。行为。

PropertyValue
Command-Line Format--binlog-ignore-db=name
TypeString

此选项以类似于--replicate-ignore-db影响复制的方式影响二进制日志记录。

此选项的效果取决于是否使用基于语句的记录格式或基于行的日志记录格式,就像--replicate-ignore-db的效果取决于是否使用基于语句的复制或基于行的复制一样。您应该记住,用于记录给定语句的格式不一定与binlog_format值指示的格式相同。例如,诸如CREATE TABLEALTER TABLE之类的 DDL 语句始终作为语句记录,而不考虑有效的记录格式,因此,针对--binlog-ignore-db的以下基于语句的规则始终适用于确定该语句是否被记录。

基于语句的日志记录. 告诉服务器不要记录默认数据库(即USE选择的数据库)为* db_name *的任何语句。

在 MySQL 5.7.2 之前,如果未指定默认数据库(即SELECT DATABASE()返回NULL),则此选项导致包含标准 table 名的所有语句均不记录。在 MySQL 5.7.2 和更高版本中,如果没有默认数据库,则不会应用--binlog-ignore-db选项,并且始终记录此类语句。 (缺陷#11829838,缺陷#60188)

基于行的格式. 告诉服务器不要将对数据库中任何 table 的更新记录在日志中db_name *。当前数据库无效。

当使用基于语句的日志记录时,以下示例无法正常工作。假设服务器以--binlog-ignore-db=sales启动,并且您发出以下语句:

USE prices;
UPDATE sales.january SET amount=amount+1000;

在这种情况下会记录UPDATE语句*,因为--binlog-ignore-db仅适用于默认数据库(由USE语句确定)。由于sales数据库是在语句中显式指定的,因此该语句尚未过滤。但是,在使用基于行的日志记录时,不会将UPDATE语句的效果写入二进制日志,这意味着不会记录对sales.januarytable 的任何更改。在这种情况下,出于二进制日志记录的目的,--binlog-ignore-db=sales导致对sales数据库的源副本中的 table 所做的“所有”更改被忽略。

要指定多个要忽略的数据库,请多次使用此选项,每个数据库一次。因为数据库名称可以包含逗号,所以如果提供逗号分隔的列 table,则该列 table 将被视为单个数据库的名称。

如果您正在使用跨数据库更新,并且不想记录这些更新,则不应使用此选项。

校验和选项. MySQL 支持读写二进制日志校验和。使用此处列出的两个选项可以启用这些功能:

PropertyValue
Command-Line Format--binlog-checksum=type
TypeString
Default ValueCRC32
Valid ValuesNONE

CRC32

启用此选项会使源为写入二进制日志的事件写入校验和。设置为NONE即可禁用,或设置为用于生成校验和的算法名称;当前仅支持 CRC32 校验和,默认为 CRC32.您不能在事务中更改此选项的设置。

要控制副本(从中继日志中)读取校验和,请使用--slave-sql-verify-checksum选项。

测试和调试选项. 以下二进制日志选项用于复制测试和调试。它们不适合在正常操作中使用。

PropertyValue
Command-Line Format--max-binlog-dump-events=#
TypeInteger
Default Value0

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

PropertyValue
Command-Line Format--sporadic-binlog-dump-fail[={OFF|ON}]
TypeBoolean
Default ValueOFF

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

与二进制日志记录一起使用的系统变量

下 table 描述了用于控制二进制日志记录的系统变量。可以在服务器启动时设置它们,其中一些可以在运行时使用SET进行更改。本节前面列出了用于控制二进制日志记录的服务器选项。

PropertyValue
Command-Line Format--binlog-cache-size=#
System Variablebinlog_cache_size
ScopeGlobal
DynamicYes
TypeInteger
Default Value32768
Minimum Value4096
最大值(64 位平台)18446744073709551615
最大值(32 位平台)4294967295

在事务期间用于保存二进制日志更改的缓存大小。如果服务器支持任何事务存储引擎,并且服务器启用了二进制日志(--log-bin选项),则为每个 Client 端分配一个二进制日志缓存。如果您经常使用大型事务,则可以增加缓存大小以获得更好的性能。 Binlog_cache_useBinlog_cache_disk_use状态变量可用于调整此变量的大小。参见第 5.4.4 节“二进制日志”

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

PropertyValue
Command-Line Format--binlog-checksum=name
System Variablebinlog_checksum
ScopeGlobal
DynamicYes
TypeString
Default ValueCRC32
Valid ValuesNONE

CRC32

启用后,此变量使源将二进制日志中每个事件的校验和写入。 binlog_checksum支持值NONE(已禁用)和CRC32。默认值为CRC32。您不能在事务中更改binlog_checksum的值。

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

更改此变量的值会导致二进制日志被轮换。校验和总是写入整个二进制日志文件,而不是仅写入其中一部分。

将源上的此变量设置为副本无法识别的值会导致副本将其自己的binlog_checksum值设置为NONE,并因错误而停止复制。 (缺陷号#13553750,错误号#61096)如果考虑到与较早副本的向后兼容性,则可能需要将该值显式设置为NONE

PropertyValue
Command-Line Format--binlog-direct-non-transactional-updates[={OFF|ON}]
System Variablebinlog_direct_non_transactional_updates
ScopeGlobal, Session
DynamicYes
TypeBoolean
Default ValueOFF

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

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

  • binlog_direct_non_transactional_updates仅适用于使用基于语句的二进制日志记录格式复制的语句*;也就是说,它仅在binlog_format的值为STATEMENTbinlog_formatMIXED并且使用基于语句的格式复制给定的语句时才有效。当二进制日志格式为ROWbinlog_format设置为MIXED且使用基于行的格式复制给定的语句时,此变量无效。

Important

在启用此变量之前,必须确保事务 table 和非事务 table 之间没有依赖关系。此类依赖的一个示例是语句INSERT INTO myisam_table SELECT * FROM innodb_table。否则,这样的语句很可能导致副本与源不同。

当二进制日志格式为ROWMIXED时,此变量无效。

PropertyValue
Command-Line Format--binlog-error-action[=value]
System Variablebinlog_error_action
ScopeGlobal
DynamicYes
TypeEnumeration
Default ValueABORT_SERVER
Valid ValuesIGNORE_ERROR

ABORT_SERVER

控制当服务器遇到诸如无法写入,刷新或同步二进制日志之类的错误时发生的情况,该错误可能导致源的二进制日志变得不一致并且副本失去同步。

在 MySQL 5.7.7 和更高版本中,此变量默认为ABORT_SERVER,这使得服务器在遇到二进制日志中的此类错误时会暂停日志记录并关闭服务器。重新启动后,恢复将 continue 进行,就像服务器意外停止一样(请参见第 16.3.2 节“处理副本意外停止”)。

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

在以前的版本中,此变量名为binlogging_impossible_mode

PropertyValue
Command-Line Format--binlog-format=format
System Variablebinlog_format
ScopeGlobal, Session
DynamicYes
TypeEnumeration
Default ValueROW
Valid ValuesROW

STATEMENT
MIXED

此变量设置二进制日志记录格式,并且可以是STATEMENTROWMIXED之一。参见第 16.2.1 节“复制格式”

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

在 MySQL 5.7.7 之前,默认格式为STATEMENT。在 MySQL 5.7.7 和更高版本中,默认值为ROW。 * Exception *:在 NDB 群集中,默认值为MIXED; NDB 群集不支持基于语句的复制。

设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。参见第 5.1.8.1 节“系统变量特权”

该变量的更改何时生效以及效果持续多久的规则与其他 MySQL 服务器系统变量相同。有关更多信息,请参见第 13.7.4.1 节“变量分配的 SET 语法”

当指定MIXED时,将使用基于语句的复制,除非保证仅基于行的复制会导致正确的结果。例如,当语句包含用户定义的函数(UDF)或UUID()函数时,就会发生这种情况。

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

当您无法在运行时切换复制格式时,会有一些 exceptions:

  • 从存储的函数或触发器中。

    • 如果会话当前处于基于行的复制模式,并且具有打开的临时 table。

    • 从 Transaction 内部。

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

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

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

这些效果将在各个选项的说明中详细讨论。

PropertyValue
Command-Line Format--binlog-group-commit-sync-delay=#
System Variablebinlog_group_commit_sync_delay
ScopeGlobal
DynamicYes
TypeInteger
Default Value0
Minimum Value0
Maximum Value1000000

控制二进制日志提交在将二进制日志文件同步到磁盘之前 await 多少微秒。默认情况下,binlog_group_commit_sync_delay设置为 0,table 示没有延迟。将binlog_group_commit_sync_delay设置为微秒的延迟可使更多事务同时同步到磁盘,从而减少了提交一组事务的总时间,因为较大的组每个组需要的时间单位更少。

设置sync_binlog=0sync_binlog=1时,在同步之前(或在sync_binlog=0的情况下,在 continue 之前)将binlog_group_commit_sync_delay指定的延迟应用于每个二进制日志提交组。当sync_binlog的值* n 大于 1 时,将在每个 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会增加服务器上事务的延迟,这可能会影响 Client 端应用程序。同样,在高度并行的工作负载上,延迟可能会增加争用并因此降低吞吐量。通常,设置延迟的好处胜于缺点,但应始终执行调整以确定最佳设置。

PropertyValue
Command-Line Format--binlog-group-commit-sync-no-delay-count=#
System Variablebinlog_group_commit_sync_no_delay_count
ScopeGlobal
DynamicYes
TypeInteger
Default Value0
Minimum Value0
Maximum Value1000000

中止由binlog_group_commit_sync_delay指定的当前延迟之前 await 的最大事务数。如果binlog_group_commit_sync_delay设置为 0,则此选项无效。

PropertyValue
Command-Line Format--binlog-max-flush-queue-time=#
DeprecatedYes
System Variablebinlog_max_flush_queue_time
ScopeGlobal
DynamicYes
TypeInteger
Default Value0
Minimum Value0
Maximum Value100000

以前,这控制了在 continue 进行组提交之前 continue 从刷新队列读取事务的时间(以微秒为单位)。在 MySQL 5.7 中,此变量不再有效。

binlog_max_flush_queue_time自 MySQL 5.7.9 起不推荐使用,并标记为最终在将来的 MySQL 版本中删除。

PropertyValue
Command-Line Format--binlog-order-commits[={OFF|ON}]
System Variablebinlog_order_commits
ScopeGlobal
DynamicYes
TypeBoolean
Default ValueON

在复制源服务器上启用此变量(默认设置)后,发布到存储引擎的事务提交指令将在单个线程上序列化,因此事务始终以与写入二进制日志相同的 Sequences 提交。禁用此变量允许使用多个线程发出事务提交指令。与二进制日志组提交结合使用,这可以防止单个事务的提交率成为吞吐量的瓶颈,因此可能会提高性能。

当所有涉及的存储引擎已确认准备提交事务时,将事务写入二进制日志。然后,二进制日志组提交逻辑将在二进制日志写操作完成后提交一组事务。禁用binlog_order_commits时,因为此过程使用了多个线程,所以提交组中的事务可能以与二进制日志中的 Sequences 不同的 Sequences 提交。 (来自单个 Client 端的事务始终按时间 Sequences 提交.)在许多情况下,这无关紧要,因为在单独事务中执行的操作应产生一致的结果,如果不是这样,则应改用单个事务。

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

PropertyValue
Command-Line Format--binlog-row-image=image_type
System Variablebinlog_row_image
ScopeGlobal, Session
DynamicYes
TypeEnumeration
Default Valuefull
Valid Valuesfull(记录所有列)

minimal(仅记录更改的列以及标识行所需的列)
noblob(记录所有列,但不需要的 BLOB 和 TEXT 列除外)

对于 MySQL 基于行的复制,此变量确定如何将行图像写入二进制日志。

在 MySQL 基于行的复制中,每个行更改事件都包含两个图像,一个“ before”图像,在搜索要更新的行时其列将匹配,而“ after”图像则包含更改。通常,MySQL 会记录前映像和后映像的完整行(即所有列)。但是,并不一定要在两个映像中都包括每一列,并且通过记录仅实际需要的那些列,我们通常可以节省磁盘,内存和网络使用量。

Note

删除行时,仅记录前映像,因为在删除后没有要传播的更改值。插入行时,由于没有现有行要匹配,因此仅记录后映像。仅当更新一行时,才需要前后图像,并且都将其写入二进制日志。

对于前一个映像,仅需要记录唯一标识行所需的最小列集。如果包含行的 table 具有主键,则仅将一个或多个主键列写入二进制日志。否则,如果 table 具有唯一键,其所有列均为NOT NULL,则仅需要记录唯一键中的列。 (如果 table 既没有主键又没有唯一键,而没有任何NULL列,那么所有列都必须在前映像中使用并进行记录.)在后映像中,仅需要记录实际上已更改的列。

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

  • full:记录之前图像和之后图像中的所有列。

    • minimal:仅记录前映像中标识要更改的行所需的列;仅记录后映像中由 SQL 语句指定值或由自动增量生成的值的那些列。

    • noblob:记录所有列(与full相同),除了不需要BLOBTEXT列以标识行或未更改之外。

Note

NDB 群集不支持该变量。设置它对NDBtable 的日志记录没有影响。

默认值为full

当使用minimalnoblob时,如果且仅当源 table 和目标 table 都满足以下条件时,才能确保删除和更新对于给定 table 正确运行:

  • 所有列都必须以相同 Sequences 出现。每列必须使用与另一张 table 中相同的数据类型。

    • 这些 table 必须具有相同的主键定义。

(换句话说,这些 table 必须相同,但可能不属于 table 主键的索引除外)。

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

当二进制日志记录格式为STATEMENT时,设置此变量无效。当binlog_formatMIXED时,binlog_row_image的设置将应用于使用基于行的格式记录的更改,但是此设置对记录为语句的更改没有影响。

在全局或会话级别设置binlog_row_image不会导致隐式提交;这意味着可以在进行 Transaction 时更改此变量,而不会影响 Transaction。

  • binlog_rows_query_log_events

PropertyValue
Command-Line Format--binlog-rows-query-log-events[={OFF|ON}]
System Variablebinlog_rows_query_log_events
ScopeGlobal, Session
DynamicYes
TypeBoolean
Default ValueOFF

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

这些信息事件通常被读取二进制日志的 MySQL 程序忽略,因此从备份复制或还原时不会引起任何问题。要查看它们,请通过两次使用 mysqlbinlog 的--verbose选项(即-vv--verbose --verbose)来提高详细程度。

PropertyValue
Command-Line Format--binlog-stmt-cache-size=#
System Variablebinlog_stmt_cache_size
ScopeGlobal
DynamicYes
TypeInteger
Default Value32768
Minimum Value4096
最大值(64 位平台)18446744073709551615
最大值(32 位平台)4294967295

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

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

PropertyValue
Command-Line Format--binlog-transaction-dependency-tracking=value
Introduced5.7.22
System Variablebinlog_transaction_dependency_tracking
ScopeGlobal
DynamicYes
TypeEnumeration
Default ValueCOMMIT_ORDER
Valid ValuesCOMMIT_ORDER

WRITESET
WRITESET_SESSION

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

  • COMMIT_ORDER:从源的提交时间戳生成依赖关系信息。这是默认值。此模式也可用于任何没有写集的事务,即使此变量的值为WRITESETWRITESET_SESSION;没有主键的事务更新 table 和具有外键约束的事务更新 table 也是如此。

    • WRITESET:依赖项信息是从源的写集生成的,写不同 Tuples 的任何事务都可以并行化。

    • WRITESET_SESSION:依赖关系信息是从源的写集生成的,但是不能重新排序来自同一会话的两个更新。

WRITESETWRITESET_SESSION模式不提供比在COMMIT_ORDER模式下返回的事务依赖更新的任何事务依赖。

如果transaction_write_set_extractionOFF,则此变量的值不能设置为COMMIT_ORDER以外的任何值。您还应该注意,如果binlog_transaction_dependency_tracking的当前值为WRITESETWRITESET_SESSION,则不能更改transaction_write_set_extraction的值。

要保留的行哈希数和检查是否已更改给定行的最新事务数由值binlog_transaction_dependency_history_size决定。

PropertyValue
Command-Line Format--binlog-transaction-dependency-history-size=#
Introduced5.7.22
System Variablebinlog_transaction_dependency_history_size
ScopeGlobal
DynamicYes
TypeInteger
Default Value25000
Minimum Value1
Maximum Value1000000

设置行哈希值的上限,该哈希值保留在内存中,用于查找最后修改给定行的事务。一旦达到此哈希数,便清除历史记录。

PropertyValue
Command-Line Format--expire-logs-days=#
System Variableexpire_logs_days
ScopeGlobal
DynamicYes
TypeInteger
Default Value0
Minimum Value0
Maximum Value99

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

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

PropertyValue
System Variablelog_bin
ScopeGlobal
DynamicNo
TypeBoolean

是否启用了二进制日志。如果使用--log-bin选项,则此变量的值为ON;否则为OFF。该变量仅报告二进制日志记录的状态(启用或禁用)。它实际上不会报告设置--log-bin的值。

See 第 5.4.4 节“二进制日志”.

PropertyValue
System Variablelog_bin_basename
ScopeGlobal
DynamicNo
TypeFile name

保留二进制日志文件的基本名称和路径,可以使用--log-bin服务器选项设置。在 MySQL 5.7 中,默认的基本名称是带有后缀-bin的主机名。默认位置是数据目录。

PropertyValue
Command-Line Format--log-bin-index=file_name
System Variablelog_bin_index
ScopeGlobal
DynamicNo
TypeFile name

保留二进制日志索引文件的基本名称和路径,可以使用--log-bin-index服务器选项设置。

PropertyValue
Command-Line Format--log-bin-trust-function-creators[={OFF|ON}]
System Variablelog_bin_trust_function_creators
ScopeGlobal
DynamicYes
TypeBoolean
Default ValueOFF

启用二进制日志记录时,此变量适用。它控制着是否可以信任存储函数的创建者,而不创建那些导致不安全事件写入二进制日志的存储函数。如果设置为 0(默认值),则除非用户具有CREATE ROUTINEALTER ROUTINE特权,否则除非他们具有SUPER特权,否则不允许用户创建或更改存储的功能。设置为 0 还强制执行以下限制:必须使用DETERMINISTICFeature 或READS SQL DATANO SQLFeature 声明函数。如果变量设置为 1,MySQL 不会在创建存储函数时强制执行这些限制。此变量也适用于触发器创建。参见第 23.7 节“存储的程序二进制日志”

PropertyValue
Command-Line Format--log-bin-use-v1-row-events[={OFF|ON}]
System Variablelog_bin_use_v1_row_events
ScopeGlobal
DynamicNo
TypeBoolean
Default ValueOFF

是否正在使用版本 2 二进制日志记录。如果此变量为 0(默认为禁用),则使用版本 2 二进制日志事件。如果此变量为 1(启用),则服务器将使用版本 1 日志记录事件(先前版本中使用的唯一版本的二进制日志事件)写入二进制日志,从而生成可由较早的副本读取的二进制日志。

MySQL 5.7 默认使用版本 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 群集复制升级外,使用NDB$EPOCH_TRANS()作为冲突检测功能设置复制冲突检测和解决方案时,主要需要log_bin_use_v1_row_events,这需要版本 2 二进制日志行事件。因此,此变量和--ndb-log-transaction-id不兼容。

Note

MySQL NDB Cluster 7.5 默认使用版本 2 二进制日志行事件。在计划升级或降级以及使用 NDB 群集复制的设置时,您应该记住这一点。

有关更多信息,请参见第 21.6.11 节“ NDB 群集复制冲突解决”

PropertyValue
Command-Line Format--log-builtin-as-identified-by-password[={OFF|ON}]
System Variablelog_builtin_as_identified_by_password
ScopeGlobal
DynamicYes
TypeBoolean
Default ValueOFF

此变量影响用户 Management 语句的二进制日志记录。启用后,该变量具有以下作用:

  • 涉及内置身份验证插件的CREATE USER语句的二进制日志记录将重写该语句以包含IDENTIFIED BY PASSWORD子句。

启用此变量可确保与 5.6 和 5.7.6 之前的副本的跨版本复制以及在二进制日志中需要此语法的应用程序具有更好的兼容性。

PropertyValue
Command-Line Format--log-slave-updates[={OFF|ON}]
System Variablelog_slave_updates
ScopeGlobal
DynamicNo
TypeBoolean
Default ValueOFF

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

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

要链接复制服务器时启用log_slave_updates。例如,您可能想要使用以下安排来设置复制服务器:

A -> B -> C

在此,A用作副本B的源,而B用作副本C的源。为此,B必须既是源*也是副本。必须将AB都以--log-bin开头来启用二进制日志记录,并且必须将B启用log_slave_updates才能开始,以便从A接收到的更新由B记录到其二进制日志中。

PropertyValue
Command-Line Format--log-statements-unsafe-for-binlog[={OFF|ON}]
Introduced5.7.11
System Variablelog_statements_unsafe_for_binlog
ScopeGlobal
DynamicYes
TypeBoolean
Default ValueON

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

PropertyValue
Command-Line Format--master-verify-checksum[={OFF|ON}]
System Variablemaster_verify_checksum
ScopeGlobal
DynamicYes
TypeBoolean
Default ValueOFF

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

PropertyValue
Command-Line Format--max-binlog-cache-size=#
System Variablemax_binlog_cache_size
ScopeGlobal
DynamicYes
TypeInteger
Default Value18446744073709551615
Minimum Value4096
Maximum Value18446744073709551615

如果事务需要的存储字节数超过了此字节数,服务器将生成多语句事务,而该语句需要的存储错误数超过“ max_binlog_cache_size”个字节。最小值为 4096.最大可能值为 16EB(艾字节)。推荐的最大值为 4GB。这是由于 MySQL 当前无法使用大于 4GB 的二进制日志位置。

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

max_binlog_cache_size会话的可见性与binlog_cache_size系统变量的可见性匹配;换句话说,更改其值仅影响更改该值后启动的新会话。

PropertyValue
Command-Line Format--max-binlog-size=#
System Variablemax_binlog_size
ScopeGlobal
DynamicYes
TypeInteger
Default Value1073741824
Minimum Value4096
Maximum Value1073741824

如果写入二进制日志导致当前日志文件大小超过此变量的值,则服务器将旋转二进制日志(关闭当前文件并打开下一个日志)。最小值为 4096 字节。最大值和默认值为 1GB。

事务以一个块的形式写入二进制日志,因此永远不会在多个二进制日志之间进行拆分。因此,如果您的 Transaction 量很大,则可能会看到二进制日志文件大于max_binlog_size

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

PropertyValue
Command-Line Format--max-binlog-stmt-cache-size=#
System Variablemax_binlog_stmt_cache_size
ScopeGlobal
DynamicYes
TypeInteger
Default Value18446744073709547520
Minimum Value4096
Maximum Value18446744073709547520

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

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

PropertyValue
System Variablesql_log_bin
ScopeSession
DynamicYes
TypeBoolean
Default ValueON

此变量控制是否为当前会话启用到二进制日志的日志记录(假设二进制日志本身已启用)。默认值为ON。要为当前会话禁用或启用二进制日志记录,请将会话sql_log_bin变量设置为OFFON

将该变量设置为OFF可以在会话中暂时禁用二进制日志记录,同时对不希望复制到副本的源进行更改。

设置此系统变量的会话值是受限制的操作。会话用户必须具有足以设置受限会话变量的特权。参见第 5.1.8.1 节“系统变量特权”

无法在事务或子查询中设置会话值sql_log_bin

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

全局sql_log_bin变量是只读的,无法修改。全局范围已被弃用,并将在将来的 MySQL 版本中删除。

PropertyValue
Command-Line Format--sync-binlog=#
System Variablesync_binlog
ScopeGlobal
DynamicYes
TypeInteger
Default Value1
Minimum Value0
Maximum Value4294967295

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

  • sync_binlog=0:禁止 MySQL 服务器将二进制日志同步到磁盘。取而代之的是,MySQL 服务器依靠 os 不时地将二进制日志刷新到磁盘上,就像处理其他任何文件一样。此设置可提供最佳性能,但是在电源故障或 os 崩溃的情况下,服务器可能提交了尚未同步到二进制日志的事务。

    • sync_binlog=1:在提交事务之前启用二进制日志到磁盘的同步。这是最安全的设置,但由于磁盘写入次数增加,可能会对性能产生负面影响。如果出现电源故障或 os 崩溃,二进制日志中缺少的事务将仅处于准备状态。这允许自动恢复例程回滚事务,从而确保二进制日志中不会丢失任何事务。

    • sync_binlog=N,其中* N *是 0 或 1 以外的值。在已收集N个二进制日志提交组之后,二进制日志将同步到磁盘。在电源故障或 os 崩溃的情况下,服务器可能提交了尚未刷新到二进制日志的事务。由于磁盘写入次数的增加,此设置可能会对性能产生负面影响。较高的值可以提高性能,但会增加数据丢失的风险。

为了使InnoDB与事务一起使用的复制设置具有最大的持久性和一致性,请使用以下设置:

Caution

许多 os 和某些磁盘硬件使“刷新磁盘”操作变得愚蠢。他们可能会告诉mysqld即使没有发生刷新。在这种情况下,即使使用建议的设置也无法保证事务的持久性,并且在最坏的情况下,停电可能会损坏InnoDB数据。在 SCSI 磁盘控制器或磁盘本身中使用 Batteries 供电的磁盘缓存可以加快文件刷新的速度,并使操作更安全。您也可以尝试禁用硬件高速缓存中磁盘写入的高速缓存。

PropertyValue
Command-Line Format--transaction-write-set-extraction[=value]
System Variabletransaction_write_set_extraction
ScopeGlobal, Session
DynamicYes
TypeEnumeration
Default ValueOFF
有效值(≥5.7.14)OFF

MURMUR32
XXHASH64
有效值(≤5.7.13)OFF
MURMUR32

定义用于生成散列的算法,该散列标识与事务关联的写入。如果使用组复制,则哈希值用于分布式冲突检测和处理。在运行组复制的 64 位系统上,建议将其设置为XXHASH64,以避免不必要的哈希冲突,该冲突会导致认证失败和用户事务回滚。参见第 17.7.1 节“组复制要求”

Note

binlog_transaction_dependency_tracking设置为WRITESETWRITESET_SESSION时,不能更改此变量的值。

必须将binlog_format设置为ROW才能更改此变量的值。