19.1.6.4 二进制日志记录选项和变量
您可以使用mysqld选项和系统变量,描述在本节中,以影响二进制日志的操作,并控制哪些语句写入到二进制日志中。关于二进制日志的更多信息,请见第7.4.4节,“The Binary Log”。关于使用MySQL服务器选项和系统变量的更多信息,请见第7.1.7节,“Server Command Options”和第7.1.8节,“Server System Variables”。
以下是启用和配置二进制日志的启动选项。用于二进制日志的系统变量将在本节后面讨论。
-
Command-Line Format --binlog-row-event-max-size=#
System Variable binlog_row_event_max_size
Scope Global Dynamic No SET_VAR
Hint AppliesNo Type Integer Default Value 8192
Minimum Value 256
Maximum Value (64-bit platforms) 18446744073709551615
Maximum Value (32-bit platforms) 4294967295
Unit bytes 当使用行基于的二进制日志时,这个设置是行基于二进制日志事件的最大大小的软限制,单位为字节。可能的地方,存储在二进制日志中的行被分组到事件中,以避免超过该设置的值。如果事件不能被分割,最大大小可以超过该值。该值必须是或被舍入到256的倍数。默认值为8192字节。
-
Command-Line Format --log-bin=file_name
Type 文件名 指定二进制日志文件的基础名称。启用二进制日志记录时,服务器将记录所有更改数据的语句到二进制日志中,该日志用于备份和复制。二进制日志是一系列文件,其中基础名称和数字后缀组成。
--log-bin
选项的值是日志序列的基础名称。服务器将根据基础名称创建二进制日志文件,并将其序列化到文件中。如果您不提供
--log-bin
选项,MySQL将使用binlog
作为默认的二进制日志文件的基础名称。为了与早期版本保持兼容,如果您使用--log-bin
选项,但没有字符串或空字符串,基础名称将默认为
,使用主机名称。host_name
-bin二进制日志文件的默认位置是数据目录。您可以使用
--log-bin
选项指定一个不同的位置,通过在基础名称前添加一个绝对路径名。服务器读取二进制日志索引文件时,它将检查索引文件中的条目是否包含相对路径。如果是,它将相对路径替换为使用--log-bin
选项指定的绝对路径。绝对路径记录在二进制日志索引文件中将保持不变;在这种情况下,索引文件必须手动编辑以启用新的路径或路径。二进制日志文件的基础名称和指定的路径可作为log_bin_basename
系统变量。在 MySQL 8.4 中,二进制日志记录默认启用,是否指定
--log-bin
选项都一样。唯一的例外是使用mysqld手动初始化数据目录时,使用--initialize
或--initialize-insecure
选项,二进制日志记录默认禁用。可以通过指定--log-bin
选项启用二进制日志记录。启用二进制日志记录时,log_bin
系统变量将设置为 ON。要禁用二进制日志记录,可以指定
--skip-log-bin
或--disable-log-bin
选项在启动时。如果指定了这两个选项,并且指定了--log-bin
选项,后指定的选项将优先。禁用二进制日志记录时,log_bin
系统变量将设置为 OFF。当服务器在 abnormal shutdown 后重新启动时,如果禁用二进制日志记录,可能会丢失一些 GTIDs,导致复制失败。在正常关闭时,当前二进制日志文件中的 GTID 集合将被保存在
mysql.gtid_executed
表中。由于 abnormal shutdown,GTIDs 将从二进制日志文件中添加到表中,假设二进制日志记录仍然启用。如果禁用二进制日志记录,服务器无法访问二进制日志文件来恢复 GTIDs,因此复制无法启动。二进制日志记录可以在正常关闭后安全禁用。The
--log-replica-updates
和--replica-preserve-commit-order
选项需要二进制日志记录。如果您禁用二进制日志记录,或者指定--log-replica-updates=OFF
和--skip-replica-preserve-commit-order
,MySQL 将自动禁用这些选项。MySQL 在指定--skip-log-bin
或--disable-log-bin
时默认禁用这些选项。如果您同时指定--log-replica-updates
、--replica-preserve-commit-order
和--skip-log-bin
或--disable-log-bin
,将发出警告或错误信息。服务器可以在启用二进制日志记录时启动,但如果您不指定服务器 ID,服务器将发出信息性消息。对于在复制拓扑结构中使用的服务器,您必须指定每个服务器的唯一非零服务器 ID。
有关二进制日志的格式和管理,请参见第7.4.4节,“The Binary Log”。
-
Command-Line Format --log-bin-index=file_name
System Variable log_bin_index
Scope Global Dynamic No SET_VAR
Hint AppliesNo Type File name 二进制日志索引文件的名称,该文件包含二进制日志文件的名称。默认情况下,它的位置和名称与使用
--log-bin
选项指定的二进制日志文件相同,后缀为.index
。如果您不指定--log-bin
,默认的二进制日志索引文件名为binlog.index
。如果您指定--log-bin
选项,但不指定字符串或空字符串,默认的二进制日志索引文件名为
,使用主机名称。host_name
-bin.index有关二进制日志的格式和管理,请参见Section 7.4.4, “The Binary Log”。
语句选择选项. 以下列表中的选项影响哪些语句被写入到二进制日志中,从而被复制源服务器发送到其副本。还有一些选项用于副本,控制从源服务器接收到的语句是否执行或忽略。详细信息,请见第19.1.6.3节,“副本服务器选项和变量”。
-
Command-Line Format --binlog-do-db=name
Type 字符串 这个选项对二进制日志的影响类似于
--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'被记录,而不同的数据库(或无数据库)被选择。Warning要指定多个数据库,您必须 使用多个实例这个选项。因为数据库名称可以包含逗号,列表被视为单个数据库的名称,如果您提供逗号分隔的列表。
一个不工作的示例是使用语句基于的日志记录:如果服务器以
--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
启动,并且基于行的日志记录在 effect 中,然后执行以下语句: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
的数据库中的表的更改被记录,而默认数据库的选择对此行为无影响。 -
Command-Line Format --binlog-ignore-db=name
Type 字符串 这个选项对二进制日志记录的影响类似于
--replicate-ignore-db
对复制的影响。这个选项的效果取决于是否使用语句日志记录或行格式记录,类似于
--replicate-ignore-db
对复制的影响。您应该记住,记录一个语句的格式可能与binlog_format
的值不同。例如,DDL语句,如CREATE TABLE
和ALTER TABLE
,总是以语句的形式记录,不管记录格式是什么,所以--binlog-ignore-db
的语句规则总是适用于确定是否记录语句。语句日志记录 告诉服务器不要记录任何语句,其中默认数据库(即
USE
选择的)是db_name
。如果没有默认数据库,无
--binlog-ignore-db
选项将被应用,语句总是被记录。 (Bug #11829838, Bug #60188)行格式 告诉服务器不要记录对
db_name
数据库中的任何表的更新。当前数据库无效。使用语句日志时,以下示例可能不会像您期望的那样工作。假设服务器启动时使用了
--binlog-ignore-db=sales
,然后您执行以下语句:USE prices; UPDATE sales.january SET amount=amount+1000;
UPDATE 语句是被记录的,因为
--binlog-ignore-db
仅适用于默认数据库(由USE
语句确定)。由于语句中明确指定了sales
数据库,因此语句未被过滤。然而,在使用行级日志记录时,UPDATE 语句的影响不被写入到二进制日志中,这意味着在这个实例中,--binlog-ignore-db=sales
将忽略源的拷贝中的所有更改,以便于二进制日志记录的目的。要指定多个数据库忽略,可以使用该选项多次,每个数据库一次。由于数据库名称可以包含逗号,因此列表将被视为单个数据库的名称,如果您提供逗号分隔的列表。
您不应该使用该选项,如果您使用跨数据库更新,并且不想这些更新被记录。
校验和选项 MySQL 支持读取和写入二进制日志校验和。这些使用以下两个选项启用:
-
--binlog-checksum={NONE|CRC32}
Command-Line Format --binlog-checksum=type
Type 字符串 Default Value CRC32
Valid Values NONE
CRC32
启用该选项将使源写入二进制日志的事件的校验和。将其设置为
NONE
以禁用,或者指定用于生成校验和的算法名称;当前,只支持 CRC32 校验和,CRC32 是默认值。您不能在事务中更改该选项的设置。
要控制复制服务器(从中继日志)读取校验和的使用--replica-sql-verify-checksum
选项。
测试和调试选项 以下二进制日志选项用于复制测试和调试。它们不适用于正常操作。
以下是控制二进制日志的系统变量列表。它们可以在服务器启动时设置,并且一些变量可以在运行时使用SET
。用于控制二进制日志的服务器选项在本节前面列出。
-
Command-Line Format --binlog-cache-size=#
System Variable binlog_cache_size
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value 32768
Minimum Value 4096
Maximum Value (64-bit platforms) 18446744073709547520
Maximum Value (32-bit platforms) 4294963200
Unit 字节 Block Size 4096
二进制日志缓存的内存缓冲区大小。
当启用二进制日志记录时(使用
log_bin
系统变量设置为 ON),为每个客户端分配二进制日志缓存。如果事务数据超过内存缓冲区,剩余数据将被存储在临时文件中。启用二进制日志加密时,内存缓冲区不加密,但用于存储二进制日志缓存的临时文件将被加密。每个事务提交后,二进制日志缓存将被重置,清除内存缓冲区,并将临时文件截断。如果您经常使用大事务,可以增加缓存大小以提高性能,减少或消除临时文件的写入。状态变量
Binlog_cache_use
和Binlog_cache_disk_use
可以有助于调整该变量的大小。请参阅Section 7.4.4, “The Binary Log”。binlog_cache_size
只设置事务缓存的大小;语句缓存的大小由binlog_stmt_cache_size
系统变量控制。 -
Command-Line Format --binlog-checksum=type
System Variable binlog_checksum
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 字符串 Default Value CRC32
Valid Values NONE
CRC32
启用时,这个变量会使源节点为每个事件在二进制日志中写入校验和。
binlog_checksum
支持值NONE
(禁用校验和)和CRC32
。默认值为CRC32
。当binlog_checksum
禁用(值为NONE
)时,服务器将验证它是否将只写入完整事件到二进制日志中,通过写入和检查每个事件的长度(而不是校验和)来实现。将这个变量在源节点设置为未识别的值将导致副本节点将其自己的
binlog_checksum
值设置为NONE
,并在错误中停止复制。如果您关心与更老的副本的向后兼容,可以将值设置为NONE
。MySQL 8.4 中的 Group Replication 支持校验和,因此组成员可能使用默认设置。
更改
binlog_checksum
的值将导致二进制日志被旋转,因为校验和必须写入整个二进制日志文件,而不能只写入部分一个。您不能在事务中更改binlog_checksum
的值。在使用
binlog_transaction_compression
系统变量启用二进制日志事务压缩时,校验和不会为每个事件在压缩事务 payload 中写入。相反,会写入 GTID 事件的校验和和压缩的Transaction_payload_event
的校验和。 -
binlog_direct_non_transactional_updates
Command-Line Format --binlog-direct-non-transactional-updates[={OFF|ON}]
System Variable binlog_direct_non_transactional_updates
Scope 全局、会话 Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value OFF
由于并发问题,副本可能在包含更新非事务表的交易中变得不一致。MySQL 尝试通过将非事务语句写入事务缓存中,并在提交时将其flush,以保持语句之间的因果关系。然而,在非事务表上执行的修改可能会立即对其他连接可见,因为这些更改可能不会立即写入到二进制日志中。
The
binlog_direct_non_transactional_updates
变量提供了一种解决方案来解决这个问题。默认情况下,这个变量是禁用的。启用binlog_direct_non_transactional_updates
将使非事务表的更新直接写入到二进制日志中,而不是写入事务缓存中。设置这个系统变量的会话值是一个受限制的操作。会话用户必须具有足够的权限来设置受限制的会话变量。请参阅第7.1.9.1节,“系统变量权限”。
binlog_direct_non_transactional_updates
只能用于使用语句基于的二进制日志格式;也就是说,它只能在binlog_format
的值为STATEMENT
或MIXED
,且在使用语句基于的格式时生效。这变量在ROW
格式或binlog_format
设置为MIXED
,且在使用行基于的格式时无效。Important在启用这个变量前,您必须确保没有非事务表和事务表之间的依赖关系;例如,语句
INSERT INTO myisam_table SELECT * FROM innodb_table
。否则,这些语句可能会导致副本与源分歧。这个变量在
ROW
或MIXED
格式时无效。 -
Command-Line Format --binlog-encryption[={OFF|ON}]
System Variable binlog_encryption
Scope Global Dynamic Yes SET_VAR
Hint AppliesNo Type Boolean Default Value OFF
启用对二进制日志文件和中继日志文件的加密。
OFF
是默认值。ON
将对二进制日志文件和中继日志文件进行加密。二进制日志不需要在服务器上启用,以便启用加密,您可以在副本上加密中继日志文件。要使用加密,您需要安装和配置密钥ring插件,以供MySQL Server的密钥ring服务使用。有关详细信息,请参阅第8.4.4节,“MySQL密钥ring”。任何支持的密钥ring插件都可以用来存储二进制日志加密密钥。当您首次启动服务器时,启用了二进制日志加密,会生成一个新的二进制日志加密密钥,然后初始化二进制日志和中继日志。这个密钥用于加密每个二进制日志文件(如果服务器启用了二进制日志记录)和中继日志文件(如果服务器启用了复制通道),并且从文件密码中生成的密钥用于加密文件中的数据。中继日志文件对所有通道进行加密,包括Group Replication applier通道和新创建的通道。二进制日志索引文件和中继日志索引文件从不加密。
如果在服务器运行时激活加密,会生成一个新的二进制日志加密密钥。唯一的例外是,如果加密在服务器上之前启用过,然后禁用了,在这种情况下,之前使用的二进制日志加密密钥将被重新使用。二进制日志文件和中继日志文件将立即旋转,新的文件和所有后续的二进制日志文件和中继日志文件的文件密码将使用这个二进制日志加密密钥加密。服务器上仍然存在的二进制日志文件和中继日志文件不自动加密,但可以删除它们如果它们不再需要。
如果您将
binlog_encryption
系统变量设置为OFF
,二进制日志文件和中继日志文件将立即旋转,并且所有后续的记录将不加密。之前加密的文件不自动解密,但服务器仍然可以读取它们。需要BINLOG_ENCRYPTION_ADMIN
特权(或弃用的SUPER
特权)来在服务器运行时激活或禁用加密。Group Replication applier通道不包括在中继日志旋转请求中,因此这些通道的加密记录不会立即开始,直到它们在正常使用中旋转。关于二进制日志文件和中继日志文件加密的更多信息,请见第19.3.2节,“ Encrypting Binary Log Files and Relay Log Files”。
-
Command-Line Format --binlog-error-action[=value]
System Variable binlog_error_action
Scope Global Dynamic Yes SET_VAR
Hint AppliesNo Type Enumeration Default Value ABORT_SERVER
Valid Values IGNORE_ERROR
ABORT_SERVER
控制服务器遇到错误,例如无法写入、刷新或同步二进制日志,这可能会导致源的二进制日志变得不一致,复制服务器失去同步。
该变量默认为
ABORT_SERVER
,在遇到二进制日志错误时将使服务器停止记录日志并关闭。重启时,恢复过程与服务器意外关闭时相同(见第19.4.2节,“Handling an Unexpected Halt of a Replica”)。当
binlog_error_action
设置为IGNORE_ERROR
时,如果服务器遇到错误,它将继续当前事务,记录错误,然后停止记录,并继续执行更新。要恢复二进制记录log_bin
必须重新启用,这需要重新启动服务器。这一设置提供了与older版本MySQL的向后兼容性。 -
Command-Line Format --binlog-expire-logs-seconds=#
System Variable binlog_expire_logs_seconds
Scope Global Dynamic Yes SET_VAR
Hint AppliesNo Type Integer Default Value 2592000
Minimum Value 0
Maximum Value 4294967295
Unit 秒 设置二进制日志过期期限(以秒为单位)。过期期限结束后,可以自动删除二进制日志文件。可能的删除操作发生在启动时和二进制日志刷新时。日志刷新见第7.4节,“MySQL Server Logs”。
默认二进制日志过期期限为2592000秒,等于30天(30*24*60*60秒)。
可以通过设置
binlog_expire_logs_auto_purge
系统变量将自动删除二进制日志文件的功能禁用。该设置优先于任何设置binlog_expire_logs_seconds
。要手动删除二进制日志文件,请使用
PURGE BINARY LOGS
语句。见第15.4.1.1节,“PURGE BINARY LOGS Statement”。 -
Command-Line Format --binlog-expire-logs-auto-purge={ON|OFF}
System Variable binlog_expire_logs_auto_purge
Scope Global Dynamic Yes SET_VAR
Hint AppliesNo Type Boolean Default Value ON
启用或禁用自动清除二进制日志文件。将该变量设置为
ON
(默认)启用自动清除;将其设置为OFF
禁用自动清除。清除间隔由binlog_expire_logs_seconds
控制。Note即使
binlog_expire_logs_auto_purge
设置为ON
,将binlog_expire_logs_seconds
设置为0
也可以停止自动清除。该变量对
PURGE BINARY LOGS
无效。 -
Command-Line Format --binlog-format=format
Deprecated 是 System Variable binlog_format
Scope 全局、会话 Dynamic 是 SET_VAR
Hint Applies否 Type 枚举 Default Value ROW
Valid Values MIXED
STATEMENT
ROW
该系统变量设置二进制日志格式,可以是
STATEMENT
、ROW
或MIXED
中的任何一个。 (见第19.2.1节,“Replication Formats”。)设置将在服务器启用二进制日志时生效,这是当log_bin
系统变量设置为ON
时。在 MySQL 8.4 中,二进制日志默认启用,并且默认使用行基于的格式。Notebinlog_format
已弃用,可能在未来的 MySQL 版本中删除。这意味着,对于其他日志格式的支持也可能在未来的版本中删除。因此,对于任何新的 MySQL 复制设置,仅使用行基于的日志。binlog_format
可以在启动或运行时设置,除非在某些情况下,无法在运行时更改该变量或导致复制失败,后续描述。默认值为
ROW
。 Exception:在 NDB 集群中,默认值为MIXED
;语句基于的复制不支持 NDB 集群。设置会话值的系统变量是受限制的操作。会话用户必须具有足够的权限来设置受限制的会话变量。见第7.1.9.1节,“System Variable Privileges”。
关于更改该变量的规则和生效时间,以及变量的持久时间,同样适用于MySQL服务器系统变量。更多信息,请见第15.7.6.1节,“SET Syntax for Variable Assignment”。
当指定
MIXED
时,使用语句级别的复制,除非只有行级别的复制才能确保结果正确。例如,这发生在语句中包含可加载函数或UUID()
函数时。关于存储程序(存储程序、函数、触发器和事件)的处理方式,见第27.7节,“Stored Program Binary Logging”。
有一些情况不能在运行时更改复制格式:
-
不能在存储函数或触发器内部更改复制格式。
-
如果会话打开了临时表,不能更改复制格式(
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
格式日志。这可能会导致复制失败。更多信息,请见第7.4.4.2节,“Setting The Binary Log Format”。日志格式影响以下服务器选项的行为:
这些效果在每个选项的描述中有详细讨论。
-
-
binlog_group_commit_sync_delay
Command-Line Format --binlog-group-commit-sync-delay=#
System Variable binlog_group_commit_sync_delay
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value 0
Minimum Value 0
Maximum Value 1000000
Unit 微秒 控制二进制日志提交等待同步二进制日志文件到磁盘的微秒数。默认情况下,
binlog_group_commit_sync_delay
设置为 0,这意味着没有延迟。将binlog_group_commit_sync_delay
设置为微秒延迟使得更多事务同步到磁盘一起,减少了事务组的总体时间,因为更大的组需要更少的时间单元。当
sync_binlog=0
或sync_binlog=1
设置时,指定的延迟将在每个二进制日志提交组之前应用(或在sync_binlog=0
中,继续执行)。当sync_binlog
设置为一个值 n 大于 1 时,延迟将在每 n 个二进制日志提交组后应用。设置
binlog_group_commit_sync_delay
可以增加任何服务器(或可能在故障转移后)中的并行提交事务的数量,从而增加复制服务器上的并行执行。为了从这个效果中受益,复制服务器必须设置replica_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
Command-Line Format --binlog-group-commit-sync-no-delay-count=#
System Variable binlog_group_commit_sync_no_delay_count
Scope Global Dynamic Yes SET_VAR
Hint AppliesNo Type Integer Default Value 0
Minimum Value 0
Maximum Value 100000
指定
binlog_group_commit_sync_delay
指定的延迟后等待的最大事务数量。如果binlog_group_commit_sync_delay
设置为0,则该选项无效。 -
Command-Line Format --binlog-max-flush-queue-time=#
Deprecated Yes System Variable binlog_max_flush_queue_time
Scope Global Dynamic Yes SET_VAR
Hint AppliesNo Type Integer Default Value 0
Minimum Value 0
Maximum Value 100000
Unit 微秒 binlog_max_flush_queue_time
已弃用,并将在未来的 MySQL 版本中删除。以前,这个系统变量控制了在flush队列中继续读取事务的时间,以便继续进行组提交。现在,它不再有任何影响。 -
Command-Line Format --binlog-order-commits[={OFF|ON}]
System Variable binlog_order_commits
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value ON
当这个变量在复制源服务器上启用(默认情况下),事务提交指令将被序列化到单个线程中,以便事务总是以相同的顺序提交。禁用这个变量允许事务提交指令使用多个线程。与二进制日志组提交结合使用,这可以防止单个事务的提交率成为瓶颈,从而提高性能。
事务将在所有参与的事务存储引擎确认事务已经准备好提交时写入到二进制日志中。然后,二进制日志组提交逻辑将提交一组事务,事务写入二进制日志后。 cuando
binlog_order_commits
被禁用,因为多个线程用于这个过程,事务在提交组中可能会以不同的顺序提交(来自单个客户端的事务总是以时间顺序提交)。在许多情况下,这不重要,因为在单个事务中执行的操作应该产生一致的结果,如果不是,那么应该使用单个事务。如果您想确保源和多线程副本上的事务历史保持一致,请在副本上设置
replica_preserve_commit_order=1
。 -
binlog_rotate_encryption_master_key_at_startup
Command-Line Format --binlog-rotate-encryption-master-key-at-startup[={OFF|ON}]
System Variable binlog_rotate_encryption_master_key_at_startup
Scope 全局 Dynamic 否 SET_VAR
Hint Applies否 Type 布尔 Default Value OFF
指定服务器启动时是否旋转二进制日志主密钥。二进制日志主密钥是用于加密二进制日志文件和中继日志文件的密钥。在服务器首次启动时,启用二进制日志加密(
binlog_encryption=ON
)时,会生成新的二进制日志加密密钥作为二进制日志主密钥。如果设置了binlog_rotate_encryption_master_key_at_startup
系统变量为ON
,每次服务器重启时,会生成新的二进制日志加密密钥作为二进制日志主密钥。如果设置了binlog_rotate_encryption_master_key_at_startup
系统变量为OFF
,默认情况下,使用现有的二进制日志主密钥。关于二进制日志加密密钥和二进制日志主密钥的更多信息,请参见第19.3.2节,“ Encrypting Binary Log Files and Relay Log Files”。 -
Command-Line Format --binlog-row-event-max-size=#
System Variable binlog_row_event_max_size
Scope Global Dynamic No SET_VAR
Hint AppliesNo Type Integer Default Value 8192
Minimum Value 256
Maximum Value (64-bit platforms) 18446744073709551615
Maximum Value (32-bit platforms) 4294967295
Unit 字节 当使用行基于的二进制日志记录时,这个设置是行基于的二进制日志事件的最大大小的软限制,单位为字节。在可能的情况下,二进制日志中存储的行将被分组到事件中,每个事件的大小不超过该设置的值。如果事件不能被分割,最大大小可能会超过。默认值为8192字节。
这个全局系统变量是只读的,不能在服务器启动时设置。因此,可以使用
PERSIST_ONLY
关键字或@@persist_only
限定符与SET
语句来修改该值。 -
Command-Line Format --binlog-row-image=image_type
System Variable binlog_row_image
Scope Global, Session Dynamic Yes SET_VAR
Hint AppliesNo Type Enumeration Default Value full
Valid Values 全
(Log all columns)最小
(Log only changed columns, and columns needed to identify rows)noblob
(Log all columns, except for unneeded BLOB and TEXT columns)在 MySQL 行级别复制中,这个变量确定如何将行图像写入二进制日志。
设置会话值的这个系统变量是一个受限的操作。会话用户必须具有足够的权限来设置受限的会话变量。请参阅第7.1.9.1节,“系统变量权限”。
在 MySQL 行级别复制中,每个行变化事件包含两个图像,一個是“before”图像,这些列将与搜索要更新的行进行匹配,另一个是“after”图像,包含更改的值。通常,MySQL 将记录完整的行(即所有列)对于两个图像。然而,我们可以通过只记录实际需要的列来节省磁盘、内存和网络使用。
Note当删除一行时,只记录“before”图像,因为没有需要传播的更改值。插入一行时,只记录“after”图像,因为没有现有行要匹配。只有在更新一行时,才需要记录两个图像,并将其写入二进制日志。
对于“before”图像,只需要记录唯一标识行的最小列集。如果表包含行的主键,那么只记录主键列或列。否则,如果表包含唯一键,其中所有列都不是空的,那么只需要记录唯一键中的列。 (如果表既没有主键也没有唯一键,其中没有空列,那么所有列都需要在“before”图像中记录,并且需要记录。) 在“after”图像中,只需要记录实际更改的列。
您可以使服务器记录完整或最小行使用
binlog_row_image
系统变量。这個变量实际上可以取三个可能的值,如下列表所示:-
全
:记录“before”图像和“after”图像中的所有列。 -
最小
:记录“before”图像中的唯一标识行所需的列,记录“after”图像中的实际更改列。 -
noblob
:记录所有列(与全
相同),除了未需要的 BLOB 和 TEXT 列。
Note这个变量不支持 NDB 集群;设置它对 NDB 表的日志记录没有影响。
默认值为
全
。使用
minimal
或noblob
时,删除和更新操作在给定的表中将正确工作,如果和仅当以下条件在源和目标表中都成立:-
所有列都必须存在且在同一顺序,每列必须使用与对应列在另一表中的同一数据类型。
-
表必须具有相同的主键定义。
(换言之,表必须是完全相同的,除了可能的索引以外,这些索引不属于表的主键。)
如果这些条件不满足,可能会导致目标表的主键值不足以提供唯一的匹配项,以便删除或更新。在这种情况下,不会出现警告或错误;源和副本默默地分歧,从而破坏一致性。
设置这个变量对在
STATEMENT
格式的二进制日志格式无效。当binlog_format
是MIXED
时,这个设置将应用于使用行格式的更改,但这个设置对使用语句格式的更改无效。设置
binlog_row_image
在全局或会话级别不会导致隐式提交;这意味着这个变量可以在事务进行时更改,而不会影响事务。 -
-
Command-Line Format --binlog-row-metadata=metadata_type
System Variable binlog_row_metadata
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 枚举 Default Value MINIMAL
Valid Values FULL
(包括所有元数据)MINIMAL
(限制包括的元数据)在使用行格式日志时,控制添加到二进制日志中的表元数据。当设置为
MINIMAL
,默认情况下,只包括与SIGNED
标志、列字符集和几何类型相关的元数据。当设置为FULL
,则包括完整的表元数据,如列名称、ENUM
或SET
字符串值、PRIMARY KEY
信息等。扩展元数据的目的是:
-
副本使用元数据来传输数据,当其表结构不同于源表结构时。
-
外部软件可以使用元数据来解码行事件并将数据存储到外部数据库中,如数据仓库。
-
-
Command-Line Format --binlog-row-value-options=#
System Variable binlog_row_value_options
Scope 全局、会话 Dynamic 是 SET_VAR
Hint Applies否 Type 设置 Default Value Valid Values PARTIAL_JSON
当设置为
PARTIAL_JSON
时,这将启用空间效率的二进制日志格式,对于修改了 JSON 文档的少部分的更新,将在二进制日志中只写入修改的部分,而不是写入整个文档(请参见JSON 部分更新)。这适用于使用UPDATE
语句修改 JSON 列的任何序列的JSON_SET()
、JSON_REPLACE()
和JSON_REMOVE()
。如果服务器无法生成部分更新,整个文档将被使用。默认值为空字符串,这将禁用该格式。要取消设置
binlog_row_value_options
并恢复写入整个 JSON 文档,请将其值设置为空字符串。设置会话变量的值是受限制的操作。会话用户必须具有足够的权限来设置受限制的会话变量。请参见第7.1.9.1节,“系统变量权限”。
binlog_row_value_options=PARTIAL_JSON
仅在启用二进制日志记录时生效,并且binlog_format
设置为ROW
或MIXED
。语句级别复制总是将只记录 JSON 文档的修改部分, REGARDLESS OF ANY VALUE SET FORbinlog_row_value_options
。为了最大限度地节省空间,请使用binlog_row_image=NOBLOB
或binlog_row_image=MINIMAL
together with this option。binlog_row_image=FULL
将保存的空间少于这两个,因为整个 JSON 文档将存储在 before-image 中,而部分更新将存储在 after-image 中。mysqlbinlog输出将包括部分 JSON 更新,以 base-64 字符串的形式编码为
BINLOG
语句。如果指定了--verbose
选项,mysqlbinlog将将部分 JSON 更新显示为可读的 JSON 使用伪 SQL 语句。MySQL 复制生成错误,如果对 JSON 文档的修改不能在复制服务器上应用。这包括无法找到路径的失败。请注意,即使有这些和其他安全检查,如果 JSON 文档在复制服务器上与源服务器上的内容不同,并对该文档进行部分更新,仍然可能生产一个有效但意外的 JSON 文档。
-
Command-Line Format --binlog-rows-query-log-events[={OFF|ON}]
System Variable binlog_rows_query_log_events
Scope 全局、会话 Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value OFF
这个系统变量只影响行基于的日志记录。当启用时,它会将信息性日志事件,如行查询日志事件,写入到二进制日志中。这类信息可以用于调试和相关目的,例如在无法从行更新中重构原始查询时获取源服务器上的原始查询。
设置这个系统变量的会话值是一个受限制的操作。会话用户必须具有设置受限制的会话变量的权限。请参阅第7.1.9.1节,“系统变量权限”。
这些信息事件通常被 MySQL 读取二进制日志的程序忽略,因此在复制或从备份中恢复时不会产生问题。要查看这些事件,请使用 mysqlbinlog 的
--verbose
选项两次,或者使用-vv
或--verbose --verbose
。 -
Command-Line Format --binlog-stmt-cache-size=#
System Variable binlog_stmt_cache_size
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value 32768
Minimum Value 4096
Maximum Value (64-bit platforms) 18446744073709547520
Maximum Value (32-bit platforms) 4294963200
Unit 字节 Block Size 4096
二进制日志中非事务语句缓存的内存缓冲区大小。
当启用二进制日志时(使用
log_bin
系统变量设置为 ON),每个客户端都将分配一个二进制日志事务和语句缓存。如果非事务语句在事务中使用的数据超过内存缓冲区的空间,超出部分将被存储在临时文件中。启用二进制日志加密时,内存缓冲区不加密,但用于存储二进制日志缓存的临时文件加密。每个事务提交后,二进制日志语句缓存将被重置,清除内存缓冲区并截断临时文件。如果您经常在事务中使用大型非事务语句,可以增加这个缓存大小以提高性能,减少或消除写入临时文件的需要。状态变量
Binlog_stmt_cache_use
和Binlog_stmt_cache_disk_use
可以用于调整这个变量的大小。请参阅第7.4.4节,“二进制日志”。系统变量
binlog_cache_size
设置了事务缓存的大小。 -
binlog_transaction_compression
Command-Line Format --binlog-transaction-compression[={OFF|ON}]
System Variable binlog_transaction_compression
Scope 全局、会话 Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value OFF
启用对事务的二进制日志文件的压缩。
OFF
是默认值。使用binlog_transaction_compression_level_zstd
系统变量来设置zstd算法的压缩级别。当启用二进制日志事务压缩时,事务负载将被压缩,然后写入二进制日志文件作为单个事件(
Transaction_payload_event
)。压缩的事务负载在被发送到副本、其他组复制组成员或客户端,如mysqlbinlog,并在relay日志中写入压缩状态。因此,二进制日志事务压缩可以在事务的发起者和接收者(及其备份)中节省存储空间,并且在服务器实例之间发送事务时节省网络带宽。对于
binlog_transaction_compression=ON
要生效,必须在服务器上启用二进制日志。MySQL 8.4 服务器实例无二进制日志时,可以接收、处理和显示压缩的事务负载,无论binlog_transaction_compression
的值。压缩的事务负载由其他服务器在复制拓扑结构中执行的压缩,写入relay日志中,因此可以间接地受益于压缩。这个系统变量不能在事务上下文中更改。设置这个系统变量的会话值是一个受限制的操作。会话用户必须具有足够的权限来设置受限制的会话变量。请参阅第7.1.9.1节,“系统变量权限”。
关于二进制日志事务压缩的更多信息,包括事件是否压缩的详细信息,以及在启用事务压缩时的行为变化,请见第7.4.4.5节,“二进制日志事务压缩”。
您可以使用
ndb_log_transaction_compression
系统变量为NDB
启用该特性。另外,在命令行或my.cnf
文件中设置--binlog-transaction-compression=ON
将在服务器启动时启用ndb_log_transaction_compression
。请参阅变量的描述以获取更多信息。 -
binlog_transaction_compression_level_zstd
Command-Line Format --binlog-transaction-compression-level-zstd=#
System Variable binlog_transaction_compression_level_zstd
Scope 全局、会话 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value 3
Minimum Value 1
Maximum Value 22
设置二进制日志事务压缩的压缩级别,这是由
binlog_transaction_compression
系统变量启用的。值是一个整数,确定压缩努力,从1(最低努力)到22(最高努力)。如果您不指定该系统变量,压缩级别将设置为3。随着压缩级别的增加,数据压缩比率增加,减少事务负载的存储空间和网络带宽。然而,压缩努力的增加不一定与数据压缩比率的增加成线性关系。
该系统变量不能在事务上下文中更改。设置会话值的系统变量是受限制的操作。会话用户必须具有足够的权限以设置受限制的会话变量。请见第7.1.9.1节,“系统变量权限”。
该变量对
NDB
表的事务日志没有影响;请使用ndb_log_transaction_compression_level_zstd
代替。 -
binlog_transaction_dependency_history_size
Command-Line Format --binlog-transaction-dependency-history-size=#
System Variable binlog_transaction_dependency_history_size
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value 25000
Minimum Value 1
Maximum Value 1000000
设置了一个限制,用于在内存中存储行哈希的数量,以便在查找最后修改给定行的交易时使用。一次达到这个数量后,历史记录将被清除。
-
显示服务器的二进制日志状态,可能是启用(
ON
)或禁用(OFF
)。启用二进制日志时,服务器将记录所有更改数据的语句到二进制日志中,这用于备份和复制。ON
表示二进制日志可用,OFF
表示它不可用。可以使用--log-bin
选项指定二进制日志的基础名称和位置。在早期MySQL版本中,二进制日志默认禁用,并且在指定
--log-bin
选项时启用。二进制日志现在默认启用,log_bin
系统变量设置为ON
,无论是否指定--log-bin
选项。唯一的例外是使用mysqld手动初始化数据目录时,二进制日志默认禁用。可以在这种情况下启用二进制日志指定--log-bin
选项。如果在启动时指定
--skip-log-bin
或--disable-log-bin
选项,二进制日志将被禁用,log_bin
系统变量设置为OFF
。如果指定这两个选项,并且指定--log-bin
选项,后者将优先。有关二进制日志的格式和管理,请参阅Section 7.4.4, “The Binary Log”。
-
System Variable log_bin_basename
Scope 全局 Dynamic 否 SET_VAR
Hint Applies否 Type 文件名 存储了二进制日志文件的基础名称和路径,可以使用
--log-bin
服务器选项设置。最大变量长度为256。在 MySQL 8.4 中,如果没有提供--log-bin
选项,默认的基础名称为binlog
。为了与 MySQL 5.7 兼容,如果提供了--log-bin
选项,但没有字符串或为空字符串, 默认的基础名称为
,使用主机名称。默认的位置是数据目录。host_name
-bin -
Command-Line Format --log-bin-index=file_name
System Variable log_bin_index
Scope 全局 Dynamic 否 SET_VAR
Hint Applies否 Type 文件名 存储了二进制日志索引文件的基础名称和路径,可以使用
--log-bin-index
服务器选项设置。最大变量长度为256。 -
log_bin_trust_function_creators
Command-Line Format --log-bin-trust-function-creators[={OFF|ON}]
Deprecated 是 System Variable log_bin_trust_function_creators
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value OFF
当二进制日志启用时,这个变量控制是否可以信任存储函数创建者,不会创建可能写入二进制日志的不安全事件。如果设置为0(默认),用户不能创建或更改存储函数,除非拥有
SUPER
特权,或者拥有CREATE ROUTINE
或ALTER ROUTINE
特权。设置为1时,MySQL 不会强制执行这些限制对存储函数创建。这个变量也适用于触发器创建。见第27.7节,“Stored Program Binary Logging”。 -
Command-Line Format --log-replica-updates[={OFF|ON}]
System Variable log_replica_updates
Scope 全局 Dynamic 否 SET_VAR
Hint Applies否 Type 布尔 Default Value ON
log_replica_updates
指定从replication源服务器接收的更新是否将被写入到replica的二进制日志中。启用该变量将使replica将从源服务器接收的更新并由replication SQL线程执行,并将其写入到replica的二进制日志中。二进制日志控制由
--log-bin
选项启用,默认情况下启用。见第19.1.6节,“Replication and Binary Logging Options and Variables”。log_replica_updates
默认情况下启用,除非您指定--skip-log-bin
禁用二进制日志,否则MySQL将默认禁用replica更新日志。如果您需要禁用replica更新日志,而二进制日志启用,请在replica服务器启动时指定--log-replica-updates=OFF
。启用
log_replica_updates
使replication服务器可以链式连接。例如,您可能想设置replication服务器使用以下安排:A -> B -> C
在这里,
A
作为源服务器为replicaB
,并且B
作为源服务器为replicaC
。为使其工作,B
必须同时是源服务器和replica。启用二进制日志和log_replica_updates
,默认情况下启用,更新从A
接收到的将被B
写入到其二进制日志中,并可以将其传递给C
。 -
Command-Line Format --log-slave-updates[={OFF|ON}]
Deprecated 是 System Variable log_slave_updates
Scope 全局 Dynamic 否 SET_VAR
Hint Applies否 Type 布尔 Default Value ON
已弃用别名
log_replica_updates
。 -
log_statements_unsafe_for_binlog
Command-Line Format --log-statements-unsafe-for-binlog[={OFF|ON}]
Deprecated 是 System Variable log_statements_unsafe_for_binlog
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value ON
如果遇到错误1592,控制是否将生成的警告添加到错误日志中。
-
Command-Line Format --master-verify-checksum[={OFF|ON}]
Deprecated 是 System Variable master_verify_checksum
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value OFF
已弃用的别名,用于
source_verify_checksum
。 -
Command-Line Format --max-binlog-cache-size=#
System Variable max_binlog_cache_size
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value (64-bit platforms) 18446744073709547520
Default Value (32-bit platforms) 4294967295
Minimum Value 4096
Maximum Value (64-bit platforms) 18446744073709547520
Maximum Value (32-bit platforms) 4294967295
Unit 字节 Block Size 4096
如果事务需要超过这个字节数,服务器将生成一个Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage错误。當
gtid_mode
不是ON
时,最大推荐值为4GB,因为在这种情况下,MySQL不能工作于binary log positions大于4GB的位置;当gtid_mode
是ON
时,这个限制不适用,服务器可以工作于binary log positions的任意大小。如果由于
gtid_mode
不是ON
,或其他原因,你需要确保binary log不超过给定的大小maxsize
,你应该将这个变量设置为以下公式所示:max_binlog_cache_size < (((maxsize - max_binlog_size) / max_connections) - 1000) / 1.2
这个计算考虑了以下条件:
-
服务器将直到binary log的大小小于
max_binlog_size
时才写入。 -
服务器不写入单个事务,而是将事务组成组。最大可能的事务组数等于
max_connections
。 -
服务器将不在缓存中包含的数据写入。包括每个事件的4字节校验和 sum,而这增加了交易大小的20%左右。此外,服务器还将写入一个
Gtid_log_event
交易,每个事件都可以增加写入到二进制日志的1KB。
max_binlog_cache_size
只设置了事务缓存的大小,而语句缓存的上限是由max_binlog_stmt_cache_size
系统变量控制的。对
max_binlog_cache_size
的可见性与binlog_cache_size
系统变量相同,即更改其值只影响新启动的会话。 -
-
Command-Line Format --max-binlog-size=#
System Variable max_binlog_size
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value 1073741824
Minimum Value 4096
Maximum Value 1073741824
Unit 字节 Block Size 4096
如果写入二进制日志使当前日志文件大小超过该变量的值,服务器将旋转二进制日志(关闭当前文件并打开下一个)。最小值是4096字节。最大值和默认值是1GB。加密的二进制日志文件有一个512字节的头部,该头部在
max_binlog_size
中包括。事务一次写入到二进制日志中,因此它从不被拆分到多个二进制日志中。因此,如果您有大事务,您可能会看到二进制日志文件大于
max_binlog_size
。如果
max_relay_log_size
为0,max_binlog_size
的值也适用于relay日志。在服务器上使用GTIDs时,当
max_binlog_size
达到时,如果无法访问系统表mysql.gtid_executed
以写入当前二进制日志文件,二进制日志无法旋转。在这种情况下,服务器根据其binlog_error_action
设置进行响应。如果设置为IGNORE_ERROR
,服务器将记录错误并停止二进制日志记录,如果设置为ABORT_SERVER
,服务器将关闭。 -
Command-Line Format --max-binlog-stmt-cache-size=#
System Variable max_binlog_stmt_cache_size
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value 18446744073709547520
Minimum Value 4096
Maximum Value 18446744073709547520
Unit 字节 Block Size 4096
如果非事务语句在事务中需要超过这个字节数的内存,服务器将生成错误。最小值是4096。64位平台的最大值是16EB(exabytes),32位平台的最大值是4GB。
max_binlog_stmt_cache_size
只设置语句缓存的大小;事务缓存的上限由max_binlog_cache_size
系统变量控制。 -
System Variable original_commit_timestamp
Scope 会话 Dynamic 是 SET_VAR
Hint Applies否 Type 数字 用于内部使用的复制。重复执行事务时,在副本上设置该变量,以便在原始源上提交事务的时间,以微秒为单位从(epoch)开始。这使得原始提交时间可以在复制拓扑中传播。
设置会话变量的值是一个受限制的操作。会话用户必须具有
REPLICATION_APPLIER
特权(见Section 19.3.3, “Replication Privilege Checks”),或具有设置受限制的会话变量的权限(见Section 7.1.9.1, “System Variable Privileges”)。然而,请注意该变量不是用户设置的;它是由复制基础结构自动设置的。 -
Command-Line Format --source-verify-checksum[={OFF|ON}]
System Variable source_verify_checksum
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value OFF
启用
source_verify_checksum
将使源验证从二进制日志中读取的事件,通过检查校验和,并在检测到不匹配时停止。source_verify_checksum
默认禁用,在这种情况下,源将使用二进制日志中的事件长度来验证事件,以确保只读取完整的事件。 -
System Variable sql_log_bin
Scope Session Dynamic 是 SET_VAR
Hint Applies否 Type 布尔 Default Value ON
该变量控制当前会话是否启用二进制日志记录(假设二进制日志本身已启用)。默认值为
ON
。要禁用或启用当前会话的二进制日志记录,请将会话sql_log_bin
变量设置为OFF
或ON
。将该变量设置为
OFF
以在会话中暂时禁用二进制日志记录,以便在不想将更改复制到副本时进行更改。设置会话变量是受限的操作。会话用户必须具有足够的权限来设置受限的会话变量。请参阅第7.1.9.1节,“系统变量权限”。
不能在事务或子查询中设置
sql_log_bin
变量。将该变量设置为
OFF
将防止GTIDs在二进制日志中分配到事务。如果您使用GTIDs进行复制,这意味着当二进制日志记录再次启用时,写入日志的GTIDs将不包括在事务中,这意味着事务将丢失。 -
Command-Line Format --sync-binlog=#
System Variable sync_binlog
Scope 全局 Dynamic 是 SET_VAR
Hint Applies否 Type 整数 Default Value 1
Minimum Value 0
Maximum Value 4294967295
控制MySQL服务器将二进制日志同步到磁盘的频率。
-
sync_binlog=0
: 禁用 MySQL 服务器对二进制日志的磁盘同步。相反,MySQL 服务器依赖操作系统在某个时间点将二进制日志写入磁盘,从而与其他文件一样。这个设置提供了最佳的性能,但是如果出现电源故障或操作系统崩溃,可能会丢失未同步的交易记录。 -
sync_binlog=1
: 启用对二进制日志的磁盘同步,事务提交前对其进行同步。这是最安全的设置,但是可能会对性能产生负面影响,因为增加了磁盘写入次数。在电源故障或操作系统崩溃时,可能会丢失未同步的交易记录,但是这些记录将处于prepared状态,这允许自动恢复程序回滚交易,从而确保了二进制日志中没有交易丢失。 -
sync_binlog=
, whereN
N
is a value other than 0 or 1: 对二进制日志进行磁盘同步,等待N
个二进制日志提交组合。电源故障或操作系统崩溃时,可能会丢失未同步的交易记录。这设置可能会对性能产生负面影响,因为增加了磁盘写入次数。更高的值可以提高性能,但是增加了数据丢失的风险。
在使用
InnoDB
事务 replication 设置中,为了获得最高的可靠性和一致性,请使用以下设置:Caution许多操作系统和一些磁盘硬件会欺骗 flush-to-disk 操作。它们可能会告诉 mysqld flush 操作已经完成,但是实际上它并没有完成。在这种情况下,事务的可靠性不能被保证,即使使用了推荐的设置,在最坏的情况下,电源故障可能会损坏
InnoDB
数据。使用电源备份磁盘缓存在 SCSI 磁盘控制器或磁盘本身可以加速文件 flush 操作,并且使操作更加安全。您也可以尝试禁用硬件缓存中的磁盘写入缓存。 -