The binary log format has some known limitations that can affect recovery from backups. See Section 17.5.1, “Replication Features and Issues” . 

Binary logging for stored programs is done as described in Section 25.7, “Stored Program Binary Logging” . 

Note that the binary log format differs in MySQL 8.0 from previous versions of MySQL, due to enhancements in replication. See Section 17.5.2, “Replication Compatibility Between MySQL Versions” . 

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. 

•The default setting, ABORT_SERVER , makes the server halt binary logging and shut down. At this point, you can identify and correct the cause of the error. On restart, recovery proceeds as in the case of an unexpected server halt (see Section 17.4.2, “Handling an Unexpected Halt of a Replica” ). 

•The setting IGNORE_ERROR  provides backward compatibility with older versions of MySQL. With this setting, the server continues the ongoing transaction and logs the error, then halts binary logging, but continues to perform updates. At this point, you can identify and correct the cause of the error. To resume binary logging, log_bin  must be enabled again, which requires a server restart. Only use this option if you require backward compatibility, and the binary log is non-essential on this MySQL server instance. For example, you might use the binary log only for intermittent auditing or debugging of the server, and not use it for replication from the server or rely on it for point-in-time restore operations. 

By default, the binary log is synchronized to disk at each write ( 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. To prevent this, enable the sync_binlog  system variable to synchronize the binary log to disk after every N  commit groups. See Section 5.1.8, “Server System Variables” . The safest value for sync_binlog  is 1 (the default), but this is also the slowest. 

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. 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 . 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. Such an issue was resolved in previous releases by enabling InnoDB support for two-phase commit in XA transactions. In 8.0.0 and higher, the InnoDB  support for two-phase commit in XA transactions is always enabled. 

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. The InnoDB  logs are synchronized by default, and sync_binlog=1  ensures the binary log is synchronized. 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. 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. 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. 

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. 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 

