二进制日志包含描述数据库更改（例如表创建操作或表数据更改）的“ 事件 ”。它还包含针对可能进行了更改的语句的事件（例如， DELETE不匹配任何行的a），除非使用基于行的日志记录。二进制日志还包含有关每个语句花费该更新数据多长时间的信息。二进制日志有两个重要目的：
- 对于复制，复制源服务器上的二进制日志提供了要发送到副本的数据更改的记录。源将其二进制日志中包含的信息发送到其副本，副本将复制这些事务，以对源进行相同的数据更改。请参见 第17.2节“复制实现”。
- 某些数据恢复操作需要使用二进制日志。恢复备份后，将重新执行二进制日志中在备份后记录的事件。这些事件使数据库从备份开始就保持最新状态。请参见 第7.5节“时间点（增量）恢复”。
二进制日志不用于诸如SELECT或 SHOW不修改数据的语句 。要记录所有语句（例如，确定问题查询），请使用常规查询日志。请参见第5.4.3节“常规查询日志”。
运行启用了二进制日志记录的服务器会使性能稍微降低。但是，二进制日志在使您能够设置复制和进行还原操作方面的好处通常超过了这种较小的性能下降。
二进制日志可以抵抗意外的暂停。仅记录或读取完整的事件或事务。
服务器将重写写在二进制日志中的语句中的密码，以使它们不会以纯文本的形式出现。另请参见 第6.1.2.3节“密码和日志记录”。
从MySQL 8.0.14开始，可以对二进制日志文件和中继日志文件进行加密，从而有助于保护这些文件以及其中包含的潜在敏感数据，使其免受外部攻击者的滥用，并防止未经授权的用户查看其所在的操作系统被存储。通过将binlog_encryption系统变量设置为，可以在MySQL服务器上启用加密 ON。有关更多信息，请参见 第17.3.2节“加密二进制日志文件和中继日志文件”。
以下讨论描述了一些影响二进制日志记录操作的服务器选项和变量。有关完整列表，请参见 第17.1.6.4节“二进制记录选项和变量”。
默认情况下启用二进制日志记录（ log_bin系统变量设置为ON）。例外是，如果默认情况下禁用二进制日志记录，但可以通过指定选项启用mysqld，则通过使用--initializeor --initialize-insecure选项通过调用mysqld手动初始化数据目录 --log-bin。
要禁用二进制日志记录，可以 在启动时指定 --skip-log-bin 或 --disable-log-bin选项。如果指定了这些选项中的任何一个，并且 --log-bin也指定了它们，则以后指定的选项优先。
在--log-slave-updates和 --slave-preserve-commit-order 选项需要二进制日志。如果禁用二进制日志记录，请忽略这些选项，或指定 --log-slave-updates=OFF和 --skip-slave-preserve-commit-order。当 指定--skip-log-bin 或 时，MySQL默认禁用这些选项 --disable-log-bin。如果指定 --log-slave-updates或 --slave-preserve-commit-order 连同 --skip-log-bin 或者 --disable-log-bin，发出警告或错误信息。
该 选项用于指定二进制日志文件的基本名称。如果不提供该选项，则MySQL将使用二进制日志文件的默认基本名称。为了与早期版本兼容，如果提供的选项不带字符串或带空字符串，则基本名称默认为 ，使用主机名。建议您指定一个基本名称，以便在主机名更改时，可以轻松地继续使用相同的二进制日志文件名（请参见 第B.3.7节“ MySQL中的已知问题”）。如果您在日志名称中提供扩展名（例如），则该扩展名将 被静默删除并忽略。 --log-bin[=*base_name*\]--log-bin``binlog``--log-bin``*host_name*-bin--log-bin=*base_name.extension*
mysqld在二进制日志基本名称后附加数字扩展名以生成二进制日志文件名。每次服务器创建新的日志文件时，该数目都会增加，从而创建了有序的文件系列。每次发生以下任何事件，服务器都会在系列中创建一个新文件：
- 服务器已启动或重新启动
- 服务器刷新日志。
- 当前日志文件的大小达到
max_binlog_size。
max_binlog_size与使用大型事务 相比，二进制日志文件可能会更大 ，这是因为事务是一个整体地写入文件中，而不是在文件之间分割。
为了跟踪使用了哪些二进制日志文件， mysqld还创建了一个二进制日志索引文件，其中包含二进制日志文件的名称。默认情况下，该名称与二进制日志文件具有相同的基本名称，扩展名为 '.index'。您可以使用该 选项更改二进制日志索引文件的名称 。在mysqld运行时，您不应该手动编辑该文件 。这样做会使mysqld混淆 。 --log-bin-index[=*file_name*\]
术语“ 二进制日志文件 ”通常表示包含数据库事件的单独编号文件。术语 “ 二进制日志 ”共同表示一组编号的二进制日志文件加上索引文件。
二进制日志文件和二进制日志索引文件的默认位置是数据目录。您可以使用该 --log-bin选项来指定替代位置，方法是在基本名称中添加前导绝对路径名以指定其他目录。当服务器从二进制日志索引文件中读取一个条目（该文件跟踪已使用的二进制日志文件）时，它将检查该条目是否包含相对路径。如果是这样，则将路径的相对部分替换为使用 --log-bin选项。二进制日志索引文件中记录的绝对路径保持不变；在这种情况下，必须手动编辑索引文件以启用新路径。二进制日志文件的基本名称和任何指定的路径都可以用作 log_bin_basename系统变量。
在MySQL 5.7中，启用二进制日志记录时必须指定服务器ID，否则服务器将无法启动。在MySQL 8.0中，server_id 系统变量默认设置为1。启用二进制日志记录后，可以使用该默认ID启动服务器，但是如果您未使用server_id 系统变量显式指定服务器ID，则会发出参考消息。对于复制拓扑中使用的服务器，必须为每个服务器指定唯一的非零服务器ID。
具有足以设置受限制的会话系统变量的特权的客户机（请参见 第5.1.9.1节“系统变量特权”）可以通过使用SET sql_log_bin=OFF语句禁用其自身语句的二进制记录 。
默认情况下，服务器记录事件的长度以及事件本身，并使用它来验证事件是否正确写入。您还可以通过设置binlog_checksum系统变量来使服务器编写事件的校验和 。从二进制日志回读时，源默认使用事件长度，但可以通过启用master_verify_checksum系统变量使它使用校验和（如果可用） 。副本上的复制I / O线程还会验证从源接收到的事件。通过启用slave_sql_verify_checksum系统变量，可以在从中继日志中读取时使复制SQL线程使用校验和（如果可用） 。
二进制日志中记录的事件的格式取决于二进制日志格式。支持三种格式类型：基于行的日志，基于语句的日志和基于混合的日志。使用的二进制日志记录格式取决于MySQL版本。有关日志记录格式的一般说明，请参见 第5.4.4.1节“二进制日志记录格式”。有关二进制日志格式的详细信息，请参见 MySQL内部知识：二进制日志。
服务器使用--binlog-do-db和 --binlog-ignore-db选项相同的方式 评估 --replicate-do-db和 --replicate-ignore-db选项。有关如何完成此操作的信息，请参见 第17.2.5.1节“数据库级复制和二进制日志记录选项的评估”。
副本会在 log_slave_updates默认情况下启用系统变量的情况下启动，这意味着副本会将从源接收到的所有数据修改写入其自己的二进制日志。必须启用二进制日志才能使此设置生效（请参见第17.1.6.3节“ Replica服务器选项和变量”）。此设置使副本可以充当其他副本的源。
您可以使用RESET MASTER语句删除所有二进制日志文件，也可以使用删除 它们的子集PURGE BINARY LOGS。请参见 第13.7.8.6节“ RESET语句”和第13.4.1.1节“ PURGE BINARY LOGS语句”。
如果使用复制，则在确定没有副本仍需要使用它们之前，不应删除源上的旧二进制日志文件。例如，如果您的副本从未运行超过三天，则可以每天一次在源上执行mysqladmin flush-logs，然后删除任何超过三天的日志。您可以手动删除文件，但是最好使用PURGE BINARY LOGS，它还会为您安全地更新二进制日志索引文件（并且可以使用date参数）。请参见 第13.4.1.1节“ PURGE BINARY LOGS语句”。
您可以使用mysqlbinlog实用程序显示二进制日志文件的内容 。当您要重新处理日志中的语句以进行恢复操作时，此功能很有用。例如，您可以从二进制日志更新MySQL服务器，如下所示：
shell> mysqlbinlog log_file | mysql -h server_name
mysqlbinlog也可用于在副本上显示中继日志文件的内容，因为它们是使用与二进制日志文件相同的格式编写的。有关 mysqlbinlog实用程序及其使用方法的更多信息，请参见第4.6.8节“ **mysqlbinlog-**用于处理二进制日志文件的实用程序”。有关二进制日志和恢复操作的更多信息，请参见 第7.5节“时间点（增量）恢复”。
在语句或事务完成之后但在释放任何锁或完成任何提交之前，立即执行二进制日志记录。这样可以确保日志以提交顺序记录。
非事务表的更新在执行后立即存储在二进制日志中。
在未提交的事务中，所有更改事务表（例如表）的更新（UPDATE， DELETE或 INSERT）都会InnoDB被缓存，直到COMMIT服务器接收到一条 语句。此时，mysqld在COMMIT执行之前将整个事务写入二进制日志 。
对非事务表的修改不能回滚。如果回滚的事务包括对非事务表的修改，则将记录整个事务ROLLBACK 并在末尾添加一条 语句，以确保复制对这些表的修改。
当处理事务的线程启动时，它将binlog_cache_size为缓冲区语句分配一个缓冲区。如果语句大于此值，则线程将打开一个临时文件来存储事务。当线程结束时，将删除临时文件。从MySQL 8.0.17开始，如果服务器上的二进制日志加密处于活动状态，则对临时文件进行加密。
所述Binlog_cache_use状态变量表明，用这种缓冲液（和可能的一个临时文件），用于存储语句事务的数目。该 Binlog_cache_disk_use状态变量显示有多少交易实际上不得不使用临时文件。这两个变量可用于调整 binlog_cache_size到足够大的值，从而避免使用临时文件。
所述max_binlog_cache_size系统变量（默认4GB，这也是最大）可被用来限制用于高速缓存的多语句事务的总大小。如果事务大于此多个字节，它将失败并回滚。最小值是4096。
如果使用二进制日志和基于行的日志记录，则并发插入将转换为CREATE ... SELECT或 INSERT ... SELECT语句的普通插入。这样做是为了确保您可以通过在备份操作期间应用日志来重新创建表的精确副本。如果使用的是基于语句的日志记录，则原始语句将写入日志。
二进制日志格式具有一些已知的限制，可能会影响从备份的恢复。请参见第17.5.1节“复制功能和问题”。
如第24.7节“存储的程序二进制日志记录”中所述完成 存储程序的二进制日志记录。
请注意，由于复制功能的增强，MySQL 8.0中的二进制日志格式与以前的MySQL版本不同。请参见第17.5.2节“ MySQL版本之间的复制兼容性”。
如果服务器无法写入二进制日志，刷新二进制日志文件或将二进制日志同步到磁盘，则复制源服务器上的二进制日志可能会变得不一致，并且副本可能会与源失去同步。所述 binlog_error_action系统变量控制，如果这种类型的误差与二进制日志遇到所采取的行动。
- 默认设置，
ABORT_SERVER使服务器停止二进制日志记录并关闭。此时，您可以确定并纠正错误原因。重新启动后，恢复将继续进行，就像服务器意外中止一样（请参见第17.4.2节“处理副本的意外中止 ”）。 - 该设置
IGNORE_ERROR提供了与旧版本MySQL的向后兼容性。使用此设置，服务器将继续进行中的事务并记录错误，然后停止二进制日志记录，但继续执行更新。此时，您可以确定并纠正错误原因。要恢复二进制日志记录，log_bin必须再次启用，这需要重新启动服务器。仅在需要向后兼容性且二进制日志在此MySQL服务器实例上为非必需时才使用此选项。例如，您可能只将二进制日志用于服务器的间歇审核或调试，而不将其用于从服务器复制或将其用于时间点还原操作。
默认情况下，二进制日志在每次写入（sync_binlog=1）时都会同步到磁盘。如果 sync_binlog未启用它，并且操作系统或计算机（不仅是MySQL服务器）崩溃，则二进制日志的最后一条语句可能会丢失。为防止这种情况，请sync_binlog在每个*N*提交组之后启用 系统变量以将二进制日志同步到磁盘 。请参见 第5.1.8节“服务器系统变量”。最安全的值为 sync_binlog1（默认值），但这也是最慢的。
在早期的MySQL版本中，即使发生崩溃，即使sync_binlog 设置为1 ，也有可能导致表内容和二进制日志内容之间的不一致。例如，如果您使用InnoDB 表并且MySQL服务器处理一条 COMMIT语句，它将编写许多准备好的语句。将事务按顺序发送到二进制日志，同步二进制日志，然后将事务提交到中 InnoDB。如果服务器在这两个操作之间崩溃，则事务将InnoDB在重新启动时回滚 ，但仍存在于二进制日志中。通过InnoDB在XA事务中启用对两阶段提交的支持，在以前的版本中解决了此问题 。在8.0.0及更高版本中，InnoDB 始终启用对XA事务中的两阶段提交的支持。
InnoDBXA事务中对两阶段提交的支持可确保二进制日志和 InnoDB数据文件同步。但是，MySQL服务器也应配置为InnoDB在提交事务之前将二进制日志和日志同步到磁盘。该InnoDB日志由缺省同步，并sync_binlog=1 保证了二进制日志是同步的。隐式InnoDB支持XA事务中的两阶段提交的效果 sync_binlog=1是，崩溃后重新启动时，在回滚事务后，MySQL服务器扫描最新的二进制日志文件以收集事务*xid*值并计算事务中的最后一个有效位置。二进制日志文件。然后，MySQL服务器会告诉InnoDB完成将已成功写入二进制日志的所有准备好的事务，并将二进制日志截断到最后一个有效位置。这样可以确保二进制日志反映InnoDB表的确切数据 ，因此该副本与源保持同步，因为它没有收到已回滚的语句。
如果MySQL服务器在崩溃恢复时发现二进制日志比它本来应该的短，则它至少缺少一个成功提交的InnoDB事务。如果sync_binlog=1并且在请求磁盘/文件系统进行实际同步时（某些情况没有这样做），则不会发生这种情况，因此服务器将显示一条错误消息。在这种情况下，此二进制日志不正确，应从源数据的新快照重新开始复制。 The binary log *file_name* is shorter than its expected size
以下系统变量的会话值将写入二进制日志，并在分析二进制日志时由副本服务器遵循：
