——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 =销售然后你发布以下声明更新语句是不记录:

使用价格;更新销售。1月份设定金额=金额+1000;

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

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

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

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

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

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

的更改2月表中的销售数据库都是按照更新声明;这种情况是否会发生使用发表了声明。但是，当使用基于行的日志记录格式时——binlog-do-db =销售，更改如下所示更新未被记录:

使用价格;更新价格。3月SET amount=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．

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

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

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

使用价格;更新销售。1月份设定金额=金额+1000;

的更新声明是登录这样的情况是因为——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系统变量设置为ON)，如果服务器支持任何事务性存储引擎，则为每个客户机分配一个二进制日志缓存。如果事务的数据超过内存缓冲区中的空间，多余的数据将存储在临时文件中。当二进制日志加密在服务器上激活时，内存缓冲区是不加密的，但是(从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之前，组复制不能使用校验和，也不支持它们出现在二进制日志中，因此必须设置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_updatesVariable为这个问题提供了一个可能的解决方案。默认情况下，该变量是禁用的。启用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插件都可以用来存储二进制日志加密密钥。

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

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

如果您通过更改binlog_encryption系统变量为从，二进制日志文件和中继日志文件立即旋转，所有后续日志都是不加密的。以前加密的文件不会自动解密，但服务器仍然能够读取它们。的BINLOG_ENCRYPTION_ADMIN特权(或已弃用的特权超级特权)在服务器运行时激活或取消激活加密。Group Replication应用程序通道不包括在中继日志旋转请求中，因此直到这些通道的日志在正常使用中被旋转，这些通道的非加密日志才开始记录。

有关二进制日志文件和中继日志文件加密的详细信息，请参见第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节“清除二进制日志语句”．

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版本中最终删除。以前，这个系统变量以微秒为单位控制时间，以便在继续进行组提交之前继续从flush队列读取事务。它不再有任何效果。

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会记录之前和之后映像的完整行(即所有列)。但是，在两个映像中并没有必要包含每一列，通过只记录实际需要的列，我们通常可以节省磁盘、内存和网络使用量。

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

属性可以使服务器记录满行或最小行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文档发生了分歧，并且应用了部分更新，理论上仍然可以在副本上生成有效但意外的JSON文档。

binlog_rows_query_log_events

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

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

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

binlog_stmt_cache_size

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

在服务器上启用二进制日志记录时(使用log_bin系统变量设置为ON)，如果服务器支持任何事务性存储引擎，则为每个客户机分配单独的二进制日志事务和语句缓存。如果事务中使用的非事务性语句的数据超过了内存缓冲区中的空间，那么多余的数据将存储在临时文件中。当二进制日志加密在服务器上激活时，内存缓冲区是不加密的，但是(从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．

在从中继日志应用事务时，Group Replication在认证后执行自己的并行化，与为的值设置无关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节“清除二进制日志语句”．

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本，使用主机的名称。默认位置为data目录。

log_bin_index

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

log_bin_trust_function_creators

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

log_bin_use_v1_row_events

不建议使用此只读系统变量。设置系统变量为在在服务器启动时，通过使用版本1的二进制日志行事件写入二进制日志，而不是MySQL 5.6的默认版本2的二进制日志行事件，在运行MySQL server 5.5及更早版本的副本中启用基于行的复制。

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允许复制服务器被链接。例如，你可能想要使用这样的安排来设置复制服务器:

A -> b -> c

在这里,一个作为副本的源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允许复制服务器被链接。例如，你可能想要使用这样的安排来设置复制服务器:

A -> b -> c

在这里,一个作为副本的源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_size的值为0max_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 (exabytes)。必须为4096的倍数。

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

original_commit_timestamp

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

设置该系统变量的会话值为受限操作。会话用户必须具有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设置是Group Replication所必需的，其中从事务中提取写操作的过程用于对所有组成员进行冲突检测和认证(请参阅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必须设置为行更改此系统变量的值。