The binary log contains “events” that describe database changes such as table creation operations or changes to table data. 二进制日志包含描述数据库更改（如表创建操作或表数据更改）的“事件”。It also contains events for statements that potentially could have made changes (for example, a DELETE which matched no rows), unless row-based logging is used. 它还包含可能已进行更改的语句的事件（例如，不匹配任何行的DELETE），除非使用基于行的日志记录。The binary log also contains information about how long each statement took that updated data. The binary log has two important purposes:二进制日志还包含有关每条语句使用更新数据的时间的信息。二进制日志有两个重要用途：

The binary log is not used for statements such as SELECT or SHOW that do not modify data. 二进制日志不用于SELECT或SHOW等不修改数据的语句。To log all statements (for example, to identify a problem query), use the general query log. See Section 5.4.3, “The General Query Log”.要记录所有语句（例如，识别问题查询），请使用常规查询日志。请参阅第5.4.3节，“常规查询日志”。

Running a server with binary logging enabled makes performance slightly slower. However, the benefits of the binary log in enabling you to set up replication and for restore operations generally outweigh this minor performance decrement.在启用二进制日志记录的情况下运行服务器会使性能稍慢。但是，二进制登录使您能够设置复制和恢复操作，其好处通常超过了这一微小的性能下降。

The binary log is resilient to unexpected halts. Only complete events or transactions are logged or read back.二进制日志对意外停止具有弹性。只记录或读取完整的事件或事务。

Passwords in statements written to the binary log are rewritten by the server not to occur literally in plain text. See also Section 6.1.2.3, “Passwords and Logging”.写入二进制日志的语句中的密码由服务器重写，不会以纯文本形式出现。另请参见第6.1.2.3节，“密码和日志记录”。

From MySQL 8.0.14, binary log files and relay log files can be encrypted, helping to protect these files and the potentially sensitive data contained in them from being misused by outside attackers, and also from unauthorized viewing by users of the operating system where they are stored. 从MySQL 8.0.14开始，二进制日志文件和中继日志文件可以被加密，有助于保护这些文件及其包含的潜在敏感数据不被外部攻击者滥用，也不被存储这些文件的操作系统的用户未经授权查看。You enable encryption on a MySQL server by setting the binlog_encryption system variable to ON. 通过将binlog_encryption系统变量设置为ON，可以在MySQL服务器上启用加密。For more information, see Section 17.3.2, “Encrypting Binary Log Files and Relay Log Files”.有关更多信息，请参阅第17.3.2节，“加密二进制日志文件和中继日志文件”。

The following discussion describes some of the server options and variables that affect the operation of binary logging. For a complete list, see Section 17.1.6.4, “Binary Logging Options and Variables”.以下讨论描述了影响二进制日志记录操作的一些服务器选项和变量。完整列表见第17.1.6.4节，“二进制日志选项和变量”。

Binary logging is enabled by default (the log_bin system variable is set to ON). 默认情况下启用二进制日志记录（log_bin系统变量设置为ON）。The exception is if you use mysqld to initialize the data directory manually by invoking it with the --initialize or --initialize-insecure option, when binary logging is disabled by default, but can be enabled by specifying the --log-bin option.如果您使用mysqld手动初始化数据目录，方法是使用--initialize或--initialize-insecure选项调用数据目录（默认情况下禁用二进制日志记录，但可以通过指定--log-bin选项启用）。

To disable binary logging, you can specify the --skip-log-bin or --disable-log-bin option at startup. 要禁用二进制日志记录，可以在启动时指定--skip-log-bin或--disable-log-bin选项。If either of these options is specified and --log-bin is also specified, the option specified later takes precedence.如果指定了这两个选项中的任何一个，并且还指定了--log-bin，则稍后指定的选项优先。

The --log-slave-updates and --slave-preserve-commit-order options require binary logging. --log-slave-updates和--slave-preserve-commit-order选项需要二进制日志记录。If you disable binary logging, either omit these options, or specify --log-slave-updates=OFF and --skip-slave-preserve-commit-order. MySQL disables these options by default when --skip-log-bin or --disable-log-bin is specified. 如果禁用二进制日志记录，请省略这些选项，或者指定--log-slave-updates=OFF和--skip-slave-preserve-commit-order。当指定--skip-log-bin或--disable-log-bin时，MySQL默认禁用这些选项。If you specify --log-slave-updates or --slave-preserve-commit-order together with --skip-log-bin or --disable-log-bin, a warning or error message is issued.如果将--log-slave-updates或--slave-preserve-commit-order与--skip-log-bin或--disable-log-bin一起指定，则会发出警告或错误消息。

The --log-bin[=base_name] option is used to specify the base name for binary log files. --log bin[=base_name]选项用于指定二进制日志文件的基本名称。If you do not supply the --log-bin option, MySQL uses binlog as the default base name for the binary log files. 如果不提供--log-bin选项，MySQL将使用binlog作为二进制日志文件的默认基本名称。For compatibility with earlier releases, if you supply the --log-bin option with no string or with an empty string, the base name defaults to host_name-bin, using the name of the host machine. 为了与早期版本兼容，如果提供不带字符串或带空字符串的--log-bin选项，则基本名称默认为host_name-bin，使用主机的名称。It is recommended that you specify a base name, so that if the host name changes, you can easily continue to use the same binary log file names (see Section B.3.7, “Known Issues in MySQL”). 建议您指定一个基本名称，这样，如果主机名发生更改，您就可以轻松地继续使用相同的二进制日志文件名（请参阅第B.3.7节，“MySQL中的已知问题”）。If you supply an extension in the log name (for example, --log-bin=base_name.extension), the extension is silently removed and ignored.如果在日志名称中提供扩展名（例如，--log-bin=base_name.extension），则会自动删除并忽略该扩展名。

mysqld appends a numeric extension to the binary log base name to generate binary log file names.mysqld将数字扩展名附加到二进制日志基名称，以生成二进制日志文件名。 The number increases each time the server creates a new log file, thus creating an ordered series of files. The server creates a new file in the series each time any of the following events occurs:每当服务器创建一个新的日志文件，从而创建一系列有序的文件时，这个数字就会增加。每当发生以下任何事件时，服务器都会在序列中创建一个新文件：

A binary log file may become larger than max_binlog_size if you are using large transactions because a transaction is written to the file in one piece, never split between files.如果使用大型事务，二进制日志文件可能会变得大于max_binlog_size，因为事务是完整写入文件的，而不是在文件之间分割。

To keep track of which binary log files have been used, mysqld also creates a binary log index file that contains the names of the binary log files. 为了跟踪使用了哪些二进制日志文件，mysqld还创建了一个二进制日志索引文件，其中包含二进制日志文件的名称。By default, this has the same base name as the binary log file, with the extension '.index'. 默认情况下，它与二进制日志文件具有相同的基本名称，扩展名为'.index'。You can change the name of the binary log index file with the --log-bin-index[=file_name] option. 您可以使用--log-bin-index[=file_name]选项更改二进制日志索引文件的名称。You should not manually edit this file while mysqld is running; doing so would confuse mysqld.您不应该在mysqld运行时手动编辑此文件；这样做会混淆mysqld。

The term “binary log file” generally denotes an individual numbered file containing database events. 术语“二进制日志文件”通常表示包含数据库事件的单个编号文件。The term “binary log” collectively denotes the set of numbered binary log files plus the index file.术语“二进制日志”共同表示一组编号的二进制日志文件加上索引文件。

The default location for binary log files and the binary log index file is the data directory. 二进制日志文件和二进制日志索引文件的默认位置是数据目录。You can use the --log-bin option to specify an alternative location, by adding a leading absolute path name to the base name to specify a different directory. 您可以使用--log-bin选项来指定一个替代位置，方法是在基本名称中添加一个前导的绝对路径名以指定不同的目录。When the server reads an entry from the binary log index file, which tracks the binary log files that have been used, it checks whether the entry contains a relative path. 当服务器从跟踪已使用的二进制日志文件的二进制日志索引文件中读取条目时，它会检查该条目是否包含相对路径。If it does, the relative part of the path is replaced with the absolute path set using the --log-bin option. 如果是，路径的相对部分将替换为使用--log-bin选项设置的绝对路径。An absolute path recorded in the binary log index file remains unchanged; in such a case, the index file must be edited manually to enable a new path or paths to be used. 二进制日志索引文件中记录的绝对路径保持不变；在这种情况下，必须手动编辑索引文件才能使用一个或多个新路径。The binary log file base name and any specified path are available as the log_bin_basename system variable.二进制日志文件的基本名称和任何指定的路径都可用作log_bin_basename系统变量。

In MySQL 5.7, a server ID had to be specified when binary logging was enabled, or the server would not start. 在MySQL 5.7中，启用二进制日志记录时必须指定服务器ID，否则服务器将无法启动。In MySQL 8.0, the server_id system variable is set to 1 by default. 在MySQL 8.0中，server_id系统变量默认设置为1。The server can be started with this default ID when binary logging is enabled, but an informational message is issued if you do not specify a server ID explicitly using the server_id system variable. 启用二进制日志记录时，可以使用此默认ID启动服务器，但如果未使用server_id系统变量显式指定服务器ID，则会发出一条信息性消息。For servers that are used in a replication topology, you must specify a unique nonzero server ID for each server.对于复制拓扑中使用的服务器，必须为每个服务器指定一个唯一的非零服务器ID。

A client that has privileges sufficient to set restricted session system variables (see Section 5.1.9.1, “System Variable Privileges”) can disable binary logging of its own statements by using a SET sql_log_bin=OFF statement.具有足够权限设置受限会话系统变量的客户端（请参阅第5.1.9.1节，“系统变量权限”）可以使用SET sql_log_bin=OFF语句禁用其自身语句的二进制日志记录。

By default, the server logs the length of the event as well as the event itself and uses this to verify that the event was written correctly. 默认情况下，服务器会记录事件的长度以及事件本身，并使用它来验证事件是否正确写入。You can also cause the server to write checksums for the events by setting the binlog_checksum system variable. 您还可以通过设置binlog_checksum系统变量，使服务器为事件写入校验和。When reading back from the binary log, the source uses the event length by default, but can be made to use checksums if available by enabling the master_verify_checksum system variable. 从二进制日志读回时，默认情况下，源使用事件长度，但可以通过启用master_verify_checksum系统变量使其使用校验和（如果可用）。The replication I/O thread on the replica also verifies events received from the source. 复制副本上的复制I/O线程还验证从源接收到的事件。You can cause the replication SQL thread to use checksums if available when reading from the relay log by enabling the slave_sql_verify_checksum system variable.通过启用slave_sql_verify_checksum系统变量，可以使复制SQL线程在读取中继日志时使用校验和（如果可用）。

The format of the events recorded in the binary log is dependent on the binary logging format. Three format types are supported: row-based logging, statement-based logging and mixed-base logging. 二进制日志中记录的事件的格式取决于二进制日志记录格式。支持三种格式类型：基于行的日志记录、基于语句的日志记录和混合基础日志记录。The binary logging format used depends on the MySQL version. 使用的二进制日志记录格式取决于MySQL版本。For general descriptions of the logging formats, see Section 5.4.4.1, “Binary Logging Formats”. 有关日志记录格式的一般说明，请参阅第5.4.4.1节，“二进制日志记录格式”。For detailed information about the format of the binary log, see MySQL Internals: The Binary Log.有关二进制日志格式的详细信息，请参阅MySQL内部：二进制日志。

The server evaluates the --binlog-do-db and --binlog-ignore-db options in the same way as it does the --replicate-do-db and --replicate-ignore-db options. 服务器评估--binlog-do-db和--binlog-ignore-db选项的方式与评估--replicate-do-db和--replicate-ignore-db的方式相同。For information about how this is done, see Section 17.2.5.1, “Evaluation of Database-Level Replication and Binary Logging Options”.有关如何做到这一点的信息，请参阅第17.2.5.1节，“数据库级复制和二进制日志记录选项的评估”。

A replica is started with the log_slave_updates system variable enabled by default, meaning that the replica writes to its own binary log any data modifications that are received from the source. 复制副本启动时默认启用log_slave_updates系统变量，这意味着复制副本将从源接收到的任何数据修改写入其自己的二进制日志。The binary log must be enabled for this setting to work (see Section 17.1.6.3, “Replica Server Options and Variables”). 必须启用二进制日志才能使此设置正常工作（请参阅第17.1.6.3节，“副本服务器选项和变量”）。This setting enables the replica to act as a source to other replicas.此设置使复制副本能够作为其他复制副本的源。

You can delete all binary log files with the RESET MASTER statement, or a subset of them with PURGE BINARY LOGS. 您可以使用RESET MASTER语句删除所有二进制日志文件，也可以使用PURGE BINARY LOGS删除其中的一个子集。See Section 13.7.8.6, “RESET Statement”, and Section 13.4.1.1, “PURGE BINARY LOGS Statement”.请参阅第13.7.8.6节，“RESET语句”和第13.4.1.1节，“PURGE BINARY LOGS语句”。

If you are using replication, you should not delete old binary log files on the source until you are sure that no replica still needs to use them. 如果您正在使用复制，则不应删除源上的旧二进制日志文件，直到您确定没有复制副本仍需要使用这些文件为止。For example, if your replicas never run more than three days behind, once a day you can execute mysqladmin flush-logs on the source and then remove any logs that are more than three days old. 例如，如果复制副本的运行时间从未超过三天，则每天可以在源上执行一次mysqladmin flush-logs，然后删除任何超过三天的日志。You can remove the files manually, but it is preferable to use PURGE BINARY LOGS, which also safely updates the binary log index file for you (and which can take a date argument). 您可以手动删除这些文件，但最好使用PURGE BINARY LOGS，它也可以安全地为您更新二进制日志索引文件（并且可以使用日期参数）。See Section 13.4.1.1, “PURGE BINARY LOGS Statement”.请参阅第13.4.1.1节，“PURGE BINARY LOGS语句”。

You can display the contents of binary log files with the mysqlbinlog utility. 您可以使用mysqlbinlog实用程序显示二进制日志文件的内容。This can be useful when you want to reprocess statements in the log for a recovery operation. For example, you can update a MySQL server from the binary log as follows:当您希望重新处理日志中的语句以进行恢复操作时，这可能非常有用。例如，您可以从二进制日志中更新MySQL服务器，如下所示：

shell> mysqlbinlog log_file | mysql -h server_name

mysqlbinlog also can be used to display the contents of the relay log file on a replica, because they are written using the same format as binary log files. mysqlbinlog还可以用于在副本上显示中继日志文件的内容，因为它们是使用与二进制日志文件相同的格式编写的。For more information on the mysqlbinlog utility and how to use it, see Section 4.6.9, “mysqlbinlog — Utility for Processing Binary Log Files”. 有关mysqlbinlog实用程序以及如何使用它的更多信息，请参阅第4.6.9节，“mysqlbinlog用于处理二进制日志文件的实用程序”。For more information about the binary log and recovery operations, see Section 7.5, “Point-in-Time (Incremental) Recovery”.有关二进制日志和恢复操作的更多信息，请参阅第7.5节，“时间点（增量）恢复”。

Binary logging is done immediately after a statement or transaction completes but before any locks are released or any commit is done. This ensures that the log is logged in commit order.二进制日志记录是在语句或事务完成后，但在释放任何锁或完成任何提交之前立即完成的。这确保了日志是按提交顺序记录的。

Updates to nontransactional tables are stored in the binary log immediately after execution.非事务表的更新在执行后立即存储在二进制日志中。

Within an uncommitted transaction, all updates (UPDATE, DELETE, or INSERT) that change transactional tables such as InnoDB tables are cached until a COMMIT statement is received by the server. 在未提交的事务中，所有更改事务表（如InnoDB表）的更新（UPDATE、DELETE或INSERT）都会被缓存，直到服务器收到COMMIT语句。At that point, mysqld writes the entire transaction to the binary log before the COMMIT is executed.在这一点上，mysqld在COMMIT执行之前将整个事务写入二进制日志。

Modifications to nontransactional tables cannot be rolled back. 对非事务表的修改无法回滚。If a transaction that is rolled back includes modifications to nontransactional tables, the entire transaction is logged with a ROLLBACK statement at the end to ensure that the modifications to those tables are replicated.如果回滚的事务包括对非事务表的修改，则会在最后使用ROLLBACK语句记录整个事务，以确保复制对这些表的修改。

When a thread that handles the transaction starts, it allocates a buffer of binlog_cache_size to buffer statements. If a statement is bigger than this, the thread opens a temporary file to store the transaction. 当处理事务的线程启动时，它会为缓冲语句分配一个缓冲区binlog_cache_size。如果一条语句大于此值，线程将打开一个临时文件来存储事务。The temporary file is deleted when the thread ends. From MySQL 8.0.17, if binary log encryption is active on the server, the temporary file is encrypted.线程结束时将删除临时文件。从MySQL 8.0.17开始，如果二进制日志加密在服务器上处于活动状态，则对临时文件进行加密。

The Binlog_cache_use status variable shows the number of transactions that used this buffer (and possibly a temporary file) for storing statements. Binlog_cache_use状态变量显示使用该缓冲区（可能还有一个临时文件）存储语句的事务数。The Binlog_cache_disk_use status variable shows how many of those transactions actually had to use a temporary file. Binlog_cache_disk_use状态变量显示这些事务中有多少实际上必须使用临时文件。These two variables can be used for tuning binlog_cache_size to a large enough value that avoids the use of temporary files.这两个变量可用于将binlog_cache_size调整为足够大的值，从而避免使用临时文件。

The max_binlog_cache_size system variable (default 4GB, which is also the maximum) can be used to restrict the total size used to cache a multiple-statement transaction. max_binlog_cache_size系统变量（默认4GB，也是最大值）可用于限制用于缓存多语句事务的总大小。If a transaction is larger than this many bytes, it fails and rolls back. The minimum value is 4096.如果事务大于此字节数，则会失败并回滚。最小值为4096。

If you are using the binary log and row based logging, concurrent inserts are converted to normal inserts for CREATE ... SELECT or INSERT ... SELECT statements. 如果您使用二进制日志和基于行的日志记录，则CREATE ... SELECT语句或INSERT ... SELECT语句产生的并发插入将转换为正常插入。This is done to ensure that you can re-create an exact copy of your tables by applying the log during a backup operation. If you are using statement-based logging, the original statement is written to the log.这样做是为了确保您可以通过在备份操作期间应用日志来重新创建表的精确副本。如果使用基于语句的日志记录，则会将原始语句写入日志。

The binary log format has some known limitations that can affect recovery from backups. See Section 17.5.1, “Replication Features and Issues”.二进制日志格式有一些已知的限制，这些限制可能会影响从备份中恢复。请参阅第17.5.1节，“复制功能和问题”。

Binary logging for stored programs is done as described in Section 25.7, “Stored Program Binary Logging”.存储程序的二进制日志记录按照第25.7节，“存储程序二进制日志记录”所述进行。

Note that the binary log format differs in MySQL 8.0 from previous versions of MySQL, due to enhancements in replication. 请注意，MySQL 8.0中的二进制日志格式与以前版本的MySQL不同，这是由于复制方面的增强。See Section 17.5.2, “Replication Compatibility Between MySQL Versions”.请参阅第17.5.2节，“MySQL版本之间的复制兼容性”。

If the server is unable to write to the binary log, flush binary log files, or synchronize the binary log to disk, the binary log on the replication source server can become inconsistent and replicas can lose synchronization with the source. 如果服务器无法写入二进制日志、刷新二进制日志文件或将二进制日志同步到磁盘，则复制源服务器上的二进制日志可能会变得不一致，副本可能会失去与源的同步。The binlog_error_action system variable controls the action taken if an error of this type is encountered with the binary log.binlog_error_action系统变量控制在二进制日志中遇到此类错误时所采取的操作。

By default, the binary log is synchronized to disk at each write (sync_binlog=1). 默认情况下，二进制日志在每次写入时都同步到磁盘（sync_binlog=1）。If sync_binlog was not enabled, and the operating system or machine (not only the MySQL server) crashed, there is a chance that the last statements of the binary log could be lost. 如果没有启用sync_binlog，并且操作系统或机器（不仅仅是MySQL服务器）崩溃，二进制日志的最后一条语句可能会丢失。To prevent this, enable the sync_binlog system variable to synchronize the binary log to disk after every N commit groups. 为了防止这种情况发生，请启用sync_binlog系统变量，以便在每N个提交组之后将二进制日志同步到磁盘。See Section 5.1.8, “Server System Variables”. 请参阅第5.1.8节，“服务器系统变量”。The safest value for sync_binlog is 1 (the default), but this is also the slowest.sync_binlog最安全的值是1（默认值），但这也是最慢的。

In earlier MySQL releases, there was a chance of inconsistency between the table content and binary log content if a crash occurred, even with sync_binlog set to 1. 在早期的MySQL版本中，如果发生崩溃，即使sync_binlog设置为1，表内容和二进制日志内容也可能不一致。For example, if you are using InnoDB tables and the MySQL server processes a COMMIT statement, it writes many prepared transactions to the binary log in sequence, synchronizes the binary log, and then commits the transaction into InnoDB. 例如，如果您使用InnoDB表，MySQL服务器处理COMMIT语句，它会将许多准备好的事务按顺序写入二进制日志，同步二进制日志，然后将事务提交到InnoDB中。If the server unexpectedly exited between those two operations, the transaction would be rolled back by InnoDB at restart but still exist in the binary log. 如果服务器在这两个操作之间意外退出，事务将在重新启动时由InnoDB回滚，但仍存在于二进制日志中。Such an issue was resolved in previous releases by enabling InnoDB support for two-phase commit in XA transactions. 在以前的版本中，通过在XA事务中启用InnoDB对两阶段提交的支持，解决了这个问题。In 8.0.0 and higher, the InnoDB support for two-phase commit in XA transactions is always enabled.在8.0.0及更高版本中，始终启用InnoDB对XA事务中两阶段提交的支持。

InnoDB support for two-phase commit in XA transactions ensures that the binary log and InnoDB data files are synchronized. However, the MySQL server should also be configured to synchronize the binary log and the InnoDB logs to disk before committing the transaction. InnoDB对XA事务中两阶段提交的支持确保了二进制日志和InnoDB数据文件的同步。然而，MySQL服务器也应该配置为在提交事务之前将二进制日志和InnoDB日志同步到磁盘。The InnoDB logs are synchronized by default, and sync_binlog=1 ensures the binary log is synchronized. InnoDB日志默认同步，sync_binlog=1确保二进制日志同步。The effect of implicit InnoDB support for two-phase commit in XA transactions and sync_binlog=1 is that at restart after a crash, after doing a rollback of transactions, the MySQL server scans the latest binary log file to collect transaction xid values and calculate the last valid position in the binary log file. 隐式InnoDB支持XA事务和sync_binlog=1中的两阶段提交的效果是，在崩溃后重新启动时，在回滚事务后，MySQL服务器扫描最新的二进制日志文件，以收集事务xid值，并计算二进制日志文件中的最后一个有效位置。The MySQL server then tells InnoDB to complete any prepared transactions that were successfully written to the to the binary log, and truncates the binary log to the last valid position. 然后MySQL服务器告诉InnoDB完成任何准备好的事务，这些事务成功写入二进制日志，并将二进制日志截断到最后一个有效位置。This ensures that the binary log reflects the exact data of InnoDB tables, and therefore the replica remains in synchrony with the source because it does not receive a statement which has been rolled back.这确保了二进制日志反映InnoDB表的确切数据，因此副本与源保持同步，因为它不会接收到已回滚的语句。

If the MySQL server discovers at crash recovery that the binary log is shorter than it should have been, it lacks at least one successfully committed InnoDB transaction. 如果MySQL服务器在崩溃恢复时发现二进制日志比它应该的短，那么它至少缺少一个成功提交的InnoDB事务。This should not happen if sync_binlog=1 and the disk/file system do an actual sync when they are requested to (some do not), so the server prints an error message The binary log file_name is shorter than its expected size. 如果sync_binlog=1并且磁盘/文件系统在被请求时进行了实际同步（有些没有），则不应发生这种情况，因此服务器会打印错误消息二进制日志文件名比其预期大小短。In this case, this binary log is not correct and replication should be restarted from a fresh snapshot of the source's data.在这种情况下，此二进制日志不正确，应该从源数据的新快照重新启动复制。

The session values of the following system variables are written to the binary log and honored by the replica when parsing the binary log:以下系统变量的会话值被写入二进制日志，并在解析二进制日志时由副本执行：