GNU Info

Info Node: (mysql.info)Binary log

(mysql.info)Binary log


Next: Slow query log Prev: Update log Up: Log Files
Enter node , (file) or (file)node

The Binary Update Log
---------------------

The intention is that the binary log should replace the update log, so
we recommend you to switch to this log format as soon as possible!

The binary log contains all information that is available in the update
log in a more efficient format. It also contains information about how
long every query that updated the database took.

The binary log is also used when you are replicating a slave from a
master.  Note: Replication.

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.

You can use the following options to `mysqld' to affect what is logged
to the binary log:

`binlog-do-db=database_name'   Tells the master it should log updates
                              for the specified database, and exclude
                              all others not explicitly mentioned.
                              (Example: `binlog-do-db=some_database')
`binlog-ignore-db=database_name' Tells the master that updates to the
                              given database should not be logged to the
                              binary log (Example:
                              `binlog-ignore-db=some_database')

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.

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 examine the binary log file with the `mysqlbinlog' command.
For example, you can update a MySQL server from the binary log as
follows:

     mysqlbinlog log-file | mysql -h server_name

You can also use the `mysqlbinlog' program to read the binary log
directly from a remote MySQL server!

`mysqlbinlog --help' will give you more information of how to use this
program!

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.

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.

All updates (`UPDATE', `DELETE' or `INSERT') that change a
transactional table (like BDB tables) are cached until a `COMMIT'.  Any
updates to a non-transactional table are stored in the binary log at
once.  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 handle the bigger cache.  The
temporary file will be deleted when the thread ends.

The `max_binlog_cache_size' can be used to restrict the total size used
to cache a multi-transaction query.

If you are using the update or binary log, concurrent inserts will not
work together with `CREATE ... INSERT' and `INSERT ... SELECT'.  This
is to ensure that you can recreate an exact copy of your tables by
applying the log on a backup.


automatically generated by info2www version 1.2.2.9