The Binary Log 1047 •Certain data recovery operations require use of the binary log. After a backup has been restored, the events in the binary log that were recorded after the backup was made are re-executed. These events bring databases up to date from the point of the backup. See Section 7.5, “Point-in-Time (Incremental) Recovery” . The binary log is not used for statements such as  SELECT  or  SHOW  that do not modify data. 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” . 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” . 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. You enable encryption on a MySQL server by setting the  binlog_encryption  system variable to  ON . For more information, see Section 17.3.2, “Encrypting Binary Log Files and Relay Log Files” . 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” . Binary logging is enabled by default (the  log_bin  system variable is set to 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. To disable binary logging, you can specify the  --skip-log-bin  or  --disable-log-bin  option at startup. If either of these options is specified and  --log-bin  is also specified, the option specified later takes precedence. The  --log-slave-updates  and  --slave-preserve-commit-order  options require binary logging. 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. 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. The  --log-bin[= base_name ]  option is used to specify the base name for binary log files. If you do not supply the  --log-bin  option, MySQL uses  binlog  as the default base name for the binary log files. 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. 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” ). If you supply an extension in the log name (for example,  --log-bin= base_name.extension ), the extension is silently removed and ignored. mysqld  appends a numeric extension to the binary log base name to generate binary log file names. 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: