13.7.6.3 FLUSH 構文

FLUSH [NO_WRITE_TO_BINLOG | LOCAL]
    flush_option [, flush_option] ...

FLUSH ステートメントには、さまざまな内部キャッシュをクリアまたはリロードしたり、テーブルをフラッシュしたり、ロックを取得したりするいくつかのバリアント形式があります。FLUSH を実行するには、RELOAD 権限が必要です。あとで説明されているように、特定のフラッシュオプションには追加の権限が必要になることがあります。

デフォルトでは、サーバーは FLUSH ステートメントをバイナリログに書き込み、それらがレプリケーションスレーブにレプリケートされるようにします。ロギングを抑制するには、オプションの NO_WRITE_TO_BINLOG キーワード、またはそのエイリアス LOCAL を指定します。

注記

FLUSH LOGS、FLUSH TABLES WITH READ LOCK (テーブルリスト付き、またはなし)、および FLUSH TABLES tbl_name ... FOR EXPORT は、スレーブにレプリケートされると問題が発生するため、どのような場合でもバイナリログに書き込まれません。

SIGHUP シグナルをサーバーに送信すると、さまざまな形式の FLUSH ステートメントに似たいくつかのフラッシュ操作が発生します。セクション5.1.11「シグナルへのサーバー応答」を参照してください。

FLUSH ステートメントは暗黙的なコミットを発生させます。セクション13.3.3「暗黙的なコミットを発生させるステートメント」を参照してください。

RESET ステートメントは、FLUSH に似ています。レプリケーションでの RESET ステートメントの使用については、セクション13.7.6.6「RESET 構文」を参照してください。

flush_option には、次のいずれかの項目を指定できます。

• DES_KEY_FILE

  サーバーの起動時に --des-key-file オプションで指定されたファイルから DES キーをリロードします。

• HOSTS

  ホストキャッシュを空にします。ホストキャッシュは、一部のホストが IP アドレスを変更したか、または Host 'host_name' is blocked というエラーメッセージが表示された場合にフラッシュするようにしてください。(セクションB.5.2.6「ホスト 'host_name' は拒否されました」を参照してください。) MySQL サーバーへの接続中に、特定のホストに関して max_connect_errors 個を超えるエラーが連続して発生すると、MySQL は何か問題があると見なし、そのホストをそれ以上の接続要求からブロックします。ホストキャッシュをフラッシュすると、ホストからのそれ以上の接続試行が可能になります。max_connect_errors のデフォルト値は 10 です。このエラーメッセージを回避するには、max_connect_errors が大きな値に設定された状態でサーバーを起動します。

• [log_type] LOGS

  log_type オプションを指定しない場合、FLUSH LOGS はすべてのログファイルを閉じて、再度開きます。バイナリロギングが有効になっている場合は、バイナリログファイルのシーケンス番号が、前のファイルを基準にして 1 増分されます。

  log_type オプションを指定すると、指定されたログタイプのみがフラッシュされます。次の log_type オプションが許可されます。

  • BINARY はバイナリログファイルを閉じて、再度開きます。

  • ENGINE は、インストールされているストレージエンジンのフラッシュ可能なログをすべて閉じて、再度開きます。現在、これにより InnoDB はそのログをディスクにフラッシュします。

  • ERROR はエラーログファイルを閉じて、再度開きます。

  • GENERAL は一般的なクエリーログファイルを閉じて、再度開きます。

  • RELAY はリレーログファイルを閉じて、再度開きます。

  • SLOW はスロークエリーログファイルを閉じて、再度開きます。

• PRIVILEGES

  mysql データベース内の付与テーブルから権限をリロードします。

  GRANT、CREATE USER、CREATE SERVER、および INSTALL PLUGIN ステートメントの結果として、サーバーは情報をメモリーにキャッシュします。このメモリーは、対応する REVOKE、DROP USER、DROP SERVER、および UNINSTALL PLUGIN ステートメントによって解放されないため、キャッシュを発生させるステートメントの多数のインスタンスを実行するサーバーでは、メモリー使用量が増加します。このキャッシュされたメモリーは FLUSH PRIVILEGES で解放できます。

• QUERY CACHE

  クエリーキャッシュをデフラグして、そのメモリーをより有効に活用します。FLUSH QUERY CACHE は、FLUSH TABLES や RESET QUERY CACHE とは異なり、キャッシュからクエリーを削除しません。

• STATUS

  このオプションは、現在のスレッドのセッションステータス変数値をグローバル値に追加し、セッション値を 0 にリセットします。一部のグローバル変数も 0 にリセットされる可能性があります。また、(デフォルトおよび指定された) キーキャッシュのカウンタも 0 にリセットし、Max_used_connections を開いている接続の現在の数に設定します。これは、クエリーをデバッグしている場合にのみ使用するようにしてください。セクション1.6「質問またはバグをレポートする方法」を参照してください。

• TABLES

  FLUSH TABLES はテーブルをフラッシュし、使用されているバリアントに応じてロックを取得します。許可される構文については、このセクションのあとの方で説明されています。

• USER_RESOURCES

  時間あたりのすべてのユーザーリソースを 0 にリセットします。これにより、時間あたりの接続、クエリー、または更新の制限に達したクライアントが、ただちにアクティビティーを再開できるようになります。FLUSH USER_RESOURCES は、最大同時接続に対する制限には適用されません。セクション6.3.4「アカウントリソース制限の設定」を参照してください。

mysqladmin ユーティリティーは、flush-hosts、flush-logs、flush-privileges、flush-status、flush-tables などのコマンドを使用して、いくつかのフラッシュ操作へのコマンド行インタフェースを提供します。セクション4.5.2「mysqladmin — MySQL サーバーの管理を行うクライアント」を参照してください。

注記

ストアドファンクションまたはトリガー内で FLUSH ステートメントを発行することはできません。ただし、ストアドプロシージャーでは、それがストアドファンクションまたはトリガーから呼び出されないかぎり、FLUSH を使用できます。セクションD.1「ストアドプログラムの制約」を参照してください。

MySQL 5.6.11 でのみ、このステートメントを発行する前に、gtid_next を AUTOMATIC に設定する必要があります。(Bug #16062608、Bug #16715809、Bug #69045)

FLUSH TABLES 構文

FLUSH TABLES には、次に説明されているいくつかの形式があります。TABLES オプションのいずれかのバリアントが FLUSH ステートメントで使用されている場合は、それが、使用されている唯一のオプションである必要があります。FLUSH TABLES は FLUSH TABLES のシノニムです。

• FLUSH TABLES

  開かれているすべてのテーブルを閉じ、使用されているすべてのテーブルを強制的に閉じて、クエリーキャッシュをフラッシュします。FLUSH TABLES はまた、RESET QUERY CACHE ステートメントと同様に、クエリーキャッシュからすべてのクエリー結果を削除します。

  MySQL 5.6 では、アクティブな LOCK TABLES ... READ が存在する場合、FLUSH TABLES は許可されません。テーブルをフラッシュしてロックするには、代わりに FLUSH TABLES tbl_name ... WITH READ LOCK を使用します。

• FLUSH TABLES tbl_name [, tbl_name] ...

  カンマで区切られた 1 つ以上のテーブル名のリストを指定した場合、このステートメントは、サーバーが指定されたテーブルのみをフラッシュする点を除き、名前のない FLUSH TABLES と同様です。指定されたテーブルが存在しない場合、エラーは発生しません。

• FLUSH TABLES WITH READ LOCK

  開かれているすべてのテーブルを閉じ、グローバルな読み取りロックを保持しているすべてのデータベースのすべてのテーブルをロックします。これは、特定時点のスナップショットを取得できる、Veritas または ZFS などのファイルシステムがある場合にバックアップを取得するための非常に便利な方法です。このロックを解放するには、UNLOCK TABLES を使用します。

  FLUSH TABLES WITH READ LOCK は、グローバルな読み取りロックを取得しますが、テーブルロックは取得しないため、テーブルロックと暗黙的なコミットに関して LOCK TABLES および UNLOCK TABLES と同じ動作には従いません。

  • UNLOCK TABLES は、現在 LOCK TABLES でロックされているテーブルがある場合にのみ、アクティブなトランザクションをすべて暗黙的にコミットします。FLUSH TABLES WITH READ LOCK はテーブルロックを取得しないため、このステートメントに続く UNLOCK TABLES に対してコミットは発生しません。

  • トランザクションを開始すると、ユーザーが UNLOCK TABLES を実行したかのように、LOCK TABLES によって取得されたテーブルロックが解放されます。トランザクションを開始しても、FLUSH TABLES WITH READ LOCK によって取得されたグローバルな読み取りロックは解放されません。

  FLUSH TABLES WITH READ LOCK では、サーバーがログテーブルに行を挿入することは妨げられません (セクション5.2.1「一般クエリーログおよびスロークエリーログの出力先の選択」を参照してください)。

• FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK

  このステートメントは、指定されたテーブルをフラッシュし、それに対する読み取りロックを取得します。このステートメントは、まずテーブルに対する排他的なメタデータロックを取得するため、これらのテーブルを開いているトランザクションの完了を待機します。次に、このステートメントはテーブルキャッシュからテーブルをフラッシュし、テーブルを再度開き、(LOCK TABLES ... READ と同様に) テーブルロックを取得したあと、そのメタデータロックを排他的から共有にダウングレードします。このステートメントがロックを取得し、そのメタデータロックをダウングレードしたら、ほかのセッションはそれらのテーブルを読み取ることができますが、変更することはできません。

  このステートメントはテーブルロックを取得するため、いずれかの FLUSH ステートメントを使用するために必要な RELOAD 権限に加えて、各テーブルに対する LOCK TABLES 権限が必要です。

  このステートメントは、既存のベーステーブルにのみ適用されます。名前がベーステーブルを参照している場合は、そのテーブルが使用されます。TEMPORARY テーブルを参照している場合、その名前は無視されます。名前がビューに適用される場合は、ER_WRONG_OBJECT エラーが発生します。それ以外の場合は、ER_NO_SUCH_TABLE エラーが発生します。

  ロックを解放するには UNLOCK TABLES を、ロックを解放し、ほかのロックを取得するには LOCK TABLES を、またはロックを解放し、新しいトランザクションを開始するには START TRANSACTION を使用します。

  FLUSH のこのバリアントを使用すると、テーブルのフラッシュとロックを 1 つの操作で実行できます。これにより、アクティブな LOCK TABLES ... READ が存在する場合は FLUSH TABLES が許可されないという MySQL 5.6 での制限の回避方法が提供されます。

  このステートメントは暗黙的な UNLOCK TABLES を実行しないため、このステートメントをアクティブな LOCK TABLES が存在する間に使用したり、取得されたロックをまず解放することなくふたたび使用したりすると、エラーが発生します。

  フラッシュされたテーブルが HANDLER で開かれた場合、そのハンドラは暗黙的にフラッシュされ、その位置を失います。

• FLUSH TABLES tbl_name [, tbl_name] ... FOR EXPORT

  この FLUSH TABLES バリアントは、InnoDB テーブルに適用されます。これは、MySQL 5.6.6 の時点で使用できます。このステートメントは、サーバー稼働中にバイナリテーブルのコピーができるように、名前付きテーブルへの変更をディスクにフラッシュします。

  このステートメントは、次のように機能します。

  1. 指定されたテーブルに対する共有メタデータロックを取得します。これらのテーブルを変更したか、またはそれに対するテーブルロックを保持するアクティブなトランザクションがほかのセッションに存在するかぎり、このステートメントはブロックされます。ロックが取得されると、このステートメントは、これらのテーブルを更新しようとするトランザクションをブロックしながら、読み取り専用操作は続行できるようにします。

  2. これらのテーブルのすべてのストレージエンジンが FOR EXPORT をサポートしているかどうかをチェックします。サポートしていないものがある場合は、ER_ILLEGAL_HA エラーが発生し、このステートメントは失敗します。

  3. このステートメントは、各テーブルのストレージエンジンに、そのテーブルをエクスポートのために準備するよう通知します。そのストレージエンジンは、保留中の変更がすべてディスクに書き込まれるようにする必要があります。

  4. このステートメントは、FOR EXPORT ステートメントの完了時に以前に取得されたメタデータロックが解放されないように、そのセッションをテーブルロックモードにします。

  FLUSH TABLES ... FOR EXPORT ステートメントには、各テーブルに対する SELECT 権限が必要です。このステートメントはテーブルロックを取得するため、いずれかの FLUSH ステートメントを使用するために必要な RELOAD 権限に加えて、各テーブルに対する LOCK TABLES 権限も必要です。

  このステートメントは、既存のベーステーブルにのみ適用されます。名前がベーステーブルを参照している場合は、そのテーブルが使用されます。TEMPORARY テーブルを参照している場合、その名前は無視されます。名前がビューに適用される場合は、ER_WRONG_OBJECT エラーが発生します。それ以外の場合は、ER_NO_SUCH_TABLE エラーが発生します。

  InnoDB は、独自の .ibd ファイルを持つテーブル (つまり、innodb_file_per_table 設定が有効になった状態で作成されたテーブル) に対する FOR EXPORT をサポートしています。InnoDB は、FOR EXPORT ステートメントから通知されると、すべての変更を確実にディスクにフラッシュします。.ibd ファイルはトランザクション一貫性があり、サーバーの実行中にコピーできるため、これにより、FOR EXPORT ステートメントが有効になっている間にテーブルの内容のバイナリコピーを作成できます。FOR EXPORT は、InnoDB システムテーブルスペースファイルや、いずれかの FULLTEXT インデックスを含む InnoDB テーブルには適用されません。

  FLUSH TABLES ...FOR EXPORT は、MySQL 5.6.17 より前のパーティション化された InnoDB テーブルでは機能しませんが、MySQL 5.6.17 以降ではこのようなテーブルに対してもサポートされます。(Bug #16943907)。

  FOR EXPORT から通知されると、InnoDB は、通常はメモリー内か、またはテーブルスペースファイルの外部にある個別のディスクバッファーに保持される特定の種類のデータをディスクに書き込みます。InnoDB はまた、テーブルごとに、そのテーブルと同じデータベースディレクトリ内に table_name.cfg という名前のファイルも生成します。.cfg ファイルには、あとでテーブルスペースファイルを同じサーバーまたは別のサーバーに再インポートするために必要なメタデータが含まれています。

  FOR EXPORT ステートメントが完了すると、InnoDB によって、すべてのダーティーページがテーブルデータファイルにフラッシュされています。変更バッファーのエントリはすべて、フラッシュの前にマージされます。この時点で、テーブルはロックされ、静止します。これらのテーブルはディスク上でトランザクション的に一貫性のある状態にあるため、.ibd テーブルスペースファイルを対応する .cfg ファイルとともにコピーすることによって、これらのテーブルの整合性のあるスナップショットを取得できます。

  コピーされたテーブルデータを MySQL インスタンスに再インポートする手順については、セクション14.5.5「テーブルスペースの別のサーバーへのコピー (トランスポータブルテーブルスペース)」を参照してください。

  テーブルの処理を完了したあと、ロックを解放するには UNLOCK TABLES を、ロックを解放し、ほかのロックを取得するには LOCK TABLES を、またはロックを解放し、新しいトランザクションを開始するには START TRANSACTION を使用します。

  セッション内で次のいずれかのステートメントが有効になっている間は、FLUSH TABLES ... FOR EXPORT を使用しようとするとエラーが生成されます。

  FLUSH TABLES ... WITH READ LOCK
  FLUSH TABLES ... FOR EXPORT
  LOCK TABLES ... READ
  LOCK TABLES ... WRITE

  セッション内で FLUSH TABLES ... FOR EXPORT が有効になっている間は、次のいずれかのステートメントを使用しようとするとエラーが生成されます。

  FLUSH TABLES WITH READ LOCK
  FLUSH TABLES ... WITH READ LOCK
  FLUSH TABLES ... FOR EXPORT