Oracle 5.0 Reference Manual page 567

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. In MySQL
5.0.53 and earlier versions of MySQL 5.0, an
nontransactional table was not logged if it failed, and an
statement that encountered a duplicate key constraint—but did not actually change any data—was
not logged. Beginning with MySQL 5.0.54, both of these statements are written to the binary log. (Bug
#23333)
Within an uncommitted transaction, all updates (UPDATE, DELETE, or INSERT) that change
transactional tables such as
by the server. At that point,
executed.
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
statement at the end to ensure that the modifications to those tables are replicated.
When a thread that handles the transaction starts, it allocates a buffer of
to buffer statements. If a statement is bigger than this, the thread opens a temporary file to store the
transaction. The temporary file is deleted when the thread ends.
The
Binlog_cache_use
buffer (and possibly a temporary file) for storing statements. The
status variable shows how many of those transactions actually had to use a temporary file. These two
variables can be used for tuning
use of temporary files.
The
max_binlog_cache_size
can be used to restrict the total size used to cache a multiple-statement transaction. If a transaction is
larger than this many bytes, it fails and rolls back. The minimum value is 4096.
If you are using the binary log and row based logging, concurrent inserts are converted to normal
inserts for
CREATE ... SELECT
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 16.4.1, "Replication Features and
Binary logging for stored programs is done as described in
Programs".
Note that the binary log format differs in MySQL 5.0 from previous versions of MySQL, due to
enhancements in replication. See
Versions".
Writes to the binary log file and binary log index file are handled in the same way as writes to
tables. See Section C.5.4.3, "How MySQL Handles a Full
By default, the binary log is not synchronized to disk at each write. So if the operating system or
machine (not only the MySQL server) crashes, there is a chance that the last statements of the
binary log are lost. To prevent this, you can make the binary log be synchronized to disk after every
writes to the binary log, with the
N
System Variables". 1 is the safest value for
[1472]
sync_binlog
and binary log content in case of a crash. For example, if you are using
MySQL server processes a
then commits this transaction into InnoDB. If the server crashes between those two operations, the
transaction is rolled back by
The Binary Log
or tables are cached until a
BDB InnoDB
writes the entire transaction to the binary log before the
mysqld
[523] status variable shows the number of transactions that used this
binlog_cache_size
[1471] system variable (default 4GB, which is also the maximum)
or
INSERT ... SELECT
Issues".
Section 16.4.2, "Replication Compatibility Between MySQL
sync_binlog
sync_binlog
set to 1, there is still the chance of an inconsistency between the table content
statement, it writes the whole transaction to the binary log and
COMMIT
at restart but still exists in the binary log. This problem can be
InnoDB
547
statement using a stored function that modified a
UPDATE
INSERT ... ON DUPLICATE KEY UPDATE
Binlog_cache_disk_use
[440] to a large enough value that avoids the
statements. This is done to ensure that
Section 18.6, "Binary Logging of Stored
Disk".
[1472] system variable. See
[1472], but also the slowest. Even with
statement is received
COMMIT
ROLLBACK
binlog_cache_size
Section 5.1.4, "Server
tables and the
InnoDB
is
COMMIT
[440]
[523]
MyISAM