mysql参数配置binlog

官网地址： MySQL :: MySQL Replication :: 2.6.4 Binary Logging Options and Variables

欢迎关注留言，我是收集整理小能手，工具翻译，仅供参考，笔芯笔芯.

MySQL 复制 / ... / 二进制日志记录选项和变量

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

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

您可以使用本节中描述的mysqld 选项和系统变量来影响二进制日志的操作以及控制将哪些语句写入二进制日志。有关二进制日志的其他信息，请参阅二进制日志。有关使用 MySQL 服务器选项和系统变量的其他信息，请参阅服务器命令选项和服务器系统变量。

与二进制日志记录一起使用的启动选项

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

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

| 命令行格式 | --binlog-row-event-max-size=# |
| 类型 | 整数 |
| 默认值 | 8192 |
| 最小值 | 256 |
| 最大值（64 位平台） | 18446744073709551615 |
| 最大值（32 位平台） | 4294967295 |

单元字节

指定基于行的二进制日志事件的最大大小（以字节为单位）。如果可能，行将被分组为小于此大小的事件。该值应该是 256 的倍数。默认值为 8192。请参见第 5.1 节 "复制格式"。
--log-bin[=base_name]

| 命令行格式 | --log-bin=file_name |

类型文件名

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

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

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

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

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

当服务器上使用GTID时，如果异常关闭后重新启动服务器时未启用二进制日志记录，则可能会丢失部分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=file_name |
| 系统变量 | [log_bin_index](#命令行格式 --log-bin-index=file_name 系统变量 log_bin_index 范围全球的动态的不类型文件名) |
| 范围 | 全球的 |
| 动态的 | 不 |

类型文件名

二进制日志索引文件的名称，其中包含二进制日志文件的名称。默认情况下，它具有与使用选项为二进制日志文件指定的值相同的位置和基本名称--log-bin ，加上扩展名.index. 如果不指定--log-bin，则默认二进制日志索引文件名为 binlog.index. 如果省略文件名并且不指定 1 --log-bin，则默认二进制日志索引文件名为 host_name-bin.index，使用主机的名称。

有关二进制日志的格式和管理的信息，请参阅二进制日志。

语句选择选项。 以下列表中的选项会影响哪些语句写入二进制日志，从而由复制源服务器发送到其副本。副本服务器还有一些选项可以控制应执行或忽略从源接收的哪些语句。有关详细信息，请参见第 2.6.3 节 "副本服务器选项和变量"。

--binlog-do-db=db_name

| 命令行格式 | --binlog-do-db=name |

类型细绳

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

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

基于语句的日志记录。 只有那些语句才会写入默认数据库（即由选定的数据库 USE）为的二进制日志*db_name* 。要指定多个数据库，请多次使用此选项，每个数据库一次；但是，这样做不会导致跨数据库语句，例如在选择不同数据库（或没有数据库）时被记录。 UPDATE some_db.some_table SET foo='bar'
警告

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

使用基于语句的日志记录时可能无法正常工作的示例：如果服务器启动时 --binlog-do-db=sales发出以下语句，则不会 UPDATE记录该语句：
language-sql 复制代码
```
USE prices;
UPDATE sales.january SET amount=amount+1000;
```
这种"只检查默认数据库"行为的主要原因是，仅从语句中很难知道是否应该复制它（例如，如果您正在使用多表 DELETE语句或多表UPDATE 语句跨多个数据库）。如果不需要，仅检查默认数据库而不是所有数据库也更快。

另一种可能不明显的情况发生在复制给定数据库时，即使在设置选项时未指定该数据库。如果服务器以以下方式启动，则即使设置时未包含--binlog-do-db=sales以下语句，也会记录以下语句： UPDATEprices``--binlog-do-db
language-sql 复制代码
```
USE sales;
UPDATE prices.discounts SET percentage = percentage + 10;
```
因为是发出语句sales时的默认数据库，所以会记录下来。 UPDATE UPDATE

基于行的日志记录。 日志记录仅限于数据库 db_name 。db_name 仅记录所属表的更改；默认数据库对此没有影响。假设服务器启动并且启用了 --binlog-do-db=sales基于行的日志记录，然后执行以下语句：
language-sql 复制代码
```
USE prices;
UPDATE sales.february SET amount=amount+100;
```
按照语句记录数据库february中表的变化；无论是否发表该声明，都会发生这种情况。但是，当使用基于行的日志记录格式和时，不会记录以下内容所做的更改：salesUPDATE USE --binlog-do-db=sales UPDATE
language-sql 复制代码
```
USE prices;
UPDATE prices.march SET amount=amount-25;
```
即使该USE prices语句更改为USE sales，该 UPDATE语句的效果仍然不会写入二进制日志。

处理基于语句的日志记录与基于行的日志记录的另一个重要区别 --binlog-do-db在于引用多个数据库的语句。假设服务器启动为 --binlog-do-db=db1，并执行以下语句：
language-sql 复制代码
```
USE db1;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;
```
如果您使用基于语句的日志记录，则两个表的更新都会写入二进制日志。table1但是，当使用基于行的格式时，仅记录的更改；table2位于不同的数据库中，因此它不会被UPDATE. 现在假设使用了以下语句 USE db1 而不是该语句：USE db4
language-sql 复制代码
```
USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;
```
在这种情况下，UPDATE 使用基于语句的日志记录时，该语句不会写入二进制日志。table1但是，当使用基于行的日志记录时，会记录对的更改，但不会table2记录对的更改，换句话说，仅记录对名为 by 的数据库中的表的更改 --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始终记录为语句，而不考虑有效的日志记录格式，因此以下基于语句的规则 for --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您发出以下语句：
language-sql 复制代码
```
USE prices;
UPDATE sales.january SET amount=amount+1000;
```
在这种情况下会记录该UPDATE语句，因为仅适用于默认数据库（由该语句确定）。由于在语句中显式指定了数据库，因此该语句未被过滤。但是，当使用基于行的日志记录时，语句的效果不会写入二进制日志，这意味着不会记录对表的任何更改；在这种情况下，会导致对源副本中的表进行的所有更改 --binlog-ignore-db USEsalesUPDATEsales.january--binlog-ignore-db=salessales 出于二进制日志记录的目的而忽略的数据库。

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

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

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

--binlog-checksum={NONE|CRC32}

| 命令行格式 | --binlog-checksum=type |
| 类型 | 细绳 |
| 默认值 | CRC32 |

有效值 NONE CRC32

启用此选项会导致源为写入二进制日志的事件写入校验和。设置为 NONE禁用，或用于生成校验和的算法的名称；目前仅支持 CRC32 校验和，且默认为 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 测试套件内部使用此选项进行复制测试和调试。

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

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

binlog_cache_size

| 命令行格式 | --binlog-cache-size=# |
| 系统变量 | binlog_cache_size |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 32768 |
| 最小值 | 4096 |
| 最大值（64 位平台） | 18446744073709547520 |
| 最大值（32 位平台） | 4294963200 |
| 单元 | 字节 |

块大小 4096

事务期间保存二进制日志更改的缓存大小。

如果服务器支持任何事务存储引擎并且服务器启用了二进制日志（--log-bin选项），则会为每个客户端分配二进制日志缓存。如果您经常使用大型事务，则可以增加此缓存大小以获得更好的性能。和 status 变量对于调整该变量的大小非常有用Binlog_cache_use。 Binlog_cache_disk_use请参阅二进制日志。

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

| 命令行格式 | --binlog-checksum=type |
| 系统变量 | binlog_checksum |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 细绳 |
| 默认值 | CRC32 |

有效值 NONE CRC32

启用后，此变量会导致源为二进制日志中的每个事件写入校验和。 binlog_checksum支持值 NONE（禁用）和 CRC32。默认为 CRC32. binlog_checksum您无法更改交易内的值。

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

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

在源上将此变量设置为副本无法识别的值会导致副本将其自己的 binlog_checksum值设置为 NONE，并停止复制并出现错误。（Bug #13553750、Bug #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。否则，此类语句可能会导致副本与源有所不同。

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

| 命令行格式 | --binlog-error-action[=value] |
| 系统变量 | binlog_error_action |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 枚举 |
| 默认值 | ABORT_SERVER |

有效值 IGNORE_ERROR ABORT_SERVER

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

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

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

在以前的版本中，该变量被命名为 binlogging_impossible_mode。
binlog_format

| 命令行格式 | --binlog-format=format |
| 系统变量 | binlog_format |
| 范围 | 全局、会话 |
| 动态的 | 是的 |
| 类型 | 枚举 |
| 默认值 | ROW |

有效值 MIXED STATEMENT ROW

该系统变量设置二进制日志记录格式，可以是STATEMENT、 ROW、或中的任意一个MIXED。请参见第 5.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 不支持基于语句的复制。

设置此系统变量的会话值是一项受限制的操作。会话用户必须具有足够的权限才能设置受限会话变量。请参阅系统变量权限。

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

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

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

当您无法在运行时切换复制格式时存在例外情况：
- 来自存储的函数或触发器。
- 如果会话当前处于基于行的复制模式并且打开了临时表。
- 来自事务内部。
在这些情况下尝试切换格式会导致错误。

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

二进制日志格式影响以下服务器选项的行为：
- --replicate-do-db
- --replicate-ignore-db
- --binlog-do-db
- --binlog-ignore-db
这些影响将在各个选项的描述中详细讨论。
binlog_group_commit_sync_delay

| 命令行格式 | --binlog-group-commit-sync-delay=# |
| 系统变量 | binlog_group_commit_sync_delay |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 0 |
| 最小值 | 0 |
| 最大值 | 1000000 |

单元微秒

控制将二进制日志文件同步到磁盘之前二进制日志提交等待的微秒数。默认 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-no-delay-count=# |
| 系统变量 | binlog_group_commit_sync_no_delay_count |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 0 |
| 最小值 | 0 |

最大值 100000

在中止指定的当前延迟之前要等待的最大事务数 binlog_group_commit_sync_delay。如果 binlog_group_commit_sync_delay 设置为 0，则该选项无效。
binlog_max_flush_queue_time

| 命令行格式 | --binlog-max-flush-queue-time=# |
| 已弃用 | 是的 |
| 系统变量 | binlog_max_flush_queue_time |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 0 |
| 最小值 | 0 |
| 最大值 | 100000 |

单元微秒

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

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

| 命令行格式 | --binlog-order-commits[={OFF|ON}] |
| 系统变量 | binlog_order_commits |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 布尔值 |

默认值 ON

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

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

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

| 命令行格式 | --binlog-row-image=image_type |
| 系统变量 | binlog_row_image |
| 范围 | 全局、会话 |
| 动态的 | 是的 |
| 类型 | 枚举 |
| 默认值 | full |

有效值 full（记录所有列） minimal（仅记录更改的列，以及识别行所需的列） noblob（记录所有列，除了不需要的 BLOB 和 TEXT 列）

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

在MySQL基于行的复制中，每个行更改事件包含两个图像，一个"之前"图像，其列在搜索要更新的行时进行匹配，以及一个包含更改的"之后"图像。通常，MySQL 会记录前后图像的完整行（即所有列）。但是，并非严格需要在两个映像中都包含每一列，并且我们通常可以通过仅记录实际需要的那些列来节省磁盘、内存和网络使用量。
笔记

删除行时，仅记录之前的图像，因为删除后没有要传播的更改值。插入行时，仅记录后图像，因为没有要匹配的现有行。仅当更新一行时才需要之前和之后的图像，并且都写入二进制日志。

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

您可以使用系统变量使服务器记录完整或最少的行binlog_row_image。该变量实际上采用三个可能值之一，如下列表所示：
- full：记录前图像和后图像中的所有列。
- minimal：仅记录前映像中识别要更改的行所需的那些列；仅记录后映像中由 SQL 语句指定值或通过自动增量生成值的那些列。
- noblob：记录所有列（与相同 full），除了不需要识别行或未更改的列 BLOB。 TEXT
笔记

NDB Cluster 不支持此变量；设置它对表的日志记录没有影响 NDB。

默认值为full。

使用minimalor 时noblob，当且仅当源表和目标表都满足以下条件时，才能保证给定表的删除和更新正确工作：
- 所有列必须存在且顺序相同；每列必须使用与另一个表中对应列相同的数据类型。
- 这些表必须具有相同的主键定义。
（换句话说，除了不属于表主键一部分的索引之外，表必须相同。）

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

当二进制日志记录格式为时，设置此变量无效STATEMENT。当 binlog_formatis 时 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 程序忽略，因此在复制或从备份恢复时不会出现问题。要查看它们，请使用 mysqlbinlog --verbose选项两次（as-vv或）来增加详细级别--verbose --verbose。
binlog_stmt_cache_size

| 命令行格式 | --binlog-stmt-cache-size=# |
| 系统变量 | binlog_stmt_cache_size |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 32768 |
| 最小值 | 4096 |
| 最大值（64 位平台） | 18446744073709547520 |
| 最大值（32 位平台） | 4294963200 |
| 单元 | 字节 |

块大小 4096

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

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

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

| 命令行格式 | --binlog-transaction-dependency-tracking=value |
| 介绍 | 5.7.22 |
| 系统变量 | binlog_transaction_dependency_tracking |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 枚举 |
| 默认值 | COMMIT_ORDER |

有效值 COMMIT_ORDER WRITESET WRITESET_SESSION

依赖关系信息源，源用于确定哪些事务可以由副本的多线程应用程序并行执行。该变量可以采用以下列表中描述的三个值之一：
- COMMIT_ORDER：依赖信息是根据源的提交时间戳生成的。这是默认设置。
- WRITESET：依赖信息是从源的写入集生成的，任何写入不同元组的事务都可以并行化。
- WRITESET_SESSION：依赖信息是从源的写入集生成的，任何写入不同元组的事务都可以并行化，但来自同一会话的两个更新不能重新排序。
在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 则无法更改的值。如果更改该值，则在使用和语句停止并重新启动副本之前，新值不会对副本生效。 binlog_transaction_dependency_tracking``WRITESET``WRITESET_SESSIONSTOP SLAVE START SLAVE

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

| 命令行格式 | --binlog-transaction-dependency-history-size=# |
| 介绍 | 5.7.22 |
| 系统变量 | binlog_transaction_dependency_history_size |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 25000 |
| 最小值 | 1 |

最大值 1000000

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

| 命令行格式 | --expire-logs-days=# |
| 系统变量 | expire_logs_days |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 0 |
| 最小值 | 0 |
| 最大值 | 99 |

单元天

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

要手动删除二进制日志文件，请使用该 PURGE BINARY LOGS语句。请参阅PURGE BINARY LOGS 语句。
log_bin

| 系统变量 | log_bin |
| 范围 | 全球的 |
| 动态的 | 不 |

类型布尔值

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

请参阅二进制日志。
log_bin_basename

| 系统变量 | log_bin_basename |
| 范围 | 全球的 |
| 动态的 | 不 |

类型文件名

保存二进制日志文件的基本名称和路径，可以使用--log-bin 服务器选项进行设置。最大变量长度为256。在MySQL 5.7中，默认的基本名称是带有后缀的主机名称-bin。默认位置是数据目录。
log_bin_index

| 命令行格式 | --log-bin-index=file_name |
| 系统变量 | log_bin_index |
| 范围 | 全球的 |
| 动态的 | 不 |

类型文件名

保存二进制日志索引文件的基本名称和路径，可以使用 --log-bin-index服务器选项进行设置。最大变量长度为 256。
log_bin_trust_function_creators

| 命令行格式 | --log-bin-trust-function-creators[={OFF|ON}] |
| 系统变量 | log_bin_trust_function_creators |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 布尔值 |

默认值 OFF

该变量在启用二进制日志记录时应用。它控制是否可以信任存储函数创建者不会创建导致不安全事件写入二进制日志的存储函数。如果设置为 0（默认值），则不允许用户创建或更改存储的函数，除非他们拥有除或权限SUPER之外的权限。设置为 0 还强制执行这样的限制：必须使用特性或或来声明函数CREATE ROUTINE ALTER ROUTINEDETERMINISTIC``READS SQL DATA``NO SQL特征。如果该变量设置为 1，MySQL 不会对存储函数的创建强制执行这些限制。此变量也适用于触发器创建。请参阅存储程序二进制日志记录。
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.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 Cluster Replication 的升级之外， log_bin_use_v1_row_events 主要在设置复制冲突检测和解决方案时使用 NDB$EPOCH_TRANS()作为冲突检测功能，这需要版本 2 二进制日志行事件。因此，这个变量和 --ndb-log-transaction-id不兼容。
笔记

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

有关详细信息，请参阅 NDB Cluster 复制冲突解决方案。
log_builtin_as_identified_by_password

| 命令行格式 | --log-builtin-as-identified-by-password[={OFF|ON}] |
| 系统变量 | log_builtin_as_identified_by_password |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 布尔值 |

默认值 OFF

该变量影响用户管理语句的二进制日志记录。启用后，该变量具有以下效果：
- CREATE USER涉及内置身份验证插件的语句的二进制日志记录会重写语句以包含IDENTIFIED BY PASSWORD 子句。
- SET PASSWORD语句被记录为SET PASSWORD语句，而不是被重写为ALTER USER 语句。
- SET PASSWORD语句已更改为记录密码的哈希值，而不是提供的明文（未加密）密码。
启用此变量可确保与 5.6 和 5.7.6 之前的副本的跨版本复制以及在二进制日志中期望此语法的应用程序具有更好的兼容性。
log_slave_updates

| 命令行格式 | --log-slave-updates[={OFF|ON}] |
| 系统变量 | log_slave_updates |
| 范围 | 全球的 |
| 动态的 | 不 |
| 类型 | 布尔值 |

默认值 OFF

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

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

log_slave_updates当您想要链接复制服务器时启用。例如，您可能希望使用以下安排来设置复制服务器：
language-none 复制代码
```
A -> B -> C
```
在此，A充当副本的源B，并B 充当副本的源C。为此，B必须同时是源和副本。您必须同时启动 A和B来 --log-bin启用二进制日志记录，并B启用 log_slave_updates以便A将接收到的更新记录B到其二进制日志中。
log_statements_unsafe_for_binlog

| 命令行格式 | --log-statements-unsafe-for-binlog[={OFF|ON}] |
| 介绍 | 5.7.11 |
| 系统变量 | log_statements_unsafe_for_binlog |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 布尔值 |

默认值 ON

如果遇到错误 1592，则控制是否将生成的警告添加到错误日志中。
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 |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值（64 位平台） | 18446744073709547520 |
| 默认值（32 位平台） | 4294967295 |
| 最小值 | 4096 |
| 最大值（64 位平台） | 18446744073709547520 |
| 最大值（32 位平台） | 4294967295 |
| 单元 | 字节 |

块大小 4096

如果事务需要超过这么多字节，服务器会生成多语句事务需要超过"max_binlog_cache_size"字节存储错误。当 gtid_mode不是时 ON，最大推荐值为 4GB，因为在这种情况下，MySQL 无法使用大于 4GB 的二进制日志位置；当 gtid_mode是时ON，此限制不适用，并且服务器可以使用任意大小的二进制日志位置。

如果，因为gtid_mode不是ON，或者由于某些其他原因，您需要保证二进制日志不超过给定的大小*maxsize*，则应该根据此处显示的公式设置此变量：
language-simple 复制代码
```
max_binlog_cache_size < 
  (((maxsize - max_binlog_size) / max_connections) - 1000) / 1.2
```
此计算考虑以下条件：
- 只要开始写入之前的大小小于，服务器就会写入二进制日志 max_binlog_size。
- 服务器不写入单个事务，而是写入一组事务。一个组中的最大可能交易数量等于 max_connections。
- 服务器写入未包含在缓存中的数据。这包括每个事件的 4 字节校验和；虽然这使交易规模增加了不到 20%，但这个数额是不可忽略的。另外，服务器Gtid_log_event为每笔交易写入一个；这些事件中的每一个都会使写入二进制日志的内容再增加 1 KB。
max_binlog_cache_size仅设置事务缓存的大小；语句高速缓存的上限由 max_binlog_stmt_cache_size 系统变量控制。

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

| 命令行格式 | --max-binlog-size=# |
| 系统变量 | max_binlog_size |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 1073741824 |
| 最小值 | 4096 |
| 最大值 | 1073741824 |
| 单元 | 字节 |

块大小 4096

如果写入二进制日志导致当前日志文件大小超过此变量的值，服务器将轮换二进制日志（关闭当前文件并打开下一个文件）。最小值为 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

如果事务中的非事务性语句需要超过这么多字节的内存，则服务器会生成错误。最小值为 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会话，以在对不希望复制到副本的源进行更改时临时禁用二进制日志记录。

设置此系统变量的会话值是一项受限制的操作。会话用户必须具有足够的权限才能设置受限会话变量。请参阅系统变量权限。

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

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

全局sql_log_bin 变量是只读的，不能修改。全局范围已被弃用；预计它会在未来的 MySQL 版本中被删除。
sync_binlog

| 命令行格式 | --sync-binlog=# |
| 系统变量 | sync_binlog |
| 范围 | 全球的 |
| 动态的 | 是的 |
| 类型 | 整数 |
| 默认值 | 1 |
| 最小值 | 0 |

最大值 4294967295

控制 MySQL 服务器将二进制日志同步到磁盘的频率。
- sync_binlog=0：禁用 MySQL 服务器将二进制日志同步到磁盘。相反，MySQL 服务器依赖操作系统将二进制日志不时刷新到磁盘，就像处理任何其他文件一样。此设置提供最佳性能，但在发生电源故障或操作系统崩溃时，服务器可能已提交尚未同步到二进制日志的事务。
- sync_binlog=1：在提交事务之前启用二进制日志到磁盘的同步。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。如果发生电源故障或操作系统崩溃，二进制日志中丢失的事务仅处于准备状态。这允许自动恢复例程回滚事务，从而保证二进制日志中不会丢失任何事务。
- sync_binlog=N，其中*N* 是非 0 或 1 的值： N收集二进制日志提交组后，将二进制日志同步到磁盘。如果发生电源故障或操作系统崩溃，服务器可能已提交尚未刷新到二进制日志的事务。由于磁盘写入次数增加，此设置可能会对性能产生负面影响。较高的值可以提高性能，但数据丢失的风险也会增加。
InnoDB为了在与事务一起使用的复制设置中获得最大可能的持久性和一致性，请使用以下设置：
- sync_binlog=1。
- innodb_flush_log_at_trx_commit=1。
警告

许多操作系统和一些磁盘硬件会欺骗刷新到磁盘操作。他们可能会告诉 mysqld 刷新已经发生，即使它还没有发生。在这种情况下，即使采用推荐的设置，也无法保证事务的持久性，并且在最坏的情况下，断电可能会损坏InnoDB数据。在 SCSI 磁盘控制器或磁盘本身中使用电池支持的磁盘缓存可以加快文件刷新速度，并使操作更安全。您还可以尝试禁用硬件缓存中的磁盘写入缓存。
transaction_write_set_extraction

| 命令行格式 | --transaction-write-set-extraction[=value] |
| 系统变量 | transaction_write_set_extraction |
| 范围 | 全局、会话 |
| 动态的 | 是的 |
| 类型 | 枚举 |
| 默认值 | OFF |
| 有效值（≥ 5.7.14） | OFF MURMUR32 XXHASH64 |

有效值（≤ 5.7.13） OFF MURMUR32

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

当WRITESET或 WRITESET_SESSION被设置为的值时binlog_transaction_dependency_tracking， transaction_write_set_extraction 必须设置为指定算法（不能设置为 OFF）。当的当前值为或时 binlog_transaction_dependency_tracking ，WRITESET您 WRITESET_SESSION无法更改的值 transaction_write_set_extraction。