[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The binary log has replaced the old update log. The update log is removed starting from MySQL 5.0. The binary log contains all information that is available in the update log in a more efficient format and in a manner that is transactionally safe.
The binary log, like the old update log, only logs statements that really
update data. So an UPDATE
or a DELETE
with a WHERE
that finds no rows is not written to the log. It even skips UPDATE
statements that set a column to the value it already has.
The primary purpose of the binary log is to be able to update the database during a restore operation as fully as possible, as the binary log would contain all updates done after a backup was made.
The binary log is also used when you are replicating a slave from a master. See section 6. Replication in MySQL.
The binary log also contains information about how long each query took that updated the database. It doesn't contain queries that don't modify any data. If you want to log all queries (for example to find a problem query) you should use the general query log. See section 5.8.2 The General Query Log.
When started with the --log-bin[=file_name]
option, mysqld
writes a log file containing all SQL commands that update data. If no
file name is given, it defaults to the name of the host machine followed
by -bin
. If file name is given, but it doesn't contain a path, the
file is written in the data directory.
If you supply an extension to --log-bin=filename.extension
, the
extension will be silenty removed.
To the binary log filename mysqld
will append an extension that
is a number that is incremented each time you execute mysqladmin
refresh
, execute mysqladmin flush-logs
, execute the FLUSH
LOGS
statement or restart the server. A new binary log will also
automatically be created when the current one's size reaches
max_binlog_size
. Note if you are using
transactions: a transaction is written in one chunk to the binary log,
hence it is never split between several binary logs. Therefore, if you
have big transactions, you may see binlogs bigger than max_binlog_size
.
You can delete all binary log files with the RESET MASTER
command (see section RESET
), or only some of them with
PURGE MASTER LOGS
(see section 13.6.1 SQL Statements for Controlling Master Servers).
You can use the following options to mysqld
to affect what is logged
to the binary log (please make sure to read the notes which follow
this table):
Option | Description |
binlog-do-db=database_name | Tells the master that it should log updates to the binary log if the current database (that is, the one selected by |
binlog-ignore-db=database_name | Tells the master that updates where the current database (that is, the one selected by |
The rules are evaluated in the following order, to decide if the query should be written to the binary log or not:
binlog-do-db
or binlog-ignore-db
rules?
binlog-do-db
or
binlog-ignore-db
or both). Is there a current database (has any
database been selected by USE
?)?
binlog-do-db
rules?
binlog-do-db
rules?
binlog-ignore-db
rules.
Does the current database match any of the binlog-ignore-db
rules?
So for example, a slave running with only binlog-do-db=sales
will not write to the binlog any query whose current database is
different from sales
(in other words, binlog-do-db
can
sometimes mean "ignore other databases").
To be able to know which different binary log files have been used,
mysqld
will also create a binary log index file that
contains the name of all used binary log files. By default this has the
same 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=[filename]
option.
You should not manually edit this file while mysqld
is running;
doing this would confuse mysqld
.
If you are using replication, you should not delete old binary log
files until you are sure that no slave will ever need to use them.
One way to do this is to do mysqladmin flush-logs
once a day and then
remove any logs that are more than 3 days old. You can remove them
manually, or preferably using PURGE MASTER LOGS
(see section 13.6.1 SQL Statements for Controlling Master Servers) which will also safely update the binary
log index file for you (and which can take a date argument since
MySQL 4.1)
A connection with the SUPER
privilege can disable the binary
logging of its queries using SET
SQL_LOG_BIN=0
. See section 13.6.1 SQL Statements for Controlling Master Servers.
You can examine the binary log file with the mysqlbinlog
utility.
For example, you can update a MySQL server from the binary log
as follows:
shell> mysqlbinlog log-file | mysql -h server_name |
See 8.5 mysqlbinlog
, Executing the queries from a binary log for more information on the mysqlbinlog
utility and how to use it.
If you are using BEGIN [WORK]
or SET AUTOCOMMIT=0
, you must
use the MySQL binary log for backups instead of the old update log,
which will is removed in MySQL 5.0.0.
The binary logging is done immediately after a query completes but before any locks are released or any commit is done. This ensures that the log will be logged in the execution order.
Updates to non-transactional tables are stored in the binary log
immediately after execution. For transactional tables such as BDB
or InnoDB
tables, all updates (UPDATE
, DELETE
or INSERT
) that change tables are cached until a COMMIT
command is sent to the server. At this point mysqld
writes the whole
transaction to the binary log before the COMMIT
is executed.
Every thread will, on start, allocate a buffer of binlog_cache_size
to buffer queries. If a query is bigger than this, the thread will open
a temporary file to store the transaction. The temporary file will
be deleted when the thread ends.
The max_binlog_cache_size
(default 4G) can be used to restrict the
total size used to cache a multi-query transaction. If a transaction is
bigger than this it will fail and roll back.
If you are using the update or binary log, concurrent inserts will
be converted to normal inserts when using CREATE ... SELECT
or
INSERT ... SELECT
.
This is to ensure that you can re-create an exact copy of your tables by
applying the log on a backup.
The binary log format is different in versions 3.23, 4.0, and 5.0.0. Those format changes were required to enhance replication. MySQL 4.1 has the same binary log format as 4.0.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |