Documentation Home
MySQL 5.5 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 27.2Mb
PDF (A4) - 27.2Mb
PDF (RPM) - 26.2Mb
HTML Download (TGZ) - 6.6Mb
HTML Download (Zip) - 6.6Mb
HTML Download (RPM) - 5.6Mb
Man Pages (TGZ) - 170.5Kb
Man Pages (Zip) - 278.9Kb
Info (Gzip) - 2.6Mb
Info (Zip) - 2.6Mb
Excerpts from this Manual

13.7.6.3 FLUSH Syntax

FLUSH [NO_WRITE_TO_BINLOG | LOCAL] {
    flush_option [, flush_option] ...
  | tables_option
}

flush_option: {
    BINARY LOGS
  | DES_KEY_FILE
  | ENGINE LOGS
  | ERROR LOGS
  | GENERAL LOGS
  | HOSTS
  | LOGS
  | MASTER
  | PRIVILEGES
  | QUERY CACHE
  | RELAY LOGS
  | SLAVE
  | SLOW LOGS
  | STATUS
  | USER_RESOURCES
}

tables_option: {
    TABLES
  | TABLES tbl_name [, tbl_name] ...
  | TABLES WITH READ LOCK
  | TABLES tbl_name [, tbl_name] ... WITH READ LOCK
}

The FLUSH statement has several variant forms that clear or reload various internal caches, flush tables, or acquire locks. To execute FLUSH, you must have the RELOAD privilege. Specific flush options might require additional privileges, as described later.

Note

It is not possible to issue FLUSH statements within stored functions or triggers. However, you may use FLUSH in stored procedures, so long as these are not called from stored functions or triggers. See Section C.1, “Restrictions on Stored Programs”.

By default, the server writes FLUSH statements to the binary log so that they replicate to replication slaves. To suppress logging, specify the optional NO_WRITE_TO_BINLOG keyword or its alias LOCAL.

Note

FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE, and FLUSH TABLES WITH READ LOCK (with or without a table list) are not written to the binary log in any case because they would cause problems if replicated to a slave.

The FLUSH statement causes an implicit commit. See Section 13.3.3, “Statements That Cause an Implicit Commit”.

The mysqladmin utility provides a command-line interface to some flush operations, using commands such as flush-hosts, flush-logs, flush-privileges, flush-status, and flush-tables. See Section 4.5.2, “mysqladmin — Client for Administering a MySQL Server”.

Sending a SIGHUP signal to the server causes several flush operations to occur that are similar to various forms of the FLUSH statement. See Section 5.1.11, “Server Response to Signals”.

The RESET statement is similar to FLUSH. See Section 13.7.6.6, “RESET Syntax”, for information about using the RESET statement with replication.

The following list describes the permitted FLUSH statement flush_option values. For descriptions of FLUSH TABLES variants, see FLUSH TABLES Syntax.

FLUSH TABLES Syntax

FLUSH TABLES flushes tables, and, depending on the variant used, acquires locks. Any TABLES variant used in a FLUSH statement must be the only option used. FLUSH TABLE is a synonym for FLUSH TABLES.

Note

The descriptions here that indicate tables are flushed by closing them apply differently for InnoDB, which flushes table contents to disk but leaves them open. This still permits table files to be copied while the tables are open, as long as other activity does not modify them.


User Comments
  Posted by Simon Mudd on May 30, 2011
Please note: while the documentation does not explicitly say this for MYISAM tables FLUSH TABLES does write data out for example if you have delay_key_write set to ON (default) / ALL any dirty buffer pages are written out.

So many people use this command to FLUSH DATA.

However, for InnoDB tables if you expect FLUSH TABLE xx to do something you are in for a shock, this does not happen. It appears that even the .bfd files are not closed (if using file_per_table) so it would be useful if the documentation for this command made some reference to exceptions and that with some engines the behaviour may not be what is expected.
  Posted by Bas Vijfwinkel on November 24, 2011
For those working in PHP with high volume sites or HPC/HFT systems : using persistent connections might sometimes lead to the mysql server getting unreachable.
Biggest oddity is that it will not occur on all servers in your system/cloud at once but only on a
number of servers. Some servers seem to be able to reuse their persistent connections pretty well while other servers will be creating multiple new connections (without discarding the used ones).
Simple solutions like doubling the amount of allowed connections does not work, it will only delay the moment until it will happen again.
You can either refrain from using persistent connections or flush all hosts when you notice that you can't reach the database anymore.

The error that you will notice is the one below :
DB connection error: Host 'your.mysql-server.url' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
Also the number of connections to the mysql server will be big (netstat -a | grep mysqld) while just a few of these connections appear to be active. You might want to flush your hosts in advance in such situations.

  Posted by Matthias Siebler on June 10, 2013
A client hostname has changed from 'oldclient' to 'newclient'. IP remained the same.
New user account user1@newclient with same grants and password is created.
Try to connect from newclient: mysql -u user1 -p
The server might reject connections with "ERROR 1045 (28000): Access denied for user 'user1'@'oldclient' ...".
Connection from other clients, that have not changed hostnames, still works. New Account with IP instead of hostname works too.

The goal is to flush hosts!

m.s.
Sign Up Login You must be logged in to post a comment.