•The server is started or restarted 

•The server flushes the logs. 

•The size of the current log file reaches max_binlog_size . 

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. 

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. By default, this has the same base name as the binary log file, with the extension ’.index’ . You can change the name of the binary log index file with the --log-bin- index[= file_name ]  option. You should not manually edit this file while mysqld  is running; doing so would confuse 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. 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. 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. 

In MySQL 5.7, a server ID had to be specified when binary logging was enabled, or the server would not start. In MySQL 8.0, the server_id  system variable is set to 1 by default. 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. For servers that are used in a replication topology, you must specify a unique nonzero server ID for each server. 

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. 

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. 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. The replication I/O thread on the replica also verifies events received from the source. 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. 

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. For general descriptions of the logging formats, see Section 5.4.4.1, “Binary Logging Formats” . For detailed information about the format of the binary log, see MySQL Internals: The Binary Log. 

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. For information about how this is done, see Section 17.2.5.1, “Evaluation of Database-Level Replication and Binary Logging Options” . 

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. The binary log 

