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

当使用基于行的二进制日志记录时，此设置是对基于行的二进制日志事件的最大大小(以字节为单位)的软限制。在可能的情况下，将存储在二进制日志中的行分组为事件，事件的大小不超过该设置的值。如果事件不能分割，则可以超过最大大小。该值必须是256的倍数(否则会四舍五入)。默认为8192字节。

——log-bin [=base_name］

指定要用于二进制日志文件的基本名称。启用二进制日志记录后，服务器将记录所有将数据更改为二进制日志的语句，二进制日志用于备份和复制。二进制日志是一个具有基本名称和数字扩展名的文件序列。的——log-bin选项值是日志序列的基本名称。服务器通过在基本名称中添加数字后缀顺序创建二进制日志文件。

如果您不提供——log-bin选项,MySQL使用binlog作为二进制日志文件的默认基本名称。为了与早期版本兼容，如果您提供——log-bin选项不带字符串或带空字符串时，基本名称默认为host_name本，使用主机机器的名称。

二进制日志文件的默认位置是数据目录。你可以使用——log-bin选项指定替代位置，方法是在基本名称中添加前导绝对路径名以指定不同的目录。当服务器从二进制日志索引文件中读取条目(该文件跟踪已使用的二进制日志文件)时，它检查条目是否包含相对路径。如果是，则将路径的相对部分替换为使用——log-bin选择。二进制日志索引文件中记录的绝对路径保持不变;在这种情况下，必须手动编辑索引文件，以便使用一个或多个新路径。二进制日志文件的基名称和任何指定的路径可以作为log_bin_basename系统变量。

在早期的MySQL版本中，默认情况下二进制日志是禁用的，如果指定——log-bin选择。从MySQL 8.0开始，默认启用二进制日志记录，无论您是否指定——log-bin选择。例外是如果你使用mysqld方法调用数据目录，手动初始化数据目录——初始化或——initialize-insecure选项，默认情况下禁用二进制日志记录。在这种情况下，可以通过指定——log-bin选择。当启用二进制日志记录时，log_bin显示服务器上二进制日志记录状态的system变量被设置为on。

要禁用二进制日志记录，可以指定——skip-log-bin或——disable-log-bin在启动时选项。如果指定了这两个选项中的任何一个——log-bin时，后面指定的选项优先。当禁用二进制日志记录时，log_bin系统变量设置为OFF。

当服务器上使用gtid时，如果您在异常关闭后重新启动服务器时禁用二进制日志记录，那么可能会丢失一些gtid，导致复制失败。在正常关闭中，当前二进制日志文件中的gtid集保存在mysql.gtid_executed表格在异常关闭(没有发生这种情况)之后，在恢复期间，如果仍然启用二进制日志记录功能，就会从二进制日志文件中将gtid添加到表中。如果在服务器重新启动时禁用了二进制日志记录，则服务器无法访问二进制日志文件来恢复gtid，因此无法启动复制。在正常关闭后，可以安全地禁用二进制日志记录。

的——log-slave-updates而且——slave-preserve-commit-order选项需要二进制日志记录。如果禁用二进制日志记录，则忽略这些选项或指定——log-slave-updates =了而且——skip-slave-preserve-commit-order．MySQL在默认情况下禁用这些选项——skip-log-bin或——disable-log-bin都是确定的。如果您指定——log-slave-updates或——slave-preserve-commit-order在一起——skip-log-bin或——disable-log-bin，发出警告或错误消息。

在MySQL 5.7中，启用二进制日志记录时必须指定服务器ID，否则服务器将无法启动。在MySQL 8.0中server_id系统变量默认为1。当启用二进制日志记录时，服务器现在可以使用此默认服务器ID启动，但是如果您没有通过设置显式指定服务器ID，则会发出一条信息性消息server_id系统变量。对于复制拓扑中使用的服务器，必须为每个服务器指定唯一的非零服务器ID。

有关二进制日志的格式和管理的信息，请参见第5.4.4节，“二进制日志”．

——log-bin-index [=file_name］

二进制日志索引文件的名称，包含二进制日志文件的名称。默认情况下，它的位置和基本名称与使用的二进制日志文件指定的值相同——log-bin选项，加上扩展.index．如果不指定——log-bin，默认的二进制日志索引文件名为binlog.index．如果您指定——log-bin选项，默认的二进制日志索引文件名称为host_name-bin.index，使用主机机器的名称。

有关二进制日志的格式和管理的信息，请参见第5.4.4节，“二进制日志”．

——binlog-do-db =db_name

该选项影响二进制日志记录的方式与上述方法类似——replicate-do-db影响复制。

此选项的效果取决于使用的是基于语句的日志记录格式还是基于行的日志记录格式，与的效果相同——replicate-do-db取决于使用的是基于语句的复制还是基于行的复制。您应该记住，用于记录给定语句的格式不一定与的值所表示的格式相同binlog_format．例如，DDL语句如创建表而且ALTER TABLE总是作为语句记录，而不管日志格式是否有效，因此以下基于语句的规则为——binlog-do-db在确定是否记录语句时总是应用。

Statement-based日志记录。只有这些语句被写入二进制日志，其中默认数据库(即，由使用)是db_name．若要指定多个数据库，请多次使用此选项，每个数据库一次;然而，这样做却会不导致跨数据库语句，如更新some_db.some_table设置foo = '酒吧'在选择不同的数据库(或没有数据库)时记录日志。

使用基于语句的日志记录时，可能无法正常工作的一个示例:如果服务器以——binlog-do-db =销售你发表以下声明更新语句是不记录:

使用价格;更新销售。1000年1月组数量=数量+;

主要原因是”只需检查默认数据库”问题是，仅从语句很难知道是否应该复制它(例如，如果使用多表删除语句或多个表更新跨多个数据库的语句)。如果没有必要，只检查默认数据库比检查所有数据库更快。

另一种可能不自明的情况发生在复制给定数据库时，即使在设置该选项时没有指定它。如果服务器以——binlog-do-db =销售,下面的更新语句被记录价格设置时未包含——binlog-do-db：

使用销售;更新价格。SET百分比=百分比+ 10;

因为销售是默认数据库时的更新声明发出后，更新记录。

基于行的日志记录。日志记录仅限于数据库db_name．只更改属于的表db_name记录;默认数据库对此没有影响。假设服务器以——binlog-do-db =销售然后基于行的日志记录开始生效，然后执行以下语句:

使用价格;更新销售。2月集amount=amount+100;

对2月表中销售数据库是按照更新声明;这种情况无论是否发生使用声明发布。但是，当使用基于行的日志格式和——binlog-do-db =销售，更改如下更新不是记录:

使用价格;更新价格。3月组数量= amount-25;

即使使用的价格语句改为使用销售,更新语句的效果仍然不会写入二进制日志。

另一个重要的区别是——binlog-do-db针对引用多个数据库的语句进行基于语句的日志记录处理，而不是基于行的日志记录处理。假设服务器以——binlog-do-db = db1，执行以下语句:

使用db1;更新db1。表1，db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

如果使用基于语句的日志记录，对这两个表的更新将写入二进制日志。但是，当使用基于行的格式时，只更改为表1记录;表二是在不同的数据库中，所以它不是由更新．现在假设使用db1声明,使用db4声明如下:

使用db4;更新db1。表1，db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

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

——binlog-ignore-db =db_name

该选项影响二进制日志记录的方式与上述方法类似——replicate-ignore-db影响复制。

此选项的效果取决于使用的是基于语句的日志记录格式还是基于行的日志记录格式，与的效果相同——replicate-ignore-db取决于使用的是基于语句的复制还是基于行的复制。您应该记住，用于记录给定语句的格式不一定与的值所表示的格式相同binlog_format．例如，DDL语句如创建表而且ALTER TABLE总是作为语句记录，而不管日志格式是否有效，因此以下基于语句的规则为——binlog-ignore-db在确定是否记录语句时总是应用。

Statement-based日志记录。告诉服务器不要记录默认数据库(即，由使用)是db_name．

当没有默认数据库时，选择“no”——binlog-ignore-db选项被应用，并且这样的语句总是被记录下来。(Bug #11829838, Bug #60188)

基于行的格式。告诉服务器不要将更新记录到数据库中的任何表db_name．当前数据库无效。

在使用基于语句的日志记录时，下面的示例可能不会像您预期的那样工作。假设服务器以——binlog-ignore-db =销售你发表了以下声明:

使用价格;更新销售。1000年1月组数量=数量+;

的更新声明是记录这样的案件是因为——binlog-ignore-db只适用于默认数据库(由使用声明)。因为销售数据库在语句中显式指定，则语句未被过滤。但是，当使用基于行的日志记录时，更新声明的影响不写入到二进制日志，这意味着没有更改sales.january表记录;在这种情况下,——binlog-ignore-db =销售原因所有控件的源副本中的表所做的更改销售用于二进制日志的数据库将被忽略。

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

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

——binlog-checksum ={没有| CRC32}

启用此选项将导致源写入写入二进制日志的事件的校验和。设置为没有一个禁用，或用于生成校验和的算法的名称;目前只支持CRC32校验和，默认为CRC32。不能在事务中更改此选项的设置。

——max-binlog-dump-events =N

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

——sporadic-binlog-dump-fail

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

binlog_cache_size

在事务期间保存二进制日志更改的内存缓冲区的大小。必须为4096的整数倍。

当在服务器上启用二进制日志记录时(使用log_bin如果服务器支持任何事务性存储引擎，则为每个客户端分配一个二进制日志缓存。如果事务的数据超过了内存缓冲区中的空间，那么多余的数据将存储在一个临时文件中。当二进制日志加密在服务器上激活时，内存缓冲区不会被加密，但是(来自MySQL 8.0.17)任何用于保存二进制日志缓存的临时文件都会被加密。在提交每个事务之后，通过清除内存缓冲区和截断临时文件(如果使用临时文件)来重置二进制日志缓存。

如果经常使用大型事务，可以通过增加缓存大小来减少或消除对临时文件的写入，从而获得更好的性能。的Binlog_cache_use而且Binlog_cache_disk_use状态变量对于调优这个变量的大小很有用。看到第5.4.4节，“二进制日志”．

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

binlog_checksum

当启用该变量时，该变量会导致源在二进制日志中为每个事件写一个校验和。binlog_checksum支持的值没有一个(禁用校验和)和CRC32．默认值是CRC32．当binlog_checksum是禁用的(值没有一个)，服务器通过写入和检查每个事件的事件长度(而不是校验和)来验证它只将完整的事件写入二进制日志。

将源上的这个变量设置为副本无法识别的值会导致副本设置自己的变量binlog_checksum价值没有一个，并在出现错误时停止复制。如果需要考虑与旧副本的向后兼容性，您可能希望显式地将该值设置为没有一个．

在MySQL 8.0.20之前，Group Replication不能使用校验和，也不支持校验和出现在二进制日志中，所以必须设置binlog_checksum =没有将服务器实例配置为组成员时。从MySQL 8.0.21，组复制支持校验和，所以组成员可以使用默认设置。

改变的值binlog_checksum导致二进制日志被旋转，因为校验和必须写入整个二进制日志文件，而绝不只写入其中的一部分。的值不能更改binlog_checksum在一个事务中。

启用二进制日志事务压缩时使用binlog_transaction_compression系统变量，不为压缩的事务负载中的单个事件编写校验和。相反，为GTID事件写一个校验和，为压缩后的事件写一个校验和Transaction_payload_event．

binlog_direct_non_transactional_updates

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

的binlog_direct_non_transactional_updates变量为这个问题提供了一个可能的解决方案。默认情况下，该变量是禁用的。启用binlog_direct_non_transactional_updates导致将对非事务性表的更新直接写入二进制日志，而不是写入事务缓存。

在MySQL 8.0.14中，设置这个系统变量的会话值是受限制的操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．

binlog_direct_non_transactional_updates仅适用于使用基于语句的二进制日志记录格式复制的语句；也就是说，只有当值为binlog_format是声明,或者当binlog_format是混合并且使用基于语句的格式复制给定的语句。当二进制日志格式为时，此变量不起作用行,或者当binlog_format被设置为混合并且使用基于行的格式复制给定的语句。

当二进制日志格式为时，此变量不起作用行或混合．

binlog_encryption

启用此服务器上的二进制日志文件和中继日志文件加密。从是默认的。在为二进制日志文件和中继日志文件设置加密。要启用加密，不需要在服务器上启用二进制日志记录，因此可以在没有二进制日志的副本上加密中继日志文件。要使用加密，必须安装和配置一个keyring插件来提供MySQL服务器的keyring服务。有关此操作的说明，请参见第6.4.4节，“MySQL密匙环”．任何支持的keyring插件都可以用来存储二进制日志加密密钥。

当您第一次启动启用二进制日志加密的服务器时，在初始化二进制日志和中继日志之前，会生成一个新的二进制日志加密密钥。此密钥用于加密每个二进制日志文件的文件密码(如果服务器启用了二进制日志记录)和中继日志文件(如果服务器有复制通道)，并且使用从文件密码生成的其他密钥加密文件中的数据。对所有通道加密中继日志文件，包括组复制应用程序通道和激活加密后创建的新通道。二进制日志索引文件和中继日志索引文件不加密。

如果在服务器运行时激活加密，那么此时将生成一个新的二进制日志加密密钥。例外情况是，如果加密之前在服务器上是活动的，然后被禁用，在这种情况下，之前使用的二进制日志加密密钥将再次使用。立即轮换二进制日志文件和中继日志文件，并且使用这个二进制日志加密密钥对新文件和所有后续二进制日志文件和中继日志文件的文件密码进行加密。仍然存在于服务器上的现有二进制日志文件和中继日志文件不会自动加密，但是如果不再需要它们，您可以清除它们。

如果您通过更改binlog_encryption系统变量从，二进制日志文件和中继日志文件将立即旋转，所有后续日志都不加密。之前加密的文件不会自动解密，但服务器仍然能够读取它们。的BINLOG_ENCRYPTION_ADMIN特权(或已弃用的超级在服务器运行时激活或禁用加密需要特权)。组复制应用程序通道不包含在中继日志循环请求中，因此在正常使用中对这些通道的日志进行循环之前，不会启动对它们的未加密日志记录。

有关二进制日志文件和中继日志文件加密的更多信息，请参见第17.3.2节，“加密二进制日志文件和中继日志文件”．

binlog_error_action

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

此变量默认为ABORT_SERVER，这使得服务器在遇到二进制日志错误时暂停日志记录并关闭。在重新启动时，恢复将继续，就像服务器意外停止的情况一样(参见第17.4.2节，“处理副本的意外暂停”)．

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

binlog_expire_logs_seconds

设置二进制日志过期时间，以秒为单位。在过期时间结束后，可以自动删除二进制日志文件。可能的删除发生在启动时和刷新二进制日志时。中所示的日志刷新5.4节，“MySQL服务器日志”．

默认的二进制日志过期时间为2592000秒，即30天(30*24*60*60秒)。如果两者都不存在，则默认值适用binlog_expire_logs_seconds也不是已弃用的系统变量expire_logs_days在启动时设置了一个值。如果一个变量的值为非零值binlog_expire_logs_seconds或expire_logs_days在启动时设置，该值用作二进制日志过期时间。如果在启动时为这两个变量设置了非零值，则binlog_expire_logs_seconds作为二进制日志的过期时间，且“?expire_logs_days被忽略，并发出警告消息。

若要禁用二进制日志的自动清除，请为其显式指定值0binlog_expire_logs_seconds，且不指定值expire_logs_days．为了与早期版本兼容，如果您为其显式指定值0，则自动清除也是禁用的expire_logs_days并且不要指定值binlog_expire_logs_seconds．在这种情况下，默认为binlog_expire_logs_seconds不适用。

要手动删除二进制日志文件，请使用清洗二进制日志声明。看到第13.4.1.1节，“PURGE二进制日志声明”．

binlog_format

这个系统变量设置二进制日志格式，可以是声明，行,或混合．看到第17.2.1节，“复制格式”．当在服务器上启用二进制日志记录时，该设置将生效log_bin系统变量设置为在．从MySQL 8.0开始，默认启用二进制日志记录。

binlog_format可以在启动时或运行时设置，除非在某些情况下，无法在运行时更改此变量或导致复制失败，稍后将对此进行描述。

默认值是行．异常:在NDB集群中，默认为混合；NDB集群不支持基于语句的复制。

设置此系统变量的会话值是一项受限操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．

此变量的更改何时生效以及持续时间的规则与其他MySQL服务器系统变量相同。有关更多信息，请参见第13.7.6.1节，"变量赋值的SET语法"．

当混合指定时，将使用基于语句的复制，除非只保证基于行的复制会导致正确的结果。例如，当语句包含可加载函数或UUID ()函数。

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

在运行时无法切换复制格式时存在一些例外:

在上述任何一种情况下尝试切换复制格式(或尝试设置当前复制格式)都会导致错误。但是，你可以使用PERSIST_ONLY（设置@@PERSIST_ONLY.binlog_format)在任何时候更改复制格式，因为此操作不会修改运行时全局系统变量值，并且只有在服务器重新启动后才会生效。

当存在任何临时表时，不建议在运行时切换复制格式，因为临时表仅在使用基于语句的复制时被记录日志，而对于基于行的复制和混合复制，则不被记录日志。

更改复制源服务器上的日志记录格式不会导致副本更改与其匹配的日志记录格式。如果副本启用了二进制日志记录，那么在复制过程中切换复制格式可能会导致问题，并且更改会导致使用副本声明在源使用时格式化日志记录行或混合格式的日志记录。副本无法转换接收到的二进制日志条目行日志格式声明格式在其自己的二进制日志中使用，因此这种情况可能会导致复制失败。有关更多信息，请参见5.4.4.2，“设置二进制日志格式”．

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

这些影响将在个别选项的描述中详细讨论。

binlog_group_commit_sync_delay

控制二进制日志提交在将二进制日志文件同步到磁盘之前等待多少微秒。默认情况下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是否设置为值n大于1时，延迟在每一次之后应用n二进制日志提交组。

设置binlog_group_commit_sync_delay可以增加具有(或在故障转移后可能具有)副本的任何服务器上的并行提交事务的数量，因此可以增加副本上的并行执行。要从这种效果中受益，副本服务器必须具有replica_parallel_type = LOGICAL_CLOCK(来自MySQL 8.0.26)或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_delay．如果binlog_group_commit_sync_delay设置为0，则此选项无效。

binlog_max_flush_queue_time

binlog_max_flush_queue_time已弃用，并在未来的MySQL版本中被标记为最终删除。以前，在进行组提交之前，这个系统变量以微秒为单位控制从刷新队列中继续读取事务的时间。它不再有任何效果。

binlog_order_commits

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

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

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

binlog_rotate_encryption_master_key_at_startup

指定是否在服务器启动时轮换二进制日志主键。二进制日志主密钥是二进制日志加密密钥，用于对服务器上二进制日志文件和中继日志文件的文件密码进行加密。当服务器第一次启动并启用二进制日志加密时(binlog_encryption =对)时，生成一个新的二进制日志加密密钥，并用作二进制日志主密钥。如果binlog_rotate_encryption_master_key_at_startup系统变量也设置为在当服务器重新启动时，将生成另一个二进制日志加密密钥，并将其用作所有后续二进制日志文件和中继日志文件的二进制日志主密钥。如果binlog_rotate_encryption_master_key_at_startup系统变量设置为从，这是默认值，服务器重启后将再次使用现有的二进制日志主密钥。有关二进制日志加密密钥和二进制日志主密钥的更多信息，请参见第17.3.2节，“加密二进制日志文件和中继日志文件”．

binlog_row_event_max_size

当使用基于行的二进制日志记录时，此设置是对基于行的二进制日志事件的最大大小(以字节为单位)的软限制。在可能的情况下，将存储在二进制日志中的行分组为事件，事件的大小不超过该设置的值。如果事件不能分割，则可以超过最大大小。该值必须是256的倍数(否则会四舍五入)。默认为8192字节。

这个全局系统变量是只读的，只能在服务器启动时设置。因此，只能使用PERSIST_ONLY关键字或@@persist_only限定符的集声明。

binlog_row_image

对于MySQL基于行的复制，这个变量决定如何将行映像写入二进制日志。

设置此系统变量的会话值是一项受限操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．

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

对于前面的图像，只需要记录唯一标识行所需的最小列集。如果包含该行的表有一个主键，那么只有主键列(或多个列)被写入二进制日志。否则，如果表有一个唯一的键，其所有列都是非空，则只需要记录惟一键中的列。(如果表既没有主键，也没有唯一键零列，那么所有列都必须在before映像中使用，并记录日志。)在后面的映像中，只需要记录实际更改的列。

可以使服务器记录全部或最少的行binlog_row_image系统变量。这个变量实际上有三种可能的值，如下表所示:

缺省值为完整的．

当使用最小的或noblob，当且仅当源表和目标表的以下条件都为真时，删除和更新保证对给定表正常工作:

(换句话说，除了可能存在不属于表主键的索引之外，这些表必须是相同的。)

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

当二进制日志格式为时，设置此变量无效声明．当binlog_format是混合，设置为binlog_row_image应用于使用基于行格式记录的更改，但此设置对作为语句记录的更改没有影响。

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

binlog_row_metadata

配置使用基于行的日志记录时添加到二进制日志中的表元数据量。当设置为最小的，默认只与元数据相关签署标记、列字符集和几何类型将被记录。当设置为完整的记录表的完整元数据，例如列名，枚举或集字符串值,主键信息等等。

扩展元数据的目的如下:

binlog_row_value_options

当设置为PARTIAL_JSON，这样就可以为只修改JSON文档的一小部分的更新使用一种节省空间的二进制日志格式，这将导致基于行的复制只将JSON文档中修改的部分写入二进制日志中的更新后像，而不是写入完整的文档(参见JSON值的部分更新)．这适用于更新语句使用的任何序列修改JSON列JSON_SET ()，JSON_REPLACE (),JSON_REMOVE ()．如果服务器无法生成部分更新，则使用完整文档。

默认值是一个空字符串，这将禁用该格式。要设置binlog_row_value_options并恢复到编写完整的JSON文档，将其值设置为空字符串。

设置此系统变量的会话值是一项受限操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．

binlog_row_value_options = PARTIAL_JSON仅在启用二进制日志记录时生效binlog_format被设置为行或混合．Statement-based复制总是只记录JSON文档中修改的部分，而不管设置了什么值binlog_row_value_options．要最大限度地节省空间，请使用binlog_row_image = NOBLOB或binlog_row_image =最小连同这个选项。binlog_row_image =全因为完整的JSON文档存储在前图像中，而部分更新只存储在后图像中，所以节省的空间比这两个都要少。

mysqlbinlog输出包括部分JSON更新，以事件的形式编码为base-64字符串BINLOG语句。如果——详细指定选项,mysqlbinlog使用伪sql语句将部分JSON更新显示为可读的JSON。

如果修改不能应用到副本上的JSON文档，MySQL Replication将产生错误。这包括无法找到路径。请注意，即使通过这个和其他安全检查，如果副本上的JSON文档与源上的不一致，并且应用了部分更新，理论上仍然有可能在副本上生成有效但意外的JSON文档。

binlog_rows_query_log_events

这个系统变量只影响基于行的日志记录。当启用时，它会导致服务器将信息性日志事件(如行查询日志事件)写入其二进制日志。此信息可用于调试和相关目的，例如，当无法根据行更新重构源时，获取对源发出的原始查询。

设置此系统变量的会话值是一项受限操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．

这些信息事件通常被读取二进制日志的MySQL程序忽略，因此在从备份中复制或恢复时不会产生任何问题。要查看它们，可以使用mysqlbinlog来增加详细级别——详细选择两次，either asvv或——冗长冗长的．

binlog_stmt_cache_size

二进制日志用于保存事务期间发出的非事务性语句的内存缓冲区的大小。必须为4096的整数倍。

当在服务器上启用二进制日志记录时(使用log_bin如果服务器支持任何事务性存储引擎，则为每个客户端分配单独的二进制日志事务和语句缓存。如果事务中使用的非事务性语句的数据超过了内存缓冲区中的空间，那么多余的数据将存储在一个临时文件中。当二进制日志加密在服务器上激活时，内存缓冲区不会被加密，但是(来自MySQL 8.0.17)任何用于保存二进制日志缓存的临时文件都会被加密。在提交每个事务之后，通过清除内存缓冲区和截断临时文件(如果使用临时文件)来重置二进制日志语句缓存。

如果您经常在事务期间使用大型非事务性语句，那么可以通过增加缓存大小来减少或消除对临时文件的写入，从而获得更好的性能。的Binlog_stmt_cache_use而且Binlog_stmt_cache_disk_use状态变量对于调优这个变量的大小很有用。看到第5.4.4节，“二进制日志”．

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

binlog_transaction_compression

对写入此服务器上二进制日志文件的事务启用压缩。从是默认的。使用binlog_transaction_compression_level_zstd系统变量来设置用于压缩的ZSTD算法的级别。

当启用二进制日志事务压缩时，事务有效负载将被压缩，然后作为单个事件(Transaction_payload_event)．压缩事务有效负载在复制流中发送到副本、其他Group replication组成员或客户端(例如)时保持压缩状态mysqlbinlog，并写入中继日志，但仍处于压缩状态。因此，二进制日志事务压缩可以节省事务发起方和接收方(以及它们的备份)的存储空间，并在事务在服务器实例之间发送时节省网络带宽。

为binlog_transaction_compression =对要产生直接效果，必须在服务器上启用二进制日志记录。当一个MySQL服务器实例没有二进制日志时，如果它是MySQL 8.0.20的发布版本，它可以接收、处理和显示压缩的事务负载，而不管它的值是多少binlog_transaction_compression．此类服务器实例接收到的压缩事务负载会以压缩状态写入中继日志，因此它们间接受益于复制拓扑中其他服务器执行的压缩。

不能在事务的上下文中更改此系统变量。设置此系统变量的会话值是一项受限操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．

有关二进制日志事务压缩的更多信息，包括哪些事件被压缩和哪些事件没有被压缩，以及在使用事务压缩时行为的变化的详细信息，请参见第5.4.4.5节，“二进制日志事务压缩”．

binlog_transaction_compression_level_zstd

设置此服务器上二进制日志事务压缩的压缩级别，该级别由binlog_transaction_compression系统变量。该值是一个整数，决定了压缩工作量，从1(最低的工作量)到22(最高的工作量)。如果不指定此系统变量，则压缩级别将设置为3。

随着压缩级别的增加，数据压缩比也会增加，从而减少事务负载所需的存储空间和网络带宽。但是，数据压缩所需的工作量也会增加，占用原始服务器上的时间和CPU和内存资源。压缩工作量的增加与数据压缩比的增加不是线性关系。

不能在事务的上下文中更改此系统变量。设置此系统变量的会话值是一项受限操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．

binlog_transaction_dependency_tracking

对于具有多线程副本(其中的副本)的复制源服务器replica_parallel_workers或slave_parallel_workers设置为大于0的值)，binlog_transaction_dependency_tracking指定依赖项信息的来源，源将该信息记录在二进制日志中，以帮助副本确定哪些事务可以并行执行。可能的值为:

在WRITESET或WRITESET_SESSION模式下，事务可以乱序提交，除非您也设置了replica_preserve_commit_order = 1或slave_preserve_commit_order = 1．

对于一些交易，这个WRITESET而且WRITESET_SESSION模式不能改进本应返回的结果COMMIT_ORDER模式。这适用于具有空写集或部分写集的事务、没有主键或唯一键的更新表的事务，以及以外键关系更新父表的事务。在这些情况下，来源使用COMMIT_ORDER模式来生成依赖项信息。

设置WRITESET或WRITESET_SESSION的值binlog_transaction_dependency_tracking，transaction_write_set_extraction必须设置或默认指定算法(未设置为从)．MySQL 8.0的默认设置是这样的transaction_write_set_extraction被设置为XXHASH64，这是组复制所需的设置。您选择的值transaction_write_set_extraction的值时不能再次更改binlog_transaction_dependency_tracking仍然是WRITESET或WRITESET_SESSION．如果修改了该值，新值将在副本上生效，直到该副本停止并重新启动停止复制而且开始复制语句。transaction_write_set_extraction在MySQL 8.0.26中已弃用，并将在未来的MySQL版本中删除。

的值决定了要保留和检查的行散列数，以确保最近的事务更改了给定行的值binlog_transaction_dependency_history_size．

当应用来自中继日志的事务时，组复制在认证之后执行它自己的并行化，与设置的值无关binlog_transaction_dependency_tracking．然而，价值binlog_transaction_dependency_tracking会影响将事务写到Group Replication成员上的二进制日志的方式。这些日志中的依赖项信息用于协助从捐赠者的二进制日志进行状态传输的过程，以便在成员加入或重新加入组时进行分布式恢复。对于这个过程，设置binlog_transaction_dependency_tracking = WRITESET可以根据组的工作负载提高组成员的性能。

binlog_transaction_dependency_history_size

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

expire_logs_days

指定距离自动删除二进制日志文件的天数。expire_logs_days已弃用，您应该期望在未来的版本中删除它。相反,使用binlog_expire_logs_seconds，以秒为单位设置二进制日志过期时间。如果没有设置任何系统变量的值，则默认的过期时间为30天。可能的删除发生在启动时和刷新二进制日志时。中所示的日志刷新5.4节，“MySQL服务器日志”．

指定的任何非零值expire_logs_days是忽略了如果binlog_expire_logs_seconds也是指定的，并且binlog_expire_logs_seconds作为二进制日志的过期时间。在这种情况下会发出警告消息。的非零值expire_logs_days仅应用于二进制日志过期时间，如果binlog_expire_logs_seconds未指定或指定为0。

若要禁用二进制日志的自动清除，请为其显式指定值0binlog_expire_logs_seconds，且不指定值expire_logs_days．为了与早期版本兼容，如果您为其显式指定值0，则自动清除也是禁用的expire_logs_days并且不要指定值binlog_expire_logs_seconds．在这种情况下，默认为binlog_expire_logs_seconds不适用。

要手动删除二进制日志文件，请使用清洗二进制日志声明。看到第13.4.1.1节，“PURGE二进制日志声明”．

log_bin

显示服务器上二进制日志记录的状态，可以是启用的(在)或残疾人士(从)．启用二进制日志记录后，服务器将记录所有将数据更改为二进制日志的语句，二进制日志用于备份和复制。在意味着二进制日志是可用的，从意味着它没有被使用。的——log-bin选项可用于指定二进制日志的基本名称和位置。

在早期的MySQL版本中，默认情况下二进制日志是禁用的，如果指定——log-bin选择。从MySQL 8.0开始，默认启用二进制日志记录log_bin系统变量设置为在，是否指定——log-bin选择。例外是如果你使用mysqld方法调用数据目录，手动初始化数据目录——初始化或——initialize-insecure选项，默认情况下禁用二进制日志记录。在这种情况下，可以通过指定——log-bin选择。

如果——skip-log-bin或——disable-log-bin选项，则禁用二进制日志记录，并使用log_bin系统变量设置为从．如果指定了这两个选项中的任何一个——log-bin时，后面指定的选项优先。

有关二进制日志的格式和管理的信息，请参见第5.4.4节，“二进制日志”．

log_bin_basename

保存二进制日志文件的基本名称和路径，可以使用——log-bin服务器选项。最大可变长度为256。在MySQL 8.0中，如果——log-bin选项，则默认基本名称为binlog．为了兼容MySQL 5.7，如果——log-bin选项不提供字符串或提供空字符串时，默认基本名称为host_name本，使用主机机器的名称。默认位置是数据目录。

log_bin_index

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

log_bin_trust_function_creators

当启用二进制日志记录时，此变量将应用。它控制是否可以信任存储的函数创建者不创建可能导致不安全事件写入二进制日志的存储函数。如果设置为0(默认值)，则不允许用户创建或更改存储的函数，除非用户具有超级特权除了创建程序或改变日常特权。设置为0还强制限制函数必须使用确定的有特色的，还是带着的读取SQL数据或没有SQL的特点。如果变量设置为1,MySQL不会对存储函数的创建实施这些限制。此变量也适用于触发器的创建。看到第25.7节，“存储程序二进制日志”．

log_bin_use_v1_row_events

不赞成使用这个只读系统变量。设置系统变量为在在服务器启动时启用了基于行的复制，通过使用版本1的二进制日志行事件来写入二进制日志，而不是版本2的二进制日志行事件，后者是MySQL 5.6的默认设置。

log_replica_updates

从MySQL 8.0.26，使用log_replica_updates在的地方log_slave_updates，在该版本中已弃用。在MySQL 8.0.26之前的版本中，使用log_slave_updates．

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

启用此变量将导致副本将从源接收并由复制SQL线程执行的更新写入副本自己的二进制日志。控件控制的二进制日志记录——log-bin选项，默认为启用，也必须在副本上启用，以便记录更新。看到第17.1.6节，“复制和二进制日志记录选项和变量”．log_replica_updates默认启用，除非您指定——skip-log-bin在这种情况下，MySQL默认也禁用副本更新日志。如果需要在启用二进制日志记录时禁用副本更新日志记录，请指定——log-replica-updates =了在副本服务器启动时。

启用log_replica_updates启用复制服务器链接。例如，您可能希望使用以下安排来设置复制服务器:

b ->

在这里,一个作为副本的源B,B作为副本的源C．为了让它工作，B一定是两者都是来源而且一个副本。启用二进制日志记录和log_replica_updates启用，这是默认设置，接收到的更新一个被记录的B到它的二进制日志，因此可以传递到C．

log_slave_updates

从MySQL 8.0.26,log_slave_updates已弃用和别名log_replica_updates应该用它代替。在MySQL 8.0.26之前的版本中，使用log_slave_updates．

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

启用此变量将导致副本将从源接收并由复制SQL线程执行的更新写入副本自己的二进制日志。控件控制的二进制日志记录——log-bin选项，默认为启用，也必须在副本上启用，以便记录更新。看到第17.1.6节，“复制和二进制日志记录选项和变量”．log_slave_updates默认启用，除非您指定——skip-log-bin在这种情况下，MySQL默认也禁用副本更新日志。如果需要在启用二进制日志记录时禁用副本更新日志记录，请指定——log-slave-updates =了在副本服务器启动时。

启用log_slave_updates启用复制服务器链接。例如，您可能希望使用以下安排来设置复制服务器:

b ->

在这里,一个作为副本的源B,B作为副本的源C．为了让它工作，B一定是两者都是来源而且一个副本。启用二进制日志记录和log_slave_updates启用，这是默认设置，接收到的更新一个被记录的B到它的二进制日志，因此可以传递到C．

log_statements_unsafe_for_binlog

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

master_verify_checksum

从MySQL 8.0.26,master_verify_checksum已弃用和别名source_verify_checksum应该用它代替。在MySQL 8.0.26之前的版本中，使用master_verify_checksum．

启用master_verify_checksum使源通过检查校验和来验证从二进制日志中读取的事件，并在不匹配的事件中出现错误时停止。master_verify_checksum默认禁用;在这种情况下，源使用二进制日志中的事件长度来验证事件，因此只从二进制日志中读取完整的事件。

max_binlog_cache_size

如果一个事务需要超过这个字节的内存，服务器将生成一个多语句事务需要大于'max_binlog_cache_size'字节的存储错误。最小值为4096。最大值为16EiB (exbibytes)。推荐的最大值为4GB;这是因为MySQL目前无法处理大于4GB的二进制日志位置。必须为4096的整数倍。

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

会议的可见性max_binlog_cache_size与binlog_cache_size系统变量;换句话说，更改其值只会影响更改值后启动的新会话。

max_binlog_size

如果对二进制日志的写入导致当前日志文件的大小超过这个变量的值，服务器将旋转二进制日志(关闭当前文件并打开下一个文件)。最小值为4096字节。最大和默认值为1GB。加密的二进制日志文件有一个额外的512字节的头，它包含在max_binlog_size．

一个事务被写入一个块到二进制日志中，所以它不会被分割到几个二进制日志中。因此，如果您有较大的事务，您可能会看到比max_binlog_size．

如果max_relay_log_size0的值是多少max_binlog_size也适用于中继日志。

当服务器上使用gtid时max_binlog_size是否达到，如果系统表mysql.gtid_executed不能从当前二进制日志文件中写入gtid，二进制日志不能旋转。在这种情况下，服务器根据其binlog_error_action设置。如果IGNORE_ERROR，则在服务器上记录错误并停止二进制日志记录，或者如果ABORT_SERVER设置，服务器关闭。

max_binlog_stmt_cache_size

如果事务中的非事务性语句需要超过这个字节的内存，服务器将生成一个错误。最小值为4096。32位平台上的最大值和默认值是4GB, 64位平台上的最大值是16EB(艾字节)。必须为4096的整数倍。

max_binlog_stmt_cache_size只设置语句缓存的大小;事务缓存的上限完全由max_binlog_cache_size系统变量。

original_commit_timestamp

供内部复制使用。当在副本上重新执行事务时，将该时间设置为事务在原始源上提交的时间，以纪元以来的微秒为单位。这允许原始提交时间戳在整个复制拓扑中传播。

设置此系统变量的会话值是一项受限操作。会话用户必须具有REPLICATION_APPLIER特权(见第17.3.3节，“复制权限检查”)或足够的权限来设置受限制的会话变量(请参见第5.1.9.1节，“系统变量权限”)．但是，请注意，该变量不是为用户设置的;它由复制基础设施自动设置。

source_verify_checksum

从MySQL 8.0.26，使用source_verify_checksum在的地方master_verify_checksum，在该版本中已弃用。在MySQL 8.0.26之前的版本中，使用master_verify_checksum．

启用source_verify_checksum使源通过检查校验和来验证从二进制日志中读取的事件，并在不匹配的事件中出现错误时停止。source_verify_checksum默认禁用;在这种情况下，源使用二进制日志中的事件长度来验证事件，因此只从二进制日志中读取完整的事件。

sql_log_bin

该变量控制是否为当前会话启用了二进制日志记录(假设二进制日志本身已启用)。缺省值为在．要禁用或启用当前会话的二进制日志记录，请设置会话sql_log_bin变量来从或在．

将此变量设置为从对于一个会话来说，当对源文件进行更改时，如果不想复制到副本中，可以暂时禁用二进制日志记录。

设置此系统变量的会话值是一项受限操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．

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

将此变量设置为从防止gtid被分配给二进制日志中的事务．如果您正在使用gtid进行复制，这意味着即使以后再次启用二进制日志记录，从这一点写入日志的gtid也不会考虑在此期间发生的任何事务，因此实际上这些事务会丢失。

sync_binlog

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

在使用的复制设置中尽可能地保持持久性和一致性InnoDB对于事务，使用以下设置:

transaction_write_set_extraction

此系统变量指定用于在事务期间对提取的写进行散列的算法。MySQL 8.0的默认设置是这样的transaction_write_set_extraction被设置为XXHASH64．从意味着不收集写集。transaction_write_set_extraction在MySQL 8.0.26中已弃用，并将在未来的MySQL版本中删除。

的XXHASH64在其中，从事务中提取写操作的过程用于对所有组成员进行冲突检测和认证(请参见第18.3.1节，“组复制要求”)．对于具有多线程副本(其中的副本)的复制源服务器replica_parallel_workers或slave_parallel_workers设置为大于0的值)，其中binlog_transaction_dependency_tracking被设置为WRITESET或WRITESET_SESSION要从源的写集生成依赖项信息，transaction_write_set_extraction必须设置或默认指定算法(未设置为从)．的当前值binlog_transaction_dependency_tracking是WRITESET或WRITESET_SESSION的值不能更改transaction_write_set_extraction．

在MySQL 8.0.14中，设置这个系统变量的会话值是受限制的操作。会话用户必须有足够的权限来设置受限的会话变量。看到第5.1.9.1节，“系统变量权限”．binlog_format必须设置为行更改此系统变量的值。如果修改了该值，新值将在副本上生效，直到该副本停止并重新启动停止复制而且开始复制语句。