| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
mysqlbinlog, Executing the queries from a binary log
You can examine the binary log file (see section 5.8.4 The Binary Log) with the
mysqlbinlog utility.
shell> mysqlbinlog hostname-bin.001 |
will print all queries contained in binlog `hostname-bin.001', together with information (time the query took, ID of the thread which issued it, timestamp when it was issued etc).
You can pipe the output of mysqlbinlog into a mysql
client; this is used to recover from a crash when you have an old
backup (see section 5.6.1 Database Backups):
shell> mysqlbinlog hostname-bin.001 | mysql |
or:
shell> mysqlbinlog hostname-bin.[0-9]* | mysql |
You can also redirect the output of mysqlbinlog to a text file
instead, modify this text file (to cut queries you don't want to
execute for some reason), then execute the queries from the text file
into mysql.
mysqlbinlog has the position=# options which will print
only queries whose offset in the binlog is greater or equal to #.
If you have more than one binary log to execute on the MySQL server, the safe method is to do it in one unique MySQL connection. Here is what may be UNsafe:
shell> mysqlbinlog hostname-bin.001 | mysql # DANGER!! shell> mysqlbinlog hostname-bin.002 | mysql # DANGER!! |
It will cause problems if the first binlog contains a CREATE
TEMPORARY TABLE and the second one contains a query which uses this
temporary table: when the first mysql terminates, it will drop
the temporary table, so the second mysql will report "unknown
table". This is why you should run all binlogs you want in one unique
connection, especially if you use temporary tables. Here are two
possible ways:
shell> mysqlbinlog hostname-bin.001 hostname-bin.002 | mysql |
shell> mysqlbinlog hostname-bin.001 > /tmp/queries.sql shell> mysqlbinlog hostname-bin.002 >> /tmp/queries.sql shell> mysql -e "source /tmp/queries.sql" |
Starting from MySQL 4.0.14, mysqlbinlog can prepare suitable input
for mysql to
execute a LOAD DATA INFILE from a binlog. As the binlog
contains the data to load (this is true for MySQL 4.0; MySQL 3.23 did
not write the loaded data into the binlog, so the original
file was needed when one wanted to execute the content of
the binlog), mysqlbinlog will copy this data to a
temporary file and print a LOAD DATA INFILE command for
mysql to load
this temporary file. The location where the temporary file is
created is by default the temporary directory; it can be changed with
the local-load option of mysqlbinlog.
Warning: When you run mysqlbinlog on a binary log file,
it will create a temporary file for every found LOAD DATA INFILE
command. These files will not be automatically deleted, because
you will need them when executing the produced sql log. You should delete
them yourself when you don't need the sql log anymore. The files are named
`temporary-dir/original_file_name-#-#'.
In the future we will fix this problem by allowing mysqlbinlog
to connect directly to a mysqld server. In this case we can
safely remove the log files when the logs have been applied.
Before MySQL 4.1, mysqlbinlog could not prepare suitable output
for mysql when the binary log contained queries from different
threads using temporary tables of the same name, if these queries were
interlaced. This is solved in MySQL 4.1.
You can also use mysqlbinlog --read-from-remote-server to read
the binary log directly from a remote MySQL server. However, this is
something that is deprecated as we instead want to make it easy to to
apply binary logs to a running MySQL server.
mysqlbinlog --help will give you more information.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |